[ietf-dkim] Data integrity claims

[Scott Kitterman]

On Friday, October 15, 2010 07:50:36 pm Murray S. Kucherawy wrote:
> > -----Original Message-----
> > From: ietf-dkim-bounces at mipassoc.org
> > [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Douglas Otis Sent:
> > Friday, October 15, 2010 2:30 PM
> > To: ietf-dkim at 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.

Does it?  If the identifier is bound to the hashed information, I think it 
makes complete sense to believe one can make something of that content and 
it's relation to the identifier.  It provides a stable identifier, but that 
identifier is inextricably tied to the signed content.

> 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.

Your proposed wording sounds a lot to me like what I think of as "protecting" 
the end-to-end content.  I feel there's a lot of talking past each other here.

If we were doing what you think of as "protecting", what would be different?

Scott K