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