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