[ietf-dkim] over-the-wire (in)compatibility between pre-IETF
DKIM and (eventual) IETF DKIM
stephen.farrell at cs.tcd.ie
Mon Oct 17 01:11:32 PDT 2005
Dave Crocker wrote:
> newest Draft Charter:
>> the DKIM working group will make every reasonable attempt to keep
>> changes compatible with what is deployed, making incompatible changes
>> only when they are necessary for the success of the specifications.
>> I don't believe there is a
>> requirement for the dkim standard protocol to be backwards
>> compatible on-the-wire with what's deployed today, but rather
>> that the dkim standard be such that it's not a problem to migrate
>> from today's deployments or perhaps even to run them in parallel.
> Folks have been expressing support for the new charter text. I'm
> inclined not to perturb that, but have a continuing concern that forces
> me to probe one issue: We should make sure that there is a reasonably
> clear view of priorities for preservering installed base... or not.
I agree. I think the clearer we can get on that, the fewer arguments
about this that there'll be (though there'll always be some:-)
But, I think the charter text is fine btw.
> Is it ok with folks to be required to replace essentially all of the
> current software, administration and user deployment?
That's three things.
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?
Once that happens, many further changes have no additional impact
on incompatability, but of course, all changes do need to be
Secdondly, how admin is done isn't really part of these protocols,
except to the extent that an argument can be made that such-and-such
a proposed change makes admin of both old and new harder. Such
an argument is valid, but of course, its impact varies depending
on how many implementations are affected, where the proposed change
sits on the "nice"..."REQUIRED" dimension etc. So we can't settle
such arguments in advance.
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.)
If there're other relevant aspects of deployment (or "incompatbility")
that we ought be considering when someone proposes a change, It'd be
really good to describe them now.
> 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"
> Both are views reasonable, depending upon community need. My guess is
> that the IETF's version of DKIM will deploy in about a year, if we are
> lucky. So that the migration disruption would occur around then, and go
> for a year or two.
> (For reference, the DKIM pre-IETF effort similarly debated this point
> extensively, relative to DomainKeys compatibility. It's never an easy
You're right. There are a range of reasonable views here, but as in
most such situations, those on the far-right and far-left are far
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
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? ...
> ietf-dkim mailing list
More information about the ietf-dkim