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

From: Thomas Narten <[email-masked]>
Date: Wed, 08 Mar 2006 13:49:27 -0500

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?

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

Only "MIGHT have"?

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

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

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

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

Thomas

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