On Wed, Oct 13, 2010 at 2:37 PM, Murray S. Kucherawy <[email protected]> wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Jeff Macdonald >> Sent: Wednesday, October 13, 2010 11:27 AM >> To: DKIM >> Subject: Re: [ietf-dkim] detecting header mutations after signing >> >> <rant> >> Count me as one of those who was confused early on about what DKIM >> provides. DKIM seems to make assurances to message integrity. But it >> doesn't. I think the reason why many think it does is because of the >> body hash. It is trying to do to much. It should just provide an >> identifier that can be verified. Instead of using the body for >> hashing, use the Message-ID header along with the Date header and just >> hash that. That way most folks would understand DKIM is just providing >> an Identifier. >> </rant> > > Then you send me a piece of signed mail, I change everything except the > Message-ID and Date, and send it to someone else. And the verifier will > green-light it, meaning you've taken responsibility for it. Are you OK with > that? > > My way of thinking about this is that verification of a message is equivalent > to collecting all the pieces (header, body, signature) and coming to you and > saying "Do you take responsibility for this?" If I get your public key from > DNS and everything lines up, you're implicitly saying "yes". > > Now, if I remove the whole body and most of the header from what I'm > presenting to you for that question, you're now possibly saying "yes" to > content you didn't create. Are you OK with that?
The only thing I'm willing to say "yes" to is that I created that identifier and nothing more. Enhancements to my rant would be to include the To: header as well. The point is DKIM provides a verifiable identifier. If there is anything in the spec that leads one to believe it provides more than that, it needs to be fixed. But like I said, I was ranting. -- Jeff Macdonald Ayer, MA _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
