> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Douglas Otis > Sent: Friday, October 15, 2010 2:30 PM > To: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] detecting header mutations after signing > > 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. 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. > 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. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
