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

[Dave Crocker]

>
>>>> 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.

The question was intended to ask about a limit of impact.  Affecting all 
3 would be the upper limit.  Complete change.  I was not trying to do a 
detailed questionnaire, asking about each increment of change that would 
be acceptable.


> I think its worth avoiding such
> potential confusion, 

ahh, well.  avoiding confusion is almost always useful...


>>> 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?

I see no reason, yet, that that incompatibility is required.  And I 
think that the impact of that incompatibility would be quite unfortunate.


>
>> 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?

"changing something" does not automatically imply that earlier signature 
forms cannot be processed by newer implementations.


>
> 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.)

And the reason for having the changes done so as to exclude the current 
DKIM forms, rather than as an increment to acceptable alternative forms 
is...?

(from your next comment, I suspect I've misinterpreted the effect you 
expect.)



>
>> 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?

right.  i hope it IS possible.


> Later on, you say that "dual stack" is an issue. I disagree, but
> would welcome seeing evidence to the contrary.

There are some important differences between implementing two 
specifications -- true, pure, dual-stack, versus implementing one that 
has some options.  Options are mostly dangerous for interoperability, 
but that's the price of protecting an installed base.

>> 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.

As I said, there are some important differences between implementing two 
specifications -- true, pure, dual-stack, versus implementing one that 
has some options.  Options are mostly dangerous for interoperability, 
but that's the price of protecting an installed base.

For one thing, new implementations are likely to implement "the 
standard" and not some earlier non-standard.  Individual implementors 
are not so likely to think of protecting the installed base, or think 
that implementing only "the standard" will prevent them from doing that.


>
>>> 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.

I explained exactly what I meant within the remainder of my paragraph.  
Had you not responded to it in such small segments, the point I was 
making about "strategic" admin choices within the specification would 
not have been lost.

So, no, I do not agree with what you originally wrote.

 
>> 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. 

Of course, but that is not what I was talking about.  Choosing to use 
the DNS has a lot to do with re-using existing admin and ops capabilities.

> 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.

Anything we do that requires new tools will require new training, beyond 
having administrators learn how to handle the new data.  Learning to use 
new tools is quite different from learning how to use existing tools in 
additional ways.


>> 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.

Maybe not.

Given the many components in making a global service, like this, there 
is quite a range of compatibilities at issue.

My guess is that we differ on how we prioritize the different 
compatibilities, rather than the basic semantics of the word.  (Maybe 
you meant what I mean, and maybe you meant basic semantics.  Not sure.  
In any event, it's the range of compatibilities that I think is the issue.)


> 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
>