[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Mar 8, 2006, at 5:50 PM, Thomas Narten wrote:


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.


No problem, your comments are still appreciated ;)


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"?
This document isn't about experimenting with anything in particular. It is describing a methodology for doing an experiment safely, not describing a particular experiment.
As for what exactly is being tested: section 3 is an attempt to define the basic boundaries of what sorts of things may be tested. However, I suspect that section 3 is too clumsily stated. 


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


Like draft-ietf-dnsext-dnssec-opt-in-08 ?
Since this is just documenting an approach for shielding unaware DNSSEC validators from non-backwards-compatible changes to DNSSEC it didn't seem appropriate to point to a particular experiment. 


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.


Fair enough.  How about reducing to just the last sentence?
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/


Yes, that sentence doesn't make sense, and your modification works fine.
DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment- a.example.com" is 
   an alias of DNSSEC algorithm 5 (RSASHA1).


same issue.


Ok.


   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.
No, that isn't the intent. The intent is to mandate that a resolver that understands the experimental semantics (e.g., the opt-in flag) only treats the response as signed if and only if the zone was signed only by one or more of the private algorithms.
Or, in other words, the resolver must treat the zone as unsigned, even though it could treat the zone as signed. 


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?
Well, technically no. The existing specs only use "SHOULD". The assertion in section 4 is essentially pointing out that while the specs say "SHOULD", it is effectively (or maybe just believed to be) a MUST. So this is basically a caveat that while this technique is *believed* to work, it might not.
OTOH, you can basically read this as "there may be bugs out there", which is, of course, obvious.
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.


No, it can't.




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.]
Really? I'm using "version" in the sense of protocol versioning. Does that not make sense? That sentence is not strictly necessary, so I'll delete it if it is unclear. 




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.
Well, to be precise, it only RECOMMENDS the use of private algorithms, it does not require them. And, if they aren't used, then IANA would need to allocate DNSSEC algorithm numbers.
So, Thomas, are you suggesting that the document REQUIRE use of private algorithm identifiers? 

--
David Blacka    <davidb@verisignlabs.com>
Sr. Engineer    VeriSign Applied Research




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