Subject: Scope of discussion (was Re: Proposal to fix NSEC)

From: Olaf Kolkman <[email-masked]>
Date: Sun, 23 May 2004 16:07:47 -0700

Dear Colleagues,

I would like to narrow the discussion.

With reference to an earlier message [1].

I think it is clear at this point that the current DNSSEC-bis protocol 
spec eases content enumeration; I think it is clear that this causes a 
number of TLDs (and other players) to believe that they cannot deploy 
DNSSEC in its current form.

Please refrain from further discussion of these two points; this is a 
real issue.

The question on the table is what this WG needs to do.

In my previous mail I have listed two possibilities. Taking up work to 
prevent zone enumeration while holding the DNSSEC bis document-set or 
shipping DNSSEC bis and forgetting about solving the enumeration 
problem. Off course there are other options. Ship the document 
DNSSEC-bis document set and work out the enumeration problem later (but 
commit on finding a solution).

The 3rd option may not be that bad given that DNSSEC-bis conforms to 
the requirements of a Proposed standard and that it is (should be) 
clear that Proposed Standards are subject to change (RFC2026, 4.1.1). 
If we go this route we have to realize that we have to field new 
technology that _may_ not interoperate with DNSSEC bis.

There may be other ways of going forward, stalling development of NSEC2 
but introduce a mechanism into DNSSEC-bis that introduces versioning of 
NSEC, if you see the signal you should expect the new features (say 
NSEC2) or treat the zone as unsecured. That would delay too, but maybe 
not that long.

Rough consensus is difficult to read from the current thread. It would 
help if you make your (motivated) position clearer and provide your 
arguments for taking one of the options. Do so before June 1.

Two additional remarks:

+ PLEASE REVIEW THE DNSSEC-bis DOCUMENT SET, review is orthogonal to 
this discussion.

+ Please remain courteous and discuss arguments on the quality of the 
arguments, qualities of the author are out of scope.

Thanks,

--Olaf Kolkman
    DNSEXT co-chair
    (Olafur is still away from keyboard)

[1] 
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00489.html

--
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: Paul Vixie <[email-masked]>
Date: Mon, 24 May 2004 01:07:42 +0000

> ...
> The 3rd option may not be that bad given that DNSSEC-bis conforms to the
> requirements of a Proposed standard and that it is (should be) clear that
> Proposed Standards are subject to change (RFC2026, 4.1.1). If we go this
> route we have to realize that we have to field new technology that _may_
> not interoperate with DNSSEC bis.

that's not realistic.  if dnssec-bis takes off and creates an installed base,
then there will be no incompatible changes to it between PS/DS/FS, and those
stages will just be used to refine the documents based on implementation and
deployment experience.  if dnssec-bis fails to take off for ANY reason, then
getting more funding or development, or being taken seriously when saying "we
really think we've got it right this time," has a likelihood approaching zero.

> There may be other ways of going forward, stalling development of NSEC2 but
> introduce a mechanism into DNSSEC-bis that introduces versioning of NSEC,
> if you see the signal you should expect the new features (say NSEC2) or
> treat the zone as unsecured. That would delay too, but maybe not that long.
> 
> Rough consensus is difficult to read from the current thread. It would help
> if you make your (motivated) position clearer and provide your arguments
> for taking one of the options. Do so before June 1.

i like "advance dnssec-bis as it is, and if someone wants to work on stopping
enumeration, let them commit to it and let them figure out how to sell it and
let them figure out whether selling it is made harder if it's not backward
compatible."

---

From: [email-masked]
Date: Sun, 23 May 2004 23:32:22 +0000

I'm in favor of shipping out the docs as currently written.

This does not imply that there are areas of the spec that don't 
need work. There are. But what we have now is "good enough" for
what is needed for those who are waiting for deployment.

To paraphrase Moses, "Let my docset go".

--bill

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 May 2004 20:24:34 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Olaf" == Olaf Kolkman <[email-masked]> writes:
    Olaf> The question on the table is what this WG needs to do.

    Olaf> In my previous mail I have listed two possibilities. Taking up
    Olaf> work to prevent zone enumeration while holding the DNSSEC bis
    Olaf> document-set or shipping DNSSEC bis and forgetting about

  Sigh.
  I hate to say this... if we are going to do this, let's do it *now*

  I suggest that some may want to go ahead with DNSSEC deployment
