ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Data integrity claims

2010-10-17 20:08:08
  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

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