[ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

[Dave Crocker]

Stephen,

(Folks -- This sort of exchange is exactly why I decided to burden the 
list with my concern.  I believe that it is important that we get as 
much group alignment (consensus) about the "strategic" goals and 
requirements for this standardization process as possible, as early as 
possible.  I believe it will spare us enormous amounts of debate and 
misunderstanding, as we pursue the protocol details, since we will at 
least share a common base of expectations for the results.)

>
>
>> Is it ok with folks to be required to replace essentially all of the 
>> current software, administration and user deployment?
>
> That's three things.

right.  bigger impact.  that was my point. ensuring upward compatibility 
for an installed base can get messy.

>
> First, the current s/w will have to change since we're changing
> the signature construct (c14n & maybe the digest thing). Since
> its signing, a single bit is enough to require new s/w anyway
> and there's 99.999% certainty that we'll at least change
> one bit in an on-the-wire imcompatible way. Don't you agree?

1. "we're changing the..." ??  I have seen discussion about these 
things, but was not aware that there had been community rough 
consensus.  I thought the current focus was on threat analysis and 
chartering, rather than making technical decisions.

2. Incompatibility comes in a variety of forms.  I think that for our 
purposes, the most significant different is between a change that 
permits senders to continue with their old behaviors (over the wire) and 
still have signatures work for receivers who have upgraded.  By 
contrast, requiring both senders and signers to change, in order to 
interoperate, is a massive barrier to entry for the installed base.  So, 
for example, adding the exposed hash in the signature header field does 
not mean that a receiver can't process a signature that is lacking the 
hash.  By contrast, making the new spec unable to process an older 
canonicalization algorithm breaks mail from a sender using the original 
DKIM.


> Secdondly, how admin is done isn't really part of these protocols,

Well, that's just plain wrong.  We aren't telling folks how to add the 
new DNS information, but we *are* deciding to use the existing installed 
admin and ops base of experience for the query service.

Choosing DNS as the query service was a significant, strategic benefit 
because it re-uses existing admin and ops methods.  There are 
incremental changes, to support the new data, but no changes for 
supporting the underlying query service.  This is a massively Good Thing 
and it is mostly about admin and ops.


> Thirdly, I'm not sure exactly what you mean by "deployment", but if
> you mean that the (distributed, virtual) database of policies and
> public keys SHOULD still be usable with the output of DKIM, then
> I'm totally sympathetic with that. (Using some new optional feature
> of the standard might require adding new policy data of course, but
> that doesn't break existing deployment, in the sense above.)

I think you have captured the distinction I am trying to draw, about the 
differences in the degree of barriers to adoption.

Mostly I listed development, admin and user deployment in order to 
stress the degree of impact that changes have.  A change that is 
strictly procedural to the administration process well might require no 
new software and well might be invisible to users and even invisible to 
the receive-side DKIM software.  One can invent all sorts of changes 
that have much bigger, more disruptive and extensively visible impact.  
(For example, moving the signature header field into the body...)


>> The new draft charter would seem to impose a very high barrier on 
>> changes that render the new specifications incompatible with existing 
>> implementations.  It's language is similar to that of other IETF 
>> efforts that seek to minimize incompatibilities.
>>
>> However Stephen's comment creates a much, much lower barrier, and is 
>> concerned only with stored data that are queried.
>
> That's taken out of context - I was trying to get to the strongest
> requirement for what-not-to-break. There is no "much lower barrier"
> here.

I didn't mean to take anything out of context.  I assume folks have read 
your note in its entirety and I was offering my opinion of that entirety. 

I thought/think I did understand what you wrote and took it to define 
acceptable incompatibility at a particular point that struck me as 
substantial.  If your statement was meant to be entirely compatible with 
the new draft charter text on this, I'm sorry for the misunderstanding.

However I still see your note as having defined a different metric.


> So while we don't have a precise definition of "incompatible" (and
> probably never can, at least not in something the length of the
> charter), I think the situation's nearly as clear as we can get it
> for now.

On the other hand, we CAN specify what interoperability scenarios, 
between existing DKIM and IETF DKIM, we intend to support.


> PS: I still didn't hear much about what specific parallel scenarios
> we'd like to support btw. e.g. if a single message can have both
> new and old signatures from the same domain, do we require that
> the same public key be usable to verify both, or should we remain
> silent on that, or something else? And which of those signatures
> should encapsulate the other, or do we care? ... 

My own opinion is that an existing DKIM sender should be able to send an 
original DKIM signature to a receiver who has implemented IETF DKIM and 
the receiver should be able to successfully validate the signature, 
without having to implement anything that looks like a parallel stack.  
That is, they should be able to take the new IETF DKIM specifications, 
implement it, and be able to process original DKIM signatures. 

d/