On 10/16/10 4:50 PM, 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.
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 see your point. But there is a big difference between
a) the assumption that DKIM always protect an entire message (which it
obviously does NOT) and
b) the assertion that DKIM delivers some basic functionality + can be
used in different modi operandi
These modi operandi, which probably need to be worked out in the
deployment documents (not in 4871bis) enable organizations to use DKIM
(among others) to protect specific parts of a message, which can be very
interesting for some organizations, as it won't require a complex PKI to
deploy. Another (important) use case will be using DKIM as an enabler
for reputation services. And there will probably be more use cases for DKIM.
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.
Right, this is in line with what I wrote above, about different kinds of
DKIM use. So let's not confuse things: DKIM itself does not provide a
useful minimum protection but can be used by applying the right
parameters and configuration to protect specific parts of a message
(after all, S/MIME and PGP also provide only protection of part of a
message).
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html