Re: [ietf-dkim] 1193 considered harmful

> 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).  Related to that, it means that the verifier, if it has 
decided to trash the message, can do so by routing the body to /dev/null 
as soon as it's made that decision, rather than having to write the body 
to disk (or keep it in memory) while computing the hash.  Third, as was 
pointed out, a sender could hash a large body once and send it multiple 
times, possibly saving a lot of time/effort.
I don't see it as a big compatibility issue.  If this be put in as a 
"bodyhash=" tag (yes, we'd use a single letter, but never mind that for 
now), a verifier could simply tell by the absence of that that this is 
an allman-01 signature, and could easily verify it anyway.  We could 
even put a non-normative suggestion in the spec to that effect.
So it seems to me that this doesn't harm existing implementations, 
because it provides a smooth transition and not an abrupt 
incompatibility.  And it seems to me that it provides some useful 
benefits.  As a participant, I support it.
Mike, rebuttal?
Others, comments?  Are others worried about this introducing a damaging 
incompatibility?
Barry

--
Barry Leiba, Pervasive Computing Technology  
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html