> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- > boun...@mipassoc.org] On Behalf Of Mark Delany > Sent: Saturday, October 16, 2010 2:39 AM > To: ietf-dkim@mipassoc.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
