Michael Thomas wrote:
Stephen Farrell wrote:
I think that a number of those in favour have stated their
reasoning, as have you. So I don't think there's a lot that
remains to be said in this particular debate. But if I've
missed something that you reckon still needs a response (quite
possible) then send me a link to the archive.
Yes, here's the message I sent out last week which I haven't
heard a reply from the proposers of this change:
Actually, I thought there'd been a couple of responses to
that, in any case some did discuss some of the issues you
list even if no-one so far has given a blow-by-blow
response.
I believe I haven't seen a response to your point that verifiers
will still be waiting for the key and may have hashed the entire
body before the key arrives (I assume the response will be the
obvious "caching" and "signer benefits" points;-)
Stephen.
Barry Leiba wrote:
As a WG participant:
I don't see the problem you have, though. In particular, why is it
better to store a header hash in a tag in DKIM-Signature than it is to
store a body hash there? It seems to me that the combination of a
BODY hash and z= will give the best diagnostic combination. l= seems
a red herring (but explain, if I'm wrong), since the signer and
verifier must already deal with deciding which part of the body
contributes to the hash, whether they then hash it separately or not.
Further, there are other reasons it might be rather nice to have the
body hash. For one, it means that the verifier can start validating
the sig after having read the header-terminating CRLF, without yet
having to read the body, thus allowing the signature validation to be
done in parallel with the reading of the body (which may be
significant with large bodies).
I replied:
I just realized this morning that this benefit is mostly a
mirage: you don't have the public key until you query DNS,
and in all likelihood the message is going to be received
by the time you get the key back (assuming it's average size).
The only way to make this a reliable feature would be to send
the key in the mail itself ala IIM.
So let me see if I can tally this up:
1) ± can determine if body or headers are broken; - because it can
be done in a backward compatible fashion.
2) + can determine early on if header signature is valid; weak
because you won't ordinarily have the key, and most especially
not from malicious domains
3) + can hash a body once for redistribution; a fairly marginal
feature that might help mass mailers, but Moore's law is just
as likely to help, um, more.
4) - breaks backward compatibility
5) - no way for signer to determine when it's safe to not send
-allman-01; the longer we wait for the RFC #, the bigger this
problem becomes
6) - canonicalization/hashing agreement is the hardest part of the
spec to get right from an interop standpoint.
So the way I look at it you've got one nice benefit that can be
implemented in a backward compatible way, and two benefits that
are of fairly marginal utility. The downside is that we get churn
in the part of the spec that's hardest to get right, and a not
terribly easy way for a signer to know when it's safe to deprecate
-allman-01.
If (2) were more a reliable feature this would be harder call, but
absent other upsides I've missed, I really don't see the overall
benefit.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html