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(_dot_)com"
without needing to play any games with multiple headers
Let's say your message has two From lines, one from
bob(_at_)blurfle(_dot_)net, one from security(_at_)ebay(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html