[ietf-dkim] 1193 considered harmful

[Michael Thomas]

Barry Leiba wrote:
>> 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.

Well for one very big reason: it doesn't break current interoperability.
As I understand the proposal -- and there's nothing written down, so
sorry if I get this wrong -- you:

1) bodyhash=SHAx(body);
2) SHAx(h=headers)
3) SHAx(DKIM-SIGNATURE where (B=bodyhash));

This is very different from the current method, and a naive receiver
would *not* compute the new signature correctly.

The method I outlined -- and have implemented for around 6 months
or so -- does not break backward compatiblity and achieves the goal
of determining if the breakage is in the headers 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.

But is any of this worth breaking backward compatibility? I don't think
so. We considered a *lot* of these issues in the days leading up to the
merger of DK and IIM, I really don't see a very compelling reason to
change them again.

I'm fairly certain that the header hash can provide this short cut as
well, though I'm not sure that it's worth it.

> 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.

If my receiver as it stands today cannot verify a signature with this
proposal, it is _not_ backward compatible. Also: multiple different
methods of achieving the same functionality is the enemy of security
protocols (or, arguably, all protocols).

> 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.

If this breaks receivers as they exist today, I see a lot of harm.

		Mike

> 
> Mike, rebuttal?
> Others, comments?  Are others worried about this introducing a damaging 
> incompatibility?
> 
> Barry
> 
> -- 
> Barry Leiba, Pervasive Computing Technology  (leiba at watson.ibm.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