[ietf-dkim] Data integrity claims
ietf-dkim at kitterman.com
Fri Oct 15 17:08:34 PDT 2010
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?
More information about the ietf-dkim