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

Hector Santos 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.
>
> 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;
No.  The trick is to list From twice in h=.  This ensures more From 
headers cannot be added without breaking the signature.

Perhaps this could be mentioned in the spec with a specific reference to 
the From header, but in general terms the spec is pretty clear about how 
to prevent the addition of a header field.

-Julian

signature.asc
Description: This is a digitally signed message part.

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