ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Final update to 4871bis for working group review

2011-07-10 22:41:30
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles 
Lindsey
Sent: Sunday, July 10, 2011 6:00 AM
To: DKIM
Cc: Pete Resnick
Subject: Re: [ietf-dkim] Final update to 4871bis for working group review

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.

Too specific.  All along I've been worried about naming specific attack vectors 
as such a list could be taken as exhaustive.  Try this:

"Agents that evaluate or apply DKIM output need to be aware that a DKIM signer 
can sign messages that are malformed (e.g., violate RFC5322), or become 
malformed in transit.  Such an action might constitute an attack against a 
receiver, especially where additional credence is incorrectly given to a signed 
message without evaluation of the signer.  Moreover, a verifier would be 
incorrect to infer that all instances of a header field are signed just because 
one is.  Agents will need to account for these issues when deciding how to 
apply DKIM results to message, especially when displaying them to users."

I think that covers just about everything.  I don't agree with calling out 
Section 5.4.2 specifically, as there could be some other way to mount a 
receiver attack we haven't seen yet; calling attention there might divert it 
from other places where it's also needed.

I also don't think this is strictly necessary because the text we've proposed 
for 8.15 covers it already, but I find this to be a palatable compromise.

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).

You've answered the question yourself there (though I assume the second 
"signed" was supposed to be "unsigned").

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.

I think the above text covers that as well.


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>