[ietf-dkim] draft-fenton-dkim-threats-00

Eliot Lear lear at cisco.com
Thu Oct 6 00:50:15 PDT 2005


Doug,

> Only when the "address" and the signer are the same, would it be 
> possible to safely make assertions of behavior, but then of course 
> extending assertions of behavior to the "address" would not be 
> required.  I see little within the threat analysis that clarifies this 
> limitation.  I am not comfortable with promises that "address" 
> protection is limited to just repudiation.

I do not know what you mean by "address" and the signer being the same. 
  If by that you mean that the domain of the signer and the sender are 
the same, then at least I don't disagree.  I can't say I agree because I 
don't really understand your concern.  It follows that in order to 
determine responsibility for the sender one first needs to determine 
responsibility for the domain, and the way that is done with DKIM is via 
DNS.  The source of authority for the sender can then from that point be 
delegated.  Are you questioning the strength of that delegation?  If so, 
could you please explain it in smaller words, step by step?

> 
> The threat draft makes what I see as rather dangerously broad 
> generalizations.  It becomes a perilous situation to consider 
> establishing a matrix of authorizations with respect to signers.  Such 
> an assessment scheme would depend upon an unaccounted signer where 
> repudiation _must_ be the sole objective.  Just as "Repudiation 
> MailFrom" became "Sender Authentication", there is a real danger the 
> limited benefits of repudiation will be extended by unfair reputation 
> assessments.

I'm sorry but I don't see how you got there.  Why must repudiation be 
the sole objective?

> 
> Inappropriate use of reputation can be prevented by simply limiting the 
> purported protection to just the signing domain.  Presume a fair 
> reputation scheme on the basis of the signer offers a full spectrum of 
> protections.  This protection can be slightly enhanced by safe 
> assertions the domain signs all their own mail.  Perhaps this type of 
> assertion could even be extended to also disallow the resending of their 
> mail.
> 
> On a related topic, adding an opaque-identifier greatly extends the 
> protections made possible by DKIM that are discounted in this draft.  
> Importantly, these identifiers permit replay abatement.  Alas, without 
> prompt curtailment of abusive replays, reputation does not offer 
> dependable protection, nor will DKIM.  Zombies are far too prevalent.

Does the SMTP Message-ID play this role?

Eliot


More information about the ietf-dkim mailing list