ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From

2010-10-06 06:27:05
On Mon, 04 Oct 2010 23:24:11 +0100, Hector Santos <hsantos(_at_)isdg(_dot_)net> 
wrote:

I propose the following addition text by adding to 48721bis to address
this serious issue;

   Special Consideration for Verifying and Signing From: Header

   As an exception, header hash verification MUST be done for all
   5322.From fields and not just the last one.  Signing MUST be done
   for all 5322.From fields found, even though RFC5322 recommends
   only one 5322.From should be used. This will mitigate any
   replay that prepends a new 5322.From header to a DKIM signature
   valid message.  Some MUAs have should to display only the first
   5322.From header found.

I think you need stronger wording than that. And while you are fixing the  
problem for From: headers, you might as well fix it for the other  
once-only headers (such as Subject:) while you are at it. But the prime  
place to fix it is in the verification. I therefore suggest the following  
in section 6.1.1, presumably after the paragraph beginning "If the "h="  
tag ...":

"If the "h=" tag includes any header field for which, according to  
[RFC5322], the maximum number within the header section is limited to 1,  
and if more than 1 occurrence of that header field is present in the  
message, the verifier MUST ignore the DKIM-Signature header field and  
return PERMFAIL (multiple occurrences of XXX header field). Moreover, it  
SHOULD so treat any header field defined in any other standards track  
document to have a maximum occurrence of 1."

If you think that is a bit too vicious, here is a slightly more  
permnissive version:

"If the "h=" tag includes any header field for which, according to  
[RFC5322], the maximum number within the header section is limited to 1,  
and if the number of occurrences of that header field present in the  
message exceeds its number of occurrences in the "h=" tag, ......".

Having fixed the verification process, one could then add similar wording  
to the signing process.

NOTE that this is a serious security issue, and the present draft cannot  
proceed until this problem is fixed. If that means progression to Draft  
Standard gets delayed, then so be it.

And note that pious exhortations to ensure that RFC5322 be followed, or  
that MUAs should be fixed to solve this problem, are no solution. We live  
in the Real World (TM), and neither of those things is going to happen,  
desirable as they might be.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      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