[ietf-dkim] over-the-wire (in)compatibility between pre-IETF
DKIM and (eventual) IETF DKIM
stephen.farrell at cs.tcd.ie
Tue Oct 18 05:03:19 PDT 2005
For me this is boiling down to whether or not the wg is allowed
to change the signature construct, or prevented by the charter
from so-doing, but read on...
Dave Crocker wrote:
> (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.)
I agree and I think that this thread is useful.
>>> 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.
Nope. I meant that you conflated the three things, thus allowing a
careless reader to get confused and end up believing that a change
affecting one must affect all three. I think its worth avoiding such
potential confusion, since e.g. we could change the signature construct
and yet have no impact on admin, nor existing deployments.
>> 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?
You didn't answer the question. I personally don't believe it's at
all likely that we'll end up with a standard signature format that's
verifiable by an old verifier. Do 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.
The focus of this thread is on exploring what "compatiblity" means,
as used in the charter. Yes, its true there've been no decisions on
those things, but I've yet to see a standardisation process that
didn't end up changing something about the signature construct - was
BTW - I thought there was already consensus on changing the c14n?
There is at least medium/strong support on the list so far for that
change to the signature construct. So, such changes are really quite
likely, unless they're ruled out of order by what I'd say would be
an overly constraining charter. (I don't believe the currrent draft
is such a charter btw.)
> 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.
I don't see any problem here - why wouldn't the upgrade be able to
support both new and old? (Assuming that the key/policy data for
"new" is compatible with the key/policy data for "old"?)
Later on, you say that "dual stack" is an issue. I disagree, but
would welcome seeing evidence to the contrary.
> contrast, requiring both senders and signers to change, in order to
> interoperate, is a massive barrier to entry for the installed base.
What would cause both to change? The new signer can just emit two
signatures if they care. Otherwise I don't see how a new signer can
possibly know what verifiers are out there, so the consequence would
be that the wg cannot change a single bit of the signing construct
and that I find unacceptable.
For an old signer, the new verifier can just include the s/w for
old sigs, if they know how.
So I believe it is true that new signatures will 99% likely
require new verifiers, but false to say that new signers require
> 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
I can't believe there's a real requirement there that isn't better
handled via s/w engineering. If the uprgaded receiver is willing to
accept pre-standard formated signatures, then let him (his s/w) do
so. There's no problem there afaik, as was pointed out by Arvel in
a mail a few days ago.
>> Secdondly, how admin is done isn't really part of these protocols,
> Well, that's just plain wrong.
No its not. We're not telling folks how to add that new DNS information
which, for me, is the "admin" part of this work.
> We aren't telling folks how to add the
> new DNS information,
Oh. You agree with me. Good.
> but we *are* deciding to use the existing installed
> admin and ops base of experience for the query service.
I believe we need to be very careful if something we do is likely
to make *data* already in DNS less useful than it currently is. We do
not need to care nearly as much about the tools that were previously
used to put that data there. However, I'd like to hear specific
reasons if there's some real issue with such legacy tools that we
ought to be caring about.
> 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.
Hey we agree again. Good.
>> 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.
It is "compatible" - the problem seems to be that you and I have
different readings of that word.
> However I still see your note as having defined a different metric.
You do. I don't.
Another question for you, maybe this'll get us closer to understanding:
Do you read the new charter as effectively implying that the wg cannot
change the signature construct, with the result that standard signatures
would in fact be verifiable by pre-standard verifiers?
If so, I have a major problem with that, and would like the charter
text changed to make it clear that the WG is chartered to produce
a standard without such a millstone (not milestone:-) around its
(Note: Please don't answer assuming gratuitous changes. This discussion
is only useful if we stick to assuming reasonable changes which might
get consensus backing, e.g. c14n or the digest thing.)
>> 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.
Where's that written down? It'd be quite a useful piece of text if
we could get that agreed.
Should we add that to the list of things that are specified in the
threats/requirements document? (Thus broadening its scope somewhat.)
I'm not sure myself, but I'd love to see that text somewhere.
>> 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.
I don't agree with that as a "should" goal. I think it'd be nice but
no more since it IMO would place far too many restrictions on what the
WG could reasonably do.
More information about the ietf-dkim