On Oct 25, 2010, at 1:58 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> 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: [email protected]" 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
