[ietf-dkim] 1193 considered harmful

[Michael Thomas]

Barry Leiba wrote:
>> This is very different from the current method, and a naive receiver
>> would *not* compute the new signature correctly.
> 
> 
> That's correct; it would not -- the verifier would have to change to add 
> this method of verifying, and could remove support for the allman-01 
> version when it's satisfied that it's not seeing them any more.
> 
> You (Mike) clearly see this as more of a problem than I do.  The 
> compatibility I want to be careful to maintain is this:
> 
> 1. Continue to be able to use existing DNS records.
> 
> 2. Make the transition to the IETF spec easy by making sure that 
> verifiers can verify both old and new sigs without much difficulty, and 
> that signers can, therefore, make their transition when enough verifiers 
> have done theirs.

I find this "enough" to be an *extremely* squishy concept. When is
"enough" enough? How can a signer determine such a thing? Who would
be brave enough to go first? We have to keep in mind that email has
no feedback loop, so it is *extremely* prone to entropy.

My understanding in the chartering phase is that there was a great
deal of desire to not make backward incompatible changes unless they
were really, really needed. Ie, for things like security botches, and
the like. This is much more of an enhancement and to my mind a fairly
marginal one at that. Consider this: this will be setting the
precedent on what is acceptable for breaking backward compatibility.

>> 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.
> 
> 
> But it doesn't do any of the other nice things that I outlined.

> What would allow it, with no transition needed, would be to hash the 
> body and put it in the header tag... and then continue to do the 
> full-message hash as now.  I think that's a non-starter, though, because 
> it requires hashing the entire body twice (once by itself, and once with 
> the header stuck on).

I'm far from convinced that _any_ permutation of this is worth breaking
backward compatibility. None of the reasons you gave seem compelling to
me. Having a way to detect which broke -- header or body -- does not
require breaking backward compatibility.

		Mike