Subject: Advance request for opt-in and experiments

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 6 Jul 2006 09:58:36 +0200

Hello Mark,

This is a proto request for two documents. Olaf Kolkman will be
the shepherd for both.

Please publish draft-ietf-dnsext-dnssec-experiments-03 on the standards
track and publish draft-ietf-dnsext-dnssec-opt-in-09 as an experimental
rfc.

Questions:

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

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Sam Weiler <[email-masked]>
Date: Thu, 6 Jul 2006 09:26:32 -0400 (EDT)

The wildcard section (4.1.3 in opt-in-08) appears to have disappeared 
in opt-in-09, and I'm not recalling the WG's discussion of that. 
Would someone kindly refer me to it?

-- Sam

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

---

From: Roy Arends <[email-masked]>
Date: Thu, 6 Jul 2006 17:51:53 +0200

> Would someone kindly refer me to it?

That section was wrong and redundant. Wrong because that specific section 
dealt with full opt-in (not delegation only opt-in). Redundant since the 
issues surrounding opt-in and wildcards is covered in section 8 as well.
Section 4 discussses Protocol Additions, while section 4.1.3 in opt-in-08 
explained a security consideration.

The original reason for section 4.1.3 was that it seemed that the use of 
opt-in and wildcards are a special corner case. It is _not_ a special 
corner case. 

An opt-in span may contain unsigned delegations (i.e. onwernames that only 
own NS records, not any other records). Section 8 (security 
considerations) explain the security issues surrounding unsigned names. In 
particular, this means that a malicious entity may be able to insert or 
delete records with unsigned names.  These records are normally NS 
records, but this also includes signed wildcard expansions (while the 
wildcard record itself is signed, its expanded name is an unsigned name), 
which can be undetectably removed or used to replace an existing unsigned 
delegation.

(last two sentences are quoted from section 8).

Hope this helps.

Roy

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 7 Jul 2006 14:23:37 -0700

> [mailto:[email-masked]] On Behalf Of David Blacka

> No, I think that you just aren't accepting the opt-in tradeoff.

I think that what he is doing is asserting that the group should determine whether the tradeoff is acceptable for all parties and for all time rather than leaving this judgement to the people actually responsible for the infrastructure in question.

At present DNS is not secured in any shape or form and that is a problem.

As an intended consumer of the security provided by DNSSEC I would prefer the group to stop arguing over the terms on which parties are to be graceously permitted to deploy. After ten years the group still thinks of its role as a gatekeeper and not as it should do as an advocate.

Given the current state of deployment the response to any proposal intended to accelerate deployment should be 'that will do nicely' and not 'we will think about it'.

It will be at least a decade before the type of problems being discussed here are going to represent the weakest link in DNS. If this does happen we know how to fix them.

If people are genuinely concerned about the state of DNSSEC security then they should start work on the practices issues surrounding the registration process. That discussion cannot start until this set of discussions is concluded.

There has been enough discussion of OPT-IN to issue an Experimental RFC.

---

From: Edward Lewis <[email-masked]>
Date: Sat, 8 Jul 2006 11:57:00 -0400

>>  No, I think that you just aren't accepting the opt-in tradeoff.
...
>There has been enough discussion of OPT-IN to issue an Experimental RFC.

1) I have said that this document ought to go forward as Experimental.
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00914.html, 
and search for "I've said it earlier that I have no problem with this 
as an experimental document"

2) But experimental isn't really enough, is it?  If this stuff is to 
be real, we want it to be on the standards track.

3) The difference between experimental and standard is that in the 
former there are still questions (that's why it's an experiment).

If there's any expectation that something that's ready for 
experimental ought to never be discussed again, then is experimental 
being used as a way to route around the standards track?

Once the RFC gets stamped as an experiment by the IESG, only then do 
we begin to experiment and then review the results.  Otherwise, why 
are we even bothering with this (experimental) process?

By calling for an end to discussion, do you think that there's no 
need for an experiment and we ought to go straight to standards track?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

That tournament in Germany.  What's all the fuss?  (Get it? "fuss?")

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 8 Jul 2006 15:35:04 -0700

I am not going to get into this argument.
 
The experiment will provide the data necessary to solve the argument.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Edward Lewis
	Sent: Saturday, July 08, 2006 11:57 AM
	To: IETF DNSEXT WG
	Cc: David Blacka-CR; Edward Lewis
	Subject: RE: Advance request for opt-in and experiments

	...

	1) I have said that this document ought to go forward as Experimental.
	(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00914.html, and search for "I've said it earlier that I have no problem with this as an experimental document"

	2) But experimental isn't really enough, is it?  If this stuff is to be real, we want it to be on the standards track.

	3) The difference between experimental and standard is that in the former there are still questions (that's why it's an experiment).

	If there's any expectation that something that's ready for experimental ought to never be discussed again, then is experimental being used as a way to route around the standards track?

	Once the RFC gets stamped as an experiment by the IESG, only then do we begin to experiment and then review the results.  Otherwise, why are we even bothering with this (experimental) process?

	By calling for an end to discussion, do you think that there's no need for an experiment and we ought to go straight to standards track?