On Fri, 08 Jul 2011 18:51:39 +0100, Pete Resnick
<presnick(_at_)qualcomm(_dot_)com>
wrote:
I want to try to be precise, which I don't think Charles is being with
his below two sets of "facts". Let me try to clarify:
On 7/8/11 5:52 AM, Charles Lindsey wrote:
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.
What Charles have written above is not true, or at the very least
extremely imprecise and confusing....
(Note that I was not proposing a specific text for inclusion but rather
indicating what needed to be covered somehow)
... Try this:
1a. The fact that DKIM signers can (optionally) sign a message in such a
way that header fields can be added to the top of the message by
intermediaries without invalidating the signature means that unsigned
header fields can appear at the top of a validly signed message needs to
be drawn to the attention of implementors...
1b. The fact that DKIM signers can sign header fields with all manner of
unverified data in them, including header fields that might violate the
syntax requirements of RFC 5322, without invalidating the signature
means that header fields with unverified data can appear in an validly
signed message needs to be drawn to the attention of implementors...
Well that's getting nearer, but it's not quite there yet. How about:
Implementors of identity assessors and other agents need to be aware that
DKIM signers can sign a message in such a way some header field at the top
of the message (whether present originally or added later by an
intermediary) is unverified, even though another instance of that field
further down is signed, and even where the presence of such multiple
instances violates RFC 5322. This can lead to a variety of attacks which
take advantage of lenient MUAs which neither display nor warn about the
duplicated header field.
I hope this makes it clear that the attack is really against the lenient
MUA (even though DKIM has provided the opportunity to mount it). But I am
particularly concerned to be clear that is is not just intermediaries that
are the Bad Guys - malicious signers are, if anything, a more serious
problem. Hence my sentence in brackets. You could leave that out, but
please do NOT suggest that it is only "added" headers that are the problem.
I *believe* what I said contains all of the information that Charles
wrote in his #1. If I missed something, please say.
But I also believe that the current security considerations section
*says* all that. If you think it doesn't capture something in the above
two statements, please say.
The present text does not highlight the feature of section 5.4.2 that
enables this problem, and it is far from obvious that it so enables it,
given that DKIM was around for many years brfore someone spotted it.
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.
That one is simply bogus. The document repeatedly (and correctly) states
that having a DKIM signature *does not*, and *ought not*, in an of
itself, add any credence to a message. If that needs to be made clearer,
I'm all for it. But I think it is currently perfectly clear in the
document.
Then what on earth IS the purpose of DKIM? There is an expectation that
identity assessors will treat properly signed messages more favourably
than signed ones (just how thay do that, and what other information they
take into account is carefully not said). The malicious signer is hoping
that the treatment his scam gets is favourable enough to get past the
assessor unscathed and so reach that lenient MUA, where the real damage
happens.
My main concern is that malicious signers and malicious intermediaries are
both recognized (or if not that neither is explicitly mentioned). IMHO is
is the malicious signers that are more insidious, since the 'h=from:from:'
offers no protection against them.
--
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