On Oct 25, 2010, at 1:58 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 12:54 PM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues
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 ..." ?)
Isn't the more interesting attack a signature from some throwaway domain that
covered a matching From: but also contained a From: indicating some
high-value phish target?
Not really, no. Signing the From: field means nothing other than that it is the
same as when it was sent.
I can sign mail with d=blighty.com and "From: doolally(_at_)ebay(_dot_)com"
without needing to play any games with multiple headers
The only interesting attack in this entire situation is the ability to take a
message signed by a high-reputation domain, so that it'll get delivered to the
inbox, and to replace the Subject: (and possibly From:) with your own payload.
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.
Focusing on the MUA case might inadvertently suggest to implementers of other
components that this is not a concern for them.
True. Though it really shouldn't be a significant concern for them, as
filtering agents that are DKIM aware (should anyone create such a thing) and
have a valid DKIM identity will likely use that in preference to, say, the
From: field. And if the filtering agent is not DKIM aware, it's not an issue.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html