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(_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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html