On 10/16/10 7:16 AM, Dave CROCKER wrote:
On 10/16/2010 2:39 AM, Mark Delany wrote:
My problem is that if some valuable domain like paypal sends me a
bunch of bits that I or my MUA or my MTA ties to paypal.com then
the end goal of DKIM is, IMO, that those bunch of bits I "see" are
the ones that paypal sent. No more, no less.
To murder another idiom: "What you see is what they sent" is I
believe the ultimate goal of DKIM. Or, "what you complain about is
what they sent". Whatever.
Agreed. When used properly, DKIM should be able to offer this
assurance. DKIM makes an assessment that neither an MUA or MTA can make.
My point is that DKIM is used within an environment that has a wide
range of attacks, such as including social. While it's of course
fair to say that DKIM "protects" the bits it covers, there are two
lines of potential misunderstanding.
The first is, of course, the bits not covered.
The second is that DKIM provides certain kinds of protection, for
the bits it protects, and not others.
So when we say that DKIM protects some bits, we need to be clear
what it is /not/ doing for those bits and what, associated /other/
bits are still subject to attack.
My own observation is that nearly all discussions about DKIM do not
reflect care -- and often don't reflect understanding -- about these
constraints. This leads to overly ambitious expectations for what
DKIM can do.
Only DKIM can defend against DKIM exploitations involving elements
handled by this protocol. Inadequately defined DKIM specifications,
that when implemented, now fail to prevent signatures from mistakenly
being considered valid and then exploited. This represents a failure to
adequately defined the DKIM process.
Informative advice given in Section 6.2 of RFC 4871 was largely limited
to ensuring results headers are not spoofed, while DKIM also failed to
consider the impact of duplicate header fields that might be relied upon
for acceptance, or might be inappropriately selected for display. This
issue is not resolved by suggesting a domain being exploited in a
spoofed From header field should include double From values in the h
parameter :^(
DKIM's advice lacked useful specifics in light of discovered exploits of
DKIM's poorly defined process. A process where invalid signatures might
be considered valid whenever RFC5322 compliance is presumed. Only DKIM
is able to correct these errors! Neither the MTA nor the MUA can ensure
RFC5322 compliance, nor should they. The MTA's role is a best effort
delivery of accepted messages. The MUA role is to display content
relevant to users.
When DKIM assurance by a domain affects message acceptance by the MTA
and/or changes how the message is displayed, then the process creating
this assurance MUST also guard against spoofed headers in the same
manner as MUAs have been advised with respect to result header fields.
It would be wrong to expect MTAs or MUAs to always validate RFC5322
compliance. If there is some other mandatory process offering this
protection it should have been included within the DKIM specifications.
Please don't suggest RFC5322 compliance assessment is the role of an
undefined message filtering process. DKIM should not use that excuse.
From: president(_at_)big-bank(_dot_)com
From: someone(_at_)big-isp(_dot_)com
dkim-signature: d=big-isp.com; h=from; ...
dkim results: big-isp.com=pass (DKIM should ensure this results in a
PERMFAIL)
While many may consider DKIM a method to ensure deliverance of bulk
email, without an adequately defined DKIM process, senders also run a
risk of their users not trusting a process offering bad assurances.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html