On Oct 25, 2010, at 12:19 PM, Murray S. Kucherawy wrote:
-----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.
The real risk here is that someone can present a message as signed by someone
trustworthy that has content different to that which was provided by the
trusted signer. If the entity adding the additional content is the original
signer, it may be a message composition bug, but it's not really any sort of
attack on DKIM.
Striking "replay attack" might make it less clear what the actual risk is,
rather than more clear.
("... can be abused, e.g. during a replay attack, by adding ..." ?)
I'd also probably want to include some of my original text that sets up why
various agents are so permissive today.
I'm not sure the history adds anything, and briefer tends to lead to a clearer
call to action.
(And it annoys Mark, and may be continuing a misinterpretation of the
robustness principle and...).
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.
They can, yes, though I'm not sure that's needed to explain why this may be a
bad thing to allow.
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.
They're somewhat different. The first case involves recognizing that such
messages are likely an attempt to be deceitful, and hence that the mail is
unwanted. It's an approach that affects parts of the mail delivery system
outside of DKIM, and will directly affect mail routing and delivery, and so can
only be implemented by a broader system architect, not by a DKIM implementor.
The second simply removes the DKIM-related benefit to this sort of attempt at
deceit, removing the benefit of doing it. It doesn't make any broader
judgement, and it can be handled entirely inside the DKIM verifier, without
having any behavior change in the rest of the mail system, other than that
implied by a lack of signature.
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.
I'd prefer to stick to actual concerns, for now - stressing theoretical risks
for which we have no idea how they could be implemented is a slippery slope.
(I'm assuming that "l=" is going to be removed - if not, that would change
things considerably as far as the likelihood of some sort of mime-related body
change).
If you concur, I'll take another run at it.
Sure.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html