[ietf-dkim] Proposal for new text about multiple header issues

[Steve Atkins]

On Oct 25, 2010, at 1:58 PM, Murray S. Kucherawy wrote:

>> -----Original Message-----
>> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.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.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