[ietf-dkim] Proposal for new text about multiple header issues
Murray S. Kucherawy
msk at cloudmark.com
Mon Oct 25 12:19:27 PDT 2010
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Steve Atkins
> Sent: Monday, October 25, 2010 9:56 AM
> To: IETF DKIM WG
> Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues
> 8.14 Malformed Inputs
> DKIM allows additional headers to be added to a signed message without
> breaking the signature. This tolerance can be abused during a replay
> attack by adding additional copies of headers that are displayed to the
> end user, such as From or Subject, to an already signed message in a
> way that doesn't break the signature.
I'd strike "during a replay attack" because, as some have noted, the attack can be constructed deliberately on an original message.
I'd also probably want to include some of my original text that sets up why various agents are so permissive today.
> The resulting message violates section 3.6 of [MAIL] so the way it will
> be handled and displayed by an MUA is unpredictable - but in some cases
> they will display the newly added headers rather than those that are
> part of the originally signed message. This might allow an attacker to
> replay a previously sent, signed message with a different Subject,
> From or To field.
It's also not specific to MUAs. Filtering agents can be similarly duped.
> 1) Rejecting or treating as suspicious any message that has multiple
> copies of headers that are disallowed by section 3.6 of [MAIL],
> particularly those that are displayed to the end user (From, To, Cc,
> 2) Treating any message that has multiple copies of headers that are
> disallowed by section 3.6 of [MAIL] as not DKIM signed.
These almost say the same thing to me. For example, "treat as unsigned" could be rolled into "treat as suspicious". And I'd prefer to show 3.6 as an example of a more general problem, in case later some vector is found using MIME.
If you concur, I'll take another run at it.
More information about the ietf-dkim