ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] 1193 considered harmful

2006-03-23 08:21:10
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