Why not just keep it simple, less confusing, less challenging on
competing mind games, that DKIM can't not fully protect again unsigned
Author Addresses and its highly recommendation that DKIM signers,
verifiers and Mail Readers to kick out, reject, destroy, do not pass
on these sort of Invalid messages?
We should not leave any opening for what we don't know about. We
can't control it, and I doubt we would be able to address all legacy
systems.
Use KISS:
DKIM has no advice on how messages can be alter or viewed
after mail is signed and transmitted but we recommend that
you don't contribute by making sure only one FROM
exist during signing and verification.
Charles Lindsey wrote:
> 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.
>
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
