On 10/15/10 4:50 PM, Murray S. Kucherawy wrote:
On Friday, October 15, 2010 2:30 PM, Douglas Otis wrote:
Citing a layer violation makes little sense. With DKIM, the message
body does not stand on its own. DKIM binds elements related to the
RFC5322 header fields with the message body, for the purpose of
extending favorable message handling, such as white-listing. Since
DKIM has this property, citing layer violations lacks any basis.
I thought the "What DKIM does" thing was a long-dead horse, as we'd long ago
reached consensus that what DKIM does is provide a stable identifier on the
message, and nothing more. That makes this assertion inapposite.
I think perhaps now would be a good time to make that explicit, since a lot
of people (including some in here) are continuing to infer that DKIM should
be used to "protect" the body. So I propose this be added to 4871bis:
1.4 Data Integrity
A DKIM signature associates the d= name with the computed hash of
some or all of the message (see Section 3.7) in order to prevent the
re-use of the signature with different messages. Verifying the
signature asserts that the hashed content has not changed since it
was signed, and asserts nothing else about "protecting" the end-to-end
integrity of the message.
DKIM mandates inclusion of the From header field and recommends
validating DKIM signatures related to this field first. Why?
DKIM failed to include fundamental aspects of RFC5322 compliance, that
when not followed, permits the exploitation of message handling on the
basis of mistaken DKIM PASS results when there are multiple From header
fields, for example. The verification process MUST explicitly
disqualify such messages from ever receiving a PASS verification.
RFC5322 compliance is neither an assured function of SMTP nor MUAs. As
such, DKIM has a serious process flaw when verification fails to ensure
normally singular headers have not been pre-pended. Their display or
assumed relationship with a DKIM PASS may enable methods to exploit
either what is displayed or associated with DKIM results. Clearly,
Section 6.2 was short sighted in the advice given.
I apologize in advance if that causes yet another traffic maelstrom, but it's
something we need to settle. And since the discontinuous expectation of DKIM
exists outside the working group as well as inside it, that means consensus
needs to be codified.
Not being explicit with respect to important aspects of RFC5322
compliance in the DKIM verification process represents an error that can
be remedied ONLY by changing the DKIM verification process. A few minor
changes to this process would ensure these types of exploits are
thwarted. If or when some other exploit is discovered, the process may
need further adjustment.
There is an expectation in the integrity of the DKIM process. Few
security related protocols don't require adjustments to mitigate various
types of newly discovered exploitations. Isn't this why specifications
aren't advanced until there is greater confidence in the integrity of
the process?
Systems discovered having defective capacitors should be recalled and
have the defective devices replaced. Toys for children removing fingers
should be recalled and modified. Otherwise, manufacturers risk a class
action suit. There is no reason not to repair DKIM when its
verification process fails to offer the expected protections being
sought. Please, don't blame the short-comings on the MUA.
John and Mark are right. It is wrong to consider the DKIM signature
some type of academic exercise devoid of how DKIM might be exploited.
The WG should step up and deal with this assumed compliance
vulnerability. Without DKIM, this vulnerability would not exist.
Can someone name a current MUA that treats a DKIM-signed, malformed message
differently from an unsigned one in terms of what it renders? If not, that
last assertion is also false.
And if the response to that is "MUAs can change to show what was validated
and what wasn't", then they can also change to handle the malformations we're
talking about. And, in fact, that's probably easier to implement.
There are millions of MUAs that are unlikely to be updated anytime
soon. Even so, the error clearly rests with the DKIM verification
process. Why not fix the problem without requiring all MUAs to change,
where non-compliance with RFC5322 only becomes a problem in conjunction
with message handling and displays based upon DKIM results. Had the
DKIM verification results not been in error, there would not be a problem.
Don't think of DKIM as being inviolate offering only a disjointed
sacrosanct identifier. DKIM process must also guard against the
exploitation of its results, with goes back the first question asked.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html