DNS Security (DNSSEC) Experiments
RFC 4955

Told Mark this:

I'm not sure I want to hold a discuss on my item for years.
Not worth it. Is something happening in the WG? If not,
maybe we should just let this slide...

[Ballot discuss]
>  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 a non-validatable response and conclude
>      that the response is bogus, either due to local policy or
>      implementation details.  This is not expected to be a common
>      case, however.

I would like to understand more about what the
"some circumstances" are. If the author or WG
knows some situations where this can fail, please
state it explicitly.

[Ballot comment]
I was surprised to see this going for PS and not BCP. IMO
  this document describes the best current practice methodology for
  setting up DNSSEC experiments and should go for BCP.

Section 4., paragraph 1:
>    having only unknown algorithm identifiers in the DS records for the
>    delegation to the zone at the parent.

  Nit: expand DS on first use.

[Ballot discuss]
Section 4., paragraph 6:
>    While this behavior isn't strictly mandatory (as marked by MUST), it
>    is likely that a validator would implement this behavior, or, more to
>    the point, it would handle this situation in a safe way (see below
>    (Section 6).)

  DISCUSS: If this isn't the REQUIRED behavior, then basing a standard
  methodology for experiments on it is problematic, because it means
  that standard-compliant resolvers that happen to have a reason to
  disagree with the SHOULD will have issues. This is discussed in
  Section 6, consideration 1, below, but I don't agree with the
  conclusion that because this isn't expected to be a common case it's
  OK to base a methodology for all future DNSSEC experiments on it. (I'm
  unfortunately not sure how to make this DISCUSS actionable at this time.
  Maybe I'm misunderstanding something about this proposal?)

[Ballot comment]
Please rename section 6.  A reasonable title might be
  "Experiment Considerations".

  From the SecDir review by Stefan Santesson:
 
  Section 5 states:
  >
  > Resolvers MUST only recognize the experiment's semantics when
  > present in a zone signed by one or more of these algorithm
  > identifiers.
  >
  Strictly speaking, nothing is signed by an algorithm identifier.
  It seems that the text tries to say:
  >
  > Resolvers MUST only recognize the experiment's semantics when
  > present in a zone signed with one or more algorithms identified
  > by these algorithm identifiers.

[Ballot comment]
Editorial points from Gen-ART review by Francis Dupont,
with author comments.

>> Minor points (they should be fixed by the RFC Editor):
>>  - in 1 page 3: a missing closing parenthesis. I suggest to add the
>>    number of the RFCs too.

Sounds good.

>>  - is "validatable" (in 4 page 7 and 6 page 9) a correct English word?

Er, I guess not :)  I suggest rewording (from 4 on page 7):

  That is, a zone is either in an experiment and only experimentally
  validatable, or it is not.

with

  That is, a zone is either in an experiment and only possible to
  validate experimentally, or it is not.

And suggest rewording (from 6 on page 9):

  For instance, the resolver may look at a non-validatable response and
  conclude that the response is bogus, either due to local policy or
  implementation details.

with

  For instance, the resolver my look at a response that cannot be
  validated and still conclude that the response is bogus, either due to
  local policy or implementation details.


>>  - in 10.2 page 13 reference [6] is obsolete: a new version 03 was
>>    submitted in June.

PROTO Write-up

1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?

Yes we have reviewed both document.


2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

Yes.

draft-ietf-dnsext-dnssec-opt-in has quite a long history and thorough
and in-depth discussion a few years ago also see below. Both opt-in
and dnssec-experiments have been last called together and were
reviewed (among others) by:

Sam Weiler
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00576.html)
Ed Lewis
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00440.html)
Andrew Sullivan
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00330.html)
Mark Kosters
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00309.html)
Thierry Moreau
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00305.html)
Scott Rose
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00316.html)
Rodney
Joffe(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/
msg00335.html)
Thomas Nartan (thread starting at:
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00308.html).


3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No we do not.

4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.

It is probably good to have some historic background on the documents.

The OPT-in document has been around for a long time. In 2002 it lead
to heated debates which resulted in a conclusion that opt-in was
technically solid but there was no rough consensus to add opt-in to
the spec.
(http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01007.html)

The chairs then suggested to make sure that opt-in did not end up as
an I-D tombstone but was to be published as informational
draft. Adding the boilerplate has been on the WG todo list for a very
long time.

In the mean time the working group has created DNSSECbis and has
thought about the possible transition mechanisms to DNSSEC-ter (for
deploying NSEC3). One of the possible transition mechanism can also
be used to run experiments on production systems without interfering
with production data. This technology has been described in the
dnssec-experiments draft.

After dnssec-experiments was published as an I-D, the editors of
OPT-IN (also the editor of opt-in) suggested to update OPT-IN to fit
in the frame work of dnssec-experiments, in other words opt-in being
the first application of dnssec-experiments.

Currently the OPT-IN technology is making its comeback in the NSEC3
specification. Times seem to have changed since OPT-IN does not seem
to be as contentious as 4 years ago.


5) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with
it?

We think it is solid. Active members are aware of this document and
key members of the working group have reviewed the documents. There
were no objections raised against the document. There was some
clarification work needed after version of 'experiment' and version 8
of 'opt-in.


6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No. See the history above.

7) Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

yes

8) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:


draft-ietf-dnsext-dnssec-experiments

This document describes how algorithm identifiers can be used to
perform experiments within a DNSSECbis environment without that the
published data is marked as "bogus" by validating resolvers that do
not partake in the experiments.

The document explains why this methodology works and describes how
experiments are to be defined.

Besides, it suggests that algorithm identifiers can be used to
introduce non-backward compatible DNSSEC features into the
protocol.

The first application of this methodology will be an experiment with
"opt-in" [draft-ietf-dnsext-dnssec-opt-in]. It is possible that the
methodology will be used for the introduction of current DNSSEC
extensions currently under development in DNSEXT, the NSEC3 work.


draft-ietf-dnsext-dnssec-opt-in

opt-in is a method to disable the authenticated denial of existence
for a range of domain names in a zone. It has been developed to
generate a sparse set of NSEC RRs in a zone that contains mostly
delegations i.e. to opt-in the secure delegations. The span of
delegations for which authenticated denial is not available is still
indicated using an NSEC resource record. 'NSEC-bit' in the type
bitmap of the NSEC RDATA is used to signal the different semantic of
the opt-in type NSEC RR.

opt-in is a methodology that is backwards incompatible with DNSSEC; in
order to perform a trial the methodology described in
draft-ietf-dnsext-dnssec-experiments is applied.



--Olaf