On Thu, 07 Jul 2011 18:09:14 +0100, Pete Resnick
<presnick(_at_)qualcomm(_dot_)com>
wrote:
I am perfectly happy with Murray's original (and now, revised) text.
(Nits still being discussed are entirely up to the WG.) I am not happy
with Charles's text. Particularly:
On 7/7/11 5:08 AM, Charles Lindsey wrote:
Recall that, when multiple instances of a given header field are
present, they are signed starting with the last one and working
upwards (section 5.4.2). This DKIM feature can be deployed to
mount a
variety of attacks against the email system. In some, the attacker
is
also the signer, signing the second of some duplicated field on
behalf of his own domain, whilst hoping that some lenient MUA will
display only the first. In others, a genuine signature from the
domain under attack is obtained by legitimate means, but extra
header
fields are then added, either by interception or by replay.
It seems like this text is tailor-made to obfuscate who is doing the
attacking and who is being attacked. It's this distinction that I think
is the most important to make, and the above text simply does not
clarify; it muddies the waters. DKIM can only be "deployed to mount a
variety of attacks" if the recipient has already made the fatal mistake
of assuming that the existence of a cryptographically valid signature
*means* that the message is reliable and from a known "good" sender. You
could have a longer and more detailed discussion in the document about
how broken it is for a recipient to do such a thing, and put *that* into
the security consideration, but I don't think it's necessary. The above
can only obfuscate that very important point, making it out as if it's
something in the DKIM signing/verifying process that caused the problem.
If you do not like the text, then please suggest an alternative. I have
already made two attempts.
There are essentially two things that I wish to see stated. Both were
plainly stated in 8.14 of version-12, which is what this WG originally
submitted.
1. The fact that DKIM choose headers to sign from the bottom up (for good
reason) facilitates certain attacks (not against DKIM, but certainly
against somone/something) needs to be drawn to the attention of
implementors of identity assessors, so that they can take appropriate
action.
2. The fact that an attacker (whilst following DKIM to the letter) can use
it, in conjunction with duplicated headers, to add credence to his message
also needs to be drawn to their attention.
Any wording that makes those two points will be acceptable to me.
I would have much preferred normative wording to avoid this problem
entirely, but I can acdept fixing it in the Security Considerations if it
is done properly there. But I see that others (Doug and now Hector) are
still pressing for that, so we may presume that they would oppose complete
lack of mention of these two items, so that makes three of us.
--
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