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

[Steve Atkins]

On Oct 25, 2010, at 5:48 PM, John R. Levine wrote:

>>> 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
> 
> Let's say your message has two From lines, one from bob at blurfle.net, one from security at ebay.com, and you sign the first with d=blurfle.net.

> Perhaps blurfle.net even publishes discardable ADSP.
> 
> My concern would be that filtering agents might notice the blurfle header and signature and deem it harmless,

If the filtering agent recognises blurfle.net then that would make blurfle.net "someone trustworthy", and reduces to exactly the situation I was discussing 4 posts upstream. ("The real risk here is that someone can present a message as signed by someone trustworthy..."). 

If they've never seen blurfle.net before, then there's no reason to consider the signer trustworthy and your hypothetical filtering agent is broken.

> but an MUA would show the ebay header.

> In any event, I think it's reasonable to say that DKIM signers shouldn't sign a message with an extra From or Subject header,

That doesn't really add much value, as you can always grab the signed message, add a header and resend it (unless you're also planning on mandating h=from:from:subject:subject).

It's a perfectly reasonable policy for a DKIM signer to have, though.

> and verifiers shouldn't say the signature on such a message is good, even if it validates technically.  

Works for me, at least at the should-as-opposed-to-SHOULD level. 

I've said as much several times, and the only disagreements I've seen are people who are saying that that's not strict enough, and that DKIM verifiers also shouldn't verify a message that has, for example, bare linefeeds in it or a base 64 encoded section with an eighty character line in it.

> I dug through my message archives last week, and I don't think I've ever seen a legit message with that flaw, so it's hard to think of a reason to cut such messages any slack.

Cheers,
  Steve