On Fri, 05 Nov 2010 18:46:37 -0000, Douglas Otis <[email protected]>  
wrote:

> Append to Section 6 Verifier Actions:
>
> It is not reasonable to assume a message is in compliance with RFC5322.
> To mitigate trivial exploitation of trust established by DKIM
> signatures, messages having multiple header fields for "orig-date",
> "from", "sender", "reply-to", "to", "cc", "message-id", "in-reply-to",
> "references", or "subject" MUST always return PERMFAIL for any DKIM
> signature associated with the message.  When there are multiple
> singleton header fields, a field selected for display or sorting is
> therefore undefined.  Likely top-down selections by consumers of DKIM
> status where the signature verification selects bottom-up leaves
> singleton headers highly prone to trivial exploitation.

+0.75

I prefer requiring the signer to make such a check and then verifying that  
the signer had done so. It comes to the same thing, of course (it  
establishes that no extra headers had appeared in between, or  
alternatively that no malicious signer had failed to make the check). See  
wording proposed by Hector and myself.

The benefit of this approach is that we avoid accusations ot "layer  
violations".

Note also that it is also sufficient to address only this "header  
counting" violation of 5322. If any other 5322 violation is present (e.g.  
a malformed header, which might be part of some scam) then, assuming that  
header has been signed, the evidence of the malformation will be preserved  
and its effect will be the same as if such a scam were attempted with  
current unsigned messages.

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email protected]      snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Reply via email to