without NSEC.  If doing so, they should not have any NSEC records at all,
nor should their resolvers know what to do with them at this point.

  I think that the chairs should establish a firm time table for doing
this work. It should take no more than 5 weeks.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Vixie <[email-masked]>
Date: Tue, 25 May 2004 01:03:08 +0000

>   I hate to say this... if we are going to do this, let's do it *now*

technically i agree with this statement.  but if we were going to do this,
we should never have even considered standardizing NXT (ne NSEC), and i'm
concerned about vision creep... so concerned in fact that if we decide to
re-debate NO/opt-in/NSEC2, i'll wonder how we'll *ever* know that DNSSEC
is cooked-enough to stop tinkering with it.  (until last week, i thought
we knew.)

> nor should their resolvers know what to do with them at this point.

this is not realistic.  just as many people don't read drafts until WGLC,
many implementors and operators will not invest any effort in a standard
that's known to be an incomplete shadow of its future self.  i'm sure, for
example, that isc would have a hard time getting funding to develop code
that doesn't generate or look at NSEC, since authoritative denial of
existence was made a WG-level showstopper nine years ago.

> this work. It should take no more than 5 weeks.

this is also not realistic.  with dnssec, we can't call it "done" until
it's been extensively reviewed, modelled, and beer&pizza-tested, and for
something at the level of NSEC2 that will take six to 12 months.  that's
how we found "the grandparent problem" and that's how long it takes to
find, or be sure you're not able to find, problems of that subtle nature.

this debate is making it sound as if we don't know what dnssec is supposed
to do, or who it's going to do it for, or what are the concerns of the people
dnssec is supposed to do stuff for.  i just don't think that's all true.
but if i'm wrong, and dnssec is now a solution in search of a problem, then
i'd like to question the wisdom of spending any more time on it until the
problem is clearly known and explicitly agreed to by all possible stakeholders.
(which in other words means, until hell freezes over.)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 May 2004 17:57:03 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Olaf" == Olaf Kolkman <[email-masked]> writes:
     Olaf> I think it is clear at this point that the current DNSSEC-bis
     Olaf> protocol spec eases content enumeration; I think it is clear
     Olaf> that this causes a number of TLDs (and other players) to
     Olaf> believe that they cannot deploy DNSSEC in its current form.

  I disagree.
  Only bind ever gave them the feeling that content enumeration wasn't
trivial to begin with.

  If limiting things is desired, then someone needs to write those
requirements clearly, and then say that DNSSEC fails at them.

- --

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 May 2004 17:59:18 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:

    Paul> technically i agree with this statement.  but if we were going
    Paul> to do this, we should never have even considered

    >> I think that the chairs should establish a firm time table for
    >> doing this work. It should take no more than 5 weeks.

    Paul> this is also not realistic.  with dnssec, we can't call it
    Paul> "done" until it's been extensively reviewed, modelled, and
    Paul> beer&pizza-tested, and for something at the level of NSEC2
    Paul> that will take six to 12 months.  that's how we found "the

  Yeah, I agree.

  I don't want to pick up the NSEC2 work. I don't care about enumeration.
  But, if we have to do it, then we have to it now, and we have to
figure out how to do it quickly.  
  Yes, it requires beer, pizza and additional workshops. 

  Yes, that requires resources. If the NSEC2 proponents have the resources 
then perhaps they would step up to the plate on this.

- --

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 28 May 2004 16:12:33 +0200

Dear chairs, dear all,

> It would

DENIC (7,6 million DE-domains) is looking forward DNSSEC deployment, and 
that rather happening before secure islands appearing under DE may 
endanger the common namespace. However, DENIC will not be able to carry 
this deployment out with the form of the specification as it is today 
(because of a clashing of the NSEC traversal with [*]).

We would be willing to give green light to the current spec if the working 
group could commit to solving the NSEC traversal problem afterwards. Then, 
at that point, the form of the problem should be formalized and well 
defined, with our commitment to contribute to the process. The form of the 
solution (whether NO/NSEC2, or online signing of NXDOMAIN-answers, or 
optional use of NSEC or something else) probably can't be decided at the 
moment. We are aware that providing an open door to the future solution 
might require slight modifications of the current drafts.

Best,
Marcos Sanz
DENIC eG

[*] http://www.denic.de/en/faqs/allgemeine_faqs/index.html#section_185