On Fri, 08 Jul 2011 18:51:39 +0100, Pete Resnick <presn...@qualcomm.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: c...@clerew.man.ac.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

Reply via email to