[ietf-dkim] over-the-wire (in)compatibility between pre-IETF
DKIM and (eventual) IETF DKIM
dhc at dcrocker.net
Mon Oct 17 09:07:12 PDT 2005
(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
> 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"
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.
More information about the ietf-dkim