Subject: Re: Reminder: WGLC dnssec-experiments and dnssec-opt-in

From: David Blacka <[email-masked]>
Date: Mon, 13 Mar 2006 16:10:10 -0500

On Mar 8, 2006, at 1:49 PM, Thomas Narten wrote:

> Sam Weiler <[email-masked]> writes:
>
>> It is _not_ just experimenting with new algorithms, nor is it for
>> experiments with non-DNSSEC parts of the protocol.
>
> OK.
>
>>  We're talking about experimenting with DNSSEC flavors, extensions,
>> and bad ideas.  The unknown algorithm tells DNSSEC-aware resolvers
>> that aren't part of the experiment "you don't know what's going on
>> here -- just ignore any DNSSEC bits you see in this zone and treat
>> it as unsigned".
>
> And for those resolvers that do understand the particular flavor, it
> is saying "do flavor X" of DNSSEC here. And since it doesn't make
> sense to do "normal" DNSSEC and "flavor X" simultaneously, this is
> what is being described as another "different version" of DNSSEC?

Yes.

>> Classic examples include NSEC3 and opt-in.  We MIGHT have been  
>> able to
>> use this method to test DS (RFC3658).
>
> Only "MIGHT have"?

Well, the rules that this technique rely on postdate DS.  So I assume  
Sam was using MIGHT in the sense that had things unfolded differently...

>> We could also use this method to signal a change in typecodes
>> (RFC3755), though the new typecodes would probably be used as part
>> of some larger experiment (like NSEC3).
>
> Again, the basic point here is that "flavor X" can mean whatever "X"
> is defined to be, and the normal DNSSEC rules don't apply.

Yes.

>>>>    2.  It will not be possible for DNSSEC-aware resolvers not  
>>>> aware of
>>>>        the experiment to build a chain of trust through an
>>>>        experimental zone.
>>>
>>> Can't an experimental zone co-exist with a regular zone (i.e., one
>>> using a standard signature)? If so, the above wording seems wrong.
>
>> In general, no.  There is only one zone.  It may use no DNSSEC,
>> "standard" DNSSEC, or some "experimental" DNSSEC.
>
> Why can't a zone use both "standard" and "experimental"? I.e., signed
> different sets of keys/algorithms, as the document says up front? That
> is, any one resolver choose one or the other (but not both) for a
> particular zone. If that is the case, both can co-exist, though the
> defn. of coexistance is maybe different that you are thinking of.

Honestly, I'm not sure how to answer this.  Right now, I think I have  
to say that the reason why a zone can't serve both normal and  
experimental DNSSEC at the same time is that there is no way for the  
server to know which to serve.  That is, there is no way for the  
resolver to signal to the server which set of semantics to use.

One could construct such a proposal, I suppose, but that is not the  
purpose of this draft.

>> It may be that the extension is backwards compatible, allow a zone
>> to be validated by both "standard" and "experimental" resolvers at
>> the same time, but I imagine that to be an exceptional case.
>
>> Example: a zone could publish (and return) both NSEC and NSEC3 RR's,
>> potentially allowing it to be validated by both "standard" and  
>> "NSEC3"
>> resolvers.  But the mechanics of doing that might prove challenging.
>
> Here is the rub. This technique allows zones to identify extensions
> that only extension-aware resolvers will process. But it does not
> really allow DNS servers (e.g., those in zones implementing the
> experiment) to know they are talking to "experiment-aware" resolvers
> and thus return answers appropriate for implementors of the experiment
> (but not others). So there are some clear limitations here. If one
> has a zone only implement standard DNSSEC or "experimental flavor"
> DNSSEC, no problem.

Well, that is the situation that the draft describes.

The experimental technique described by the draft should work  
*today*.  Right now, there is no way for a resolver to reliably  
signal anything to a (possibly-more-than-one-hop-away) resolver  
without a widespread protocol change.

> It might be good for the document to say a bit more about these
> limitations.

I'll see what I can do, but this sort of feels to me like starting to  
document the infinite list of things you can't do.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Sam Weiler <[email-masked]>
Date: Fri, 17 Mar 2006 16:27:26 -0500 (EST)

David answered most of this, but I'll go ahead and add my perspective.

On Wed, 8 Mar 2006, Thomas Narten wrote:

>> We MIGHT have been able to

Yes.  Recall that DS changed the signalling at the zone cut, so we'd 
at least need a slightly different variant of this mechanism that 
worked with the last signaling semantics (SIG@child).  I suspect that 
would have been tricky, at best.

In the process of testing DS, we also found some interesting issues 
(e.g. "Jakob's bug") that MAY have existed with SIG@child code, also. 
We may not have been able to work around those with a signaling 
mechanism as "gentle" as this -- a typecode roll was (arguably) 
needed.

> defn. of coexistance is maybe different that you are thinking of.

It could be that it's impossible to generate a zone that works with 
both "standard" and "experimental" (that may be the case with NSEC and 
NSEC3, where there might be an unresolvable circular dependence). 
And as you talked about later in your post, there's no way for a 
resolver to signal which "version" of the zone it wants.  Doing so 
would have some interesting implications for caching.

> (but not others).

Correct.  And the DNS caching architecture pretty much requires this. 
Otherwise each intermediate resolver would need to be able to cache 
multiple sets of data (one set per experiment) and respond to clients 
accordingly.  We already agreed that it was okay to require a "clear 
path" of exclusively DNSSEC-aware resolvers and middlesboxes between 
authoritative servers and resolvers -- we don't want to impose that 
constraint separately for every experiment.

-- Sam