ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] sophistry is bad, was Data integrity claims

2010-10-16 13:58:19
On Saturday, October 16, 2010 10:50:25 am Dave CROCKER wrote:
On 10/16/2010 10:26 AM, John R. Levine wrote:
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.

Technically. you are correct.  Semantically, that's silly.

We went through backflips trying to figure out how to design the
signatures so that the message modifications they allowed would preserve
the same message, for an ill defined but I think well understood version
of the same.

Yes that was the goal.  No that was not the result.

-1.  I think we did that just fine.

Which header fields are essential to protect?  How much of the message body
is essential to protect?

This is completely orthogonal to the question.  As long as a receiver can 
reliably determine what is protected and what is not, then the protection goal 
is achieved.  It does not require that there is agreement on what that should 
be.

The current DKIM spec does not answer these questions and easily permits
protecting very little of the message.  Almost certainly too little to
ensure the protection you assert.

One can also point a gun at ones own head.  That doesn't make a gun a suicide 
device of no value for anything else.  The spec does permit people to do silly 
things, but so what.

That's an example of what I mean when I says that there are assumptions
about DKIM that go beyond what it (always) delivers.

Saying it's possible to use DKIM in ways that doesn't support this is not the 
same as saying DKIM doesn't support it.

It's possible to operate any modern MTA as an open relay, but it doesn't 
follow that all MTAs are open relays or that they fail to protect against open 
relaying.

I guess I should thank you for demonstrating my point.

If you had one that relevant to the discussion, it's not at all clear to me 
what it was or how it was demonstrated.

While it's always been possible to sign messages in ways
that allow gross changes, e.g. don't sign the subject or MIME headers,
set l=0, if you sign a message using a normal set of options, the idea
was always that the message the recipient saw would be the one you
signed. Throwing up our hands at the double header trick is, one might
say, ahistoric.  Claiming it's an MUA problem is simply wrong.

1. Your first sentence concedes my basic point

2. There is no commonly-agreed upon and documented concept of "normal set
of options" that I'm aware of.  What is normal for you might or might not
be normal for the next person configuring DKIM.

True, but irrelevant.

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>