-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Friday, October 15, 2010 2:30 PM
To: ietf-dkim(_at_)mipassoc(_dot_)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