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

[Thomas Narten <narten@us.ibm.com>]

> > This working group last call will terminate March 15. We request at
> > least 5 people to state that they thoroughly read said documents
> > before we forward to the IESG.

High-level, coming from someone who may not be terrible DNSSEC savvy.

I'm a bit confused about exactly what one is testing under this
methodology. There is a lot of discussion about using a private
algorithm, in which case those not participating in the experiment
will simply not recognize the signature and ignore it. That part seems
fine.

But, what exactly is being tested here? Is it real modifications to
the DNS protocols (i.e., changing/extending semantics of existing
operatiosn)? Or is it _just_ experimenting with a new signing
algorithm?  Is the idea that knowing the private algorithm (which
often isn't really an unknown algorithm, since the purpose apparently
isn't to test new algorithms) provides a way of indicating that "the
DNS protocol behaves differently for names in this zone"? 

It might help to show a concrete example of an example extension
(e.g., a past proposal) that could be tested using this scheme.

Specific comments:

abstract says:

>    In the long history of the development of the DNS security extensions
>    [1] (DNSSEC), a number of alternate methodologies and modifications
>    have been proposed and rejected for practical, rather than strictly
>    technical, reasons.  There is a desire to be able to experiment with
>    these alternate methods in the public DNS.  This document describes a
>    methodology for deploying alternate, non-backwards-compatible, DNSSEC
>    methodologies in an experimental fashion without disrupting the
>    deployment of standard DNSSEC.

IMO, the first sentence can be struck completely, as it adds nothing
to the purpose of the document.  I also don't like the wording, since
I don't know the difference between "technical" and "practical"
reasons.

>    For example, an experiment might specify in its description the DNS
>    name "dnssec-experiment-a.example.com" as the base name, and provide
>    the mapping of "3.dnssec-experiment-a.example.com" is an alias of

parsing problem???
Perhaps: s/and provide the mapping of/and declare that/
      
>    DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
>    an alias of DNSSEC algorithm 5 (RSASHA1).

same issue.

>    Resolvers MUST then only recognize the experiment's semantics when
>    present in a zone signed by one or more of these private algorithms.

Awkword wording (and I am not sure at all MUST is appropriate here, or
indeed what it is that is intended to be said here.)  Do you mean
something like:

    Only resolvers participating in the experiment would recognize the
    experiment's semantics when present in a zone signed by one or more
    of these private algorithms.
 
> 6.  Considerations
> 
>    There are a number of considerations with using this methodology.
> 
>    1.  Under some circumstances, it may be that the experiment will not
>        be sufficiently masked by this technique and may cause resolution
>        problem for resolvers not aware of the experiment.  For instance,
>        the resolver may look at the not validatable response and
>        conclude that the response is bogus, either due to local policy
>        or implementation details.  This is not expected to be the common
>        case, however.

Odd to say this, since the above is essentially a violation of
existing specs, as indicated earlier. Right?

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


> 7.  Transitions
> 
>    If an experiment is successful, there may be a desire to move the
>    experiment to a standards-track extension.  One way to do so would be
>    to move from private algorithm numbers to IANA allocated algorithm
>    numbers, with otherwise the same meaning.  This would still leave a
>    divide between resolvers that understood the extension versus
>    resolvers that did not.  It would, in essence, create an additional
>    version of DNSSEC.

This is funny defn. of "version". [note: I think answering earlier
question will clarify my confusion here.]


> 9.  IANA Considerations
> 
>    IANA may need to allocate new DNSSEC algorithm numbers if that
>    transition approach is taken, or the experiment decides to use
>    allocated numbers to begin with.  No IANA action is required to
>    deploy an experiment using private algorithm identifiers.

Better (for IANA, and for this document):

   This document provides a way of experimenting with DNSSEC using
   the existing DNSSEC Private Algorithm Identifier space. No
   coordination with IANA is needed.
   
   This document has no IANA actions. 

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