On Wed, Oct 13, 2010 at 2:37 PM, Murray S. Kucherawy
<msk(_at_)cloudmark(_dot_)com> wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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