-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Saturday, October 16, 2010 2:39 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Data integrity claims
On Sat, Oct 16, 2010 at 12:10:48AM -0400, Dave CROCKER allegedly
wrote:
On 10/15/2010 8:32 PM, Mark Delany wrote:
Therefore one could
argue that DKIM is "protecting" that relationship between the
message
and identifier.
Clever phrasing. Might be too subtle for general use, but I think
it
offers a
perspective that could be useful.
I think the issue here is that when people talk about protecting a
message, they
tend to have in mind all sorts of attacks designed to trick users.
DKIM
actually does not have much to say about such things.
Yes, it ties an identifier to a bag of bits, and yes it specifies
what
those
bits are, but it really does deal only with those bits and not
(necessarily) the
entire message.
I have a problem with this approach and I don't pretend to know the
right answer.
My problem is that if some valuable domain like paypal sends me a
bunch of bits that I or my MUA or my MTA ties to paypal.com then the
end goal of DKIM is, IMO, that those bunch of bits I "see" are the
ones that paypal sent. No more, no less.
To murder another idiom: "What you see is what they sent" is I believe
the ultimate goal of DKIM. Or, "what you complain about is what they
sent". Whatever.
So anything that circumvents "what you see is what they sent" I think
is in scope for DKIM to eliminate or mitigate.
Is that requirement solved in the verification protocol of DKIM or is
that solved in advice to MTAs/MUAs? I don't know. But I am sure that
if we don't end up with that guarantee, then I do wonder what we are
offering.
Mark is more clearly articulating what I have been struggling with.
This is also one of the reasons I have always felt that 1st party
signatures are inherently a different value proposition from 3rd party
signatures.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html