--On 4 October 2010 18:24:11 -0400 Hector Santos <hsantos(_at_)isdg(_dot_)net>
wrote:
It has been observed by implementations that is it possible to replay
a message with a 2nd 5322.From header at the top which wouldn't break
the DKIM signature validity, but would often be displayed by MUAs to
display the new 5322.From display rather than the signature bound
5322.From header.
Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to
display the signed header? Are there really MUA's that will display the
unsigned headers *and* assert that it was validated? If so, that's surely a
bug in the implementation of the MUA.
For example:
From: phisher(_at_)badguy(_dot_)com <-- injected, replayed, shown
by MUA
DKIM-Signature: d=signer.com .......;
From: signed(_at_)address(_dot_)com <-- hash bound to signature
The MUA will display the injected 5322.From header and the signature
is still valid because it only signed the bottom one and verifiers
also use this header to validate the signature.
A review of the the 4871 specification shows this statement in section
5.4 which can explains how this is possible:
5.4. Determine the Header Fields to Sign
...
Signers choosing to sign an existing header field that occurs more
than once in the message (such as Received) MUST sign the physically
last instance of that header field in the header block. Signers
wishing to sign multiple instances of such a header field MUST
include the header field name multiple times in the h= tag of the
DKIM-Signature header field, and MUST sign such header fields in
order from the bottom of the header field block to the top. The
signer MAY include more instances of a header field name in h= than
there are actual corresponding header fields to indicate that
additional header fields of that name SHOULD NOT be added.
There needs to be a special consideration where:
1) Verifiers and MDAs consider checking for violating RFC5322
messages with multiple 5322.From headers and rejected it, or
1) hash verification should be done for all 5322.From fields and not
just the last one as the above paragraph implies.
2) signing should be done for all 5322.From fields found, even though
RFC5322 recommends only one 5322.From should be used.
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.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html