[ietf-dkim] 1193 considered harmful

[Michael Thomas]

Stephen Farrell wrote:
> Michael Thomas wrote:
> 
>> 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.
> 
> 
> You are correct that this is an enhancement and not a bug-fix.
> 
> But if the WG consensus turns out to be for it, then that's
> where we end up, right?

During the chartering phase, the key concern that I -- and I
think many others -- was introducing gratuitous backward
incompatible changes from allman-01. To date, we've contemplated
two changes:

1) use of relaxed over nowsp
2) sha-256

Both security related. Both _necessary_.

>> 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. 
> 
> That's a fair position. Others may disagree, equally fairly.
> 
> However, given that we have agreed to basically move to sha256,
> signers who use sha256 will be signing incompatibly with allman-01
> verifiers so I don't see why this change would be significant,
> following on from that change.

I don't consider sha256 a very good counterpoint: we're making
that change because we _have_ to, due to forces outside our
control. This change is in our control, however.

As I said, this would set the barrier for incompatible changes
*much* lower than before, and I worry greatly about the stability
of the spec were that to happen.

>> Having a way to detect which broke -- header or body -- does not
>> require breaking backward compatibility.
> 
> 
> Sort-of. Adding the putative "X=" header-hash you mentioned would
> also require a verifier to do more than allman-01, so detecting
> which is broken would require a verifier change, although such
> signatures would remain compatible with allman-01 as you point
> out.

It does not break current implementations though. As Murray
and Arvel's implementations can attest. The current proposal
will break all of our implementations. Needlessly, IMO.

		Mike, who is not even sure that
		 we really need anything along these
		 lines long term, which is why I never
		 brought up my header hash hack up as a
   		 possible addition to -base.