ietf-dkim
[Top] [All Lists]

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

2010-10-16 12:12:05


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave CROCKER
Sent: Saturday, October 16, 2010 10:50 AM
To: John R. Levine
Cc: DKIM List
Subject: Re: [ietf-dkim] sophistry is bad, was Data integrity claims



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.

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

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.

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

I guess I should thank you for demonstrating my point.


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.

d/
--


Dave,

This is disingenuous on your part. It is akin to saying that although
the common usage of hammers is to hit nails, we must accept within the
definition of normal the usage of beating people on the head with a
hammer.... simply because some people do and it is not documented
through warnings on hammers that this is not normal.

There is a subset of headers that the vast majority of informed (even
semi-informed) implementers would agree on. Perhaps we need to reach a
consensus and document this to protect the children.

Mike

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

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