ietf-dkim
[Top] [All Lists]

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

2010-10-16 09:53:09


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 Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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