Dave,
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:
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.)
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
there one?
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.
> By
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
new verifiers.
> 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.
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"
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.
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
neck.
(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.
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org