On Oct 24, 2010, at 10:50 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: Sunday, October 24, 2010 10:36 PM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues
That still expands the API from the DKIM verifier quite a lot - it
requires the verifier to explicitly list which headers are signed, and
which aren't (that the h= field doesn't do that is what we're having
problems with). It would also require that to be pushed all the way
downstream to other pieces of software, perhaps via something similar
to an extended Authentication-Results type of header.
That's not impossible, but seems very complex for the specific problem
we're considering - we just need to communicate "This message violated
5322, specifically in a way that makes us think the sender is trying to
game DKIM" (either by flagging the mail as syntactically invalid and
suspicious at some point in the mail stream, or invalidating the DKIM
signature).
[...]
You seem to have some specific ideas in mind already. Can you propose some
alternate text?
Sure. Taking into account some of the other feedback too:
---
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.
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.
Because of this, inbound mail system implementors should consider defending
against this sort of replay attack by either
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.
Senders who feel that their messages might be particularly vulnerable to this
sort of attack who don't want to rely on receiver filtering of invalid messages
can ensure that adding additional headers will break their DKIM signature by
including two copies of the headers they're concerned about in the signature
(e.g. "h= ... from:from:to:to:subject:subject ...). See section 3.5 and 5.4 for
further discussion.
---
It's significantly less subtle than your phrasing, but I think bluntness and
clarity win out for a security discussion.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html