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: phis...@badguy.com <-- injected, replayed, shown by > MUA DKIM-Signature: d=signer.com .......; > From: sig...@address.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
