Michael Thomas wrote:
>> Generally I agree, but does saying "verification is undefined" satisfy those
>> concerned that this is a security vulnerability? The example of
>> double-From: shows verification succeeds. It's the interpretation of those
>> results that is the problem.
>
> These are two separate questions, I think. I'm only commenting on whether
> DKIM should be the SMTP police.
I don't think so, but it should inspect its own protocol requirements
and within those requirements is its crown jewel - 5322.FROM, the only
header that is required binding.
Now lets consider if its wasn't a requirement, would it matter then?
I think it greatly matters to the MUA participants.
Note, the 5322.Subject is also a victim here, but its optional and its
security threat is not even close that what a multiple 5322.From
reveals. So I think it warrants adding a check for that too. But not
as much as the From.
The point is DKIM took on the job of providing a mail integrity and
authentication work and raised the about what is expected. Included in
that job is protecting its primary header - 5322.From.
Keep in mind that not protecting it will also hurt ADSP which I
already showed that implementation may look for the first one as well.
In the spoofed Obama message, this is the authentication results
generated here:
Authentication-Results: dkim.winserver.com;
dkim=pass header.i=mipassoc.org header.d=mipassoc.org
header.s=k00001;
adsp=none author.d=whitehouse.gov signer.d=mipassoc.org;
It picked up the wrong one.
So we have TWO protocols that are affected by this. The irony in all
this is that this Multiple 5322.From could be used to solve the MLM
3rd party issue. :)
The verifier MUST check for invalid 5322.From messages if only because
its part of the DKIM and ADSP formula and mechanics.
Anyway, I hope the right decision is made and address it before it
widely discovered and becomes a problem. Even without DKIM, MTA
should be more aware about this and deal with it. But only DKIM can
close the loophole for legacy operations.
--
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
