-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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,
Subject).
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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html