ietf-dkim
[Top] [All Lists]

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

2010-10-04 17:26:34
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.

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.


-- 
Hector Santos, CTO
http://www.santronics.com




_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html