[ietf-dkim] 1193 considered harmful
mike at mtcc.com
Tue Mar 21 12:37:26 PST 2006
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:
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, rebuttal?
> Others, comments? Are others worried about this introducing a damaging
> Barry Leiba, Pervasive Computing Technology (leiba at watson.ibm.com)
> NOTE WELL: This list operates according to
More information about the ietf-dkim