On Tue, 26 Oct 2010 02:09:23 +0100, Steve Atkins
<steve(_at_)wordtothewise(_dot_)com>
wrote:
On Oct 25, 2010, at 5:48 PM, John R. Levine wrote:
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,
......
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).
No, but you can then say that verifiers should reject it because it
shouldn't have been signed (in that form) in the first place.
Essentially, you need proper wording in TWO places; something like:
A. Signers MUST NOT sign a message where any header field included in the
'h=' tag and which is a <once-only> header occurs more than once in the
mesage.
B. Verifiers MUST return PERMFAIL if the signature does not verify
{obviously} OR if the signature had been improperly applied (in particular
if A had been violated).
where <once-only> implies some list of headers which we can argue about
later (obviously including From:, Subject:, etc and perhaps defined in
terms of RFC5322, RFC2045, etc).
Observe that this catches all the Bad Actors currently under discussion,
both those that deliberately violate 5322, and those that deliberatley
violate my rule A.
Moreover, there is NO LAYERING VIOLATION, because my rule B is merely
enforcing my rule A, and both rules would be a part of 4871-bis.
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.
Exactly.
Works for me, at least at the should-as-opposed-to-SHOULD level.
But why not at the SHOULD/MUST level? What I have suggested should stop
dead all forms of the attack that have been suggested. What more could you
want?
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.
Indeed, which is why my suggested two rules carefully stopped short of
that.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html