ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] 1193 considered harmful

2006-03-27 09:37:21

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