Barry Leiba wrote:
I'm really astonished that an open item that had no list discussion that
I can find and that is backward incompatible with -allman-01 is being
"accepted". Why?
As a WG chair:
As we said in the IETF session and in the Jabber room, nothing "decided"
at the IETF meeting is final until the issue is confirmed on the mailing
list. All that was "accepted" in the meeting is that the consensus in
the room was to favour this change.
We are now (thank you for starting it, Mike) discussing it on the
mailing list.
I have for quite some time been placing a hash of the headers alone in
the DKIM signature in an unassigned tag (X= in this message) to help
me determine whether it's the headers or the body that broke on a failed
signature. It's cheap: I just call SHAx_Final when the headers are
hashed; it's unobtrusive: it doesn't require that we change our current
hashing mechanism; and it doesn't bring up any nettlesome issues with
l= which are tricky.
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 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.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html