DNS Security (DNSSEC) Opt-In
RFC 4956

[Ballot comment]
I think the working group faced a tough challeng here.  There were plenty of folks, myself included, who objected to opt-in on the grounds that it violated the principle of least surprise for applications that were expecting a "no" to have a reliable semantic.  I think the issues faced by large, flat zones are real, though, and that the working group met the challenge in a reasonable way--by making it possible to distinguish between those zones where the "no" has the expected semantic and those where it did not.  As the basis for further experimentation, this enough to see what troubles this creates in APIs and applications.

I do think this is enough for a proposed standard, and I would not support it as a change to the base semantics of dnssec.  After reflection, I do believe that this is enough to run a successful
experiment.  I wish more of the later decision making process were already sketched out, but that is a matter for charter and DNSSEC chair activity.

[Ballot comment]
Opt-in allows a zone owner to avoid signing unsecured delegations,
  avoiding a huge number of digital signature operations in
  delegation-heavy zones (like TLDs) in which most of the delegations
  are unsecured.  Opt-in allows unsecured delegations to be spoofed
  and it allows new unsecured delegations to be inserted.

  In 2003, the DNSEXT WG failed to reach rough consensus on publishing
  opt-in on the standards track.  As I understand the result of this
  exercise, the DNSEXT WG was going to add some statement to the
  introduction of the document to indicate that they did not reach
  consensus to the content of this document, and then publish it as
  an informational RFC.  That never happened.
 
  I do not see how this experiment will lead to a better understanding
  of the security implication of opt-in.  I do not think we should
  experiment with the security model of DNSSEC.  Changes to the
  security model of DNSSEC require consensus.

[Note]: 'Still in WG; no consensus to advance on standards track, continuing discussion on how to publish (info vs. experimental) and what sort of  explanatory note to include.' added by Mark Townsley

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

[Note]: 'Still in WG; no consensus to advance on standards track, continuing discussion on how to publish (info vs. experimental) and what sort of  explanatory note to include.' added by Margaret Wasserman

Still in WG; no consensus to advance on standards track, continuing discussion on how to publish (info vs. experimental) and what sort of  explanatory note to include.