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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 23 May 2004 17:25:11 -0700

> commit on finding a solution).

I strongly suggest option 3 with one proviso:

Where the docs say MUST use NSEC say "MUST use a mechanism that
provides proof of non-existence"

> NSEC2) or treat the zone as unsecured. That would delay too, 
> but maybe not that long.

Better than trying to go forward with deployment and discovering
that there is a protocol deficiency that cannot be fixed after
the fact.

People get paranoid about crypto specs, I used to. Then I started
an essay where I tried to prove this, only when I started to look
at the evidence SSL is in much better shape than anything else
despite being a disaster in original form, likewise with WEP.

Throw the stuff over the fence and see what sticks. Empirically
that is the best way to get to security.

---

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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 May 2004 09:30:27 -0700

> deployment experience.  

What is the killer app that would cause it to take off?

> if dnssec-bis fails to take off for 
> ANY reason, then

That is defeatist thinking. I think that DNSSEC needs a 
killer-app. I don't think that protecting the DNS infrastructure
itself is likely to serve until there is a massive DNS attack
that changes the way the infrastructure is viewed.

But a killer app need not be the intended purpose of even
the main purpose after the system is deployed. The Internet
killer app was the Web, not email. The Web allowed the Internet
to expand rapidly outside academia, but today email is the
app that is most valuable for most people. The killer app for the
microcomputer was the spreadsheet - an app that hardly any PC
user would rate as their most critical today. At that time you
bought a PC for your secretary to do word processing on, no
manager would admit doing that. 

I think that the most likely killer app for DNSSEC is email
accreditation services for anti-spam mechanisms. Of course this
could easily be served by a separate protocol. But reusing
DNS means that it can pull DNS extensions and DNSSEC along
in its wake. Needless to say, stopping trivial enumeration
is critical for this application.

---

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.)

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

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.

>   I think that the chairs should establish a firm time table for doing
> 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: "Loomis, Rip" <[email-masked]>
Date: Mon, 31 May 2004 11:42:44 -0400

Previously, the WG chairs asked for input  by 01 June
on WGLC and related issues, given the concerns raised
about NSEC and zone enumeration.  Since I'm going to
be out-of-pocket for two weeks and the chairs never
rescinded that request, here's my input.

Olaf wrote:
> 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 

I think that a capability that was not part of the DNS
protocol, but which many folks have made use of (and
may believe they rely on) is going to be undermined by
(most realistic schemes for) signed proof of non-
existence.  However, I would state that the "content
enumeration" bugaboo is to me just that--a bugaboo.

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

Sorry that I can't follow instructions, but I did want
to clarify the extent to which this is a "real issue"
in my mind.

> [slight editing follows to clearly state Olaf's options]
> Option 1. Taking up work to prevent zone enumeration
>    while holding the DNSSEC bis document-set
> Option 2.  shipping DNSSEC bis and forgetting for now
>    about solving the enumeration  problem.
> Option 3. Ship the DNSSEC-bis document set and work out
>    the enumeration problem later (but commit on finding
>    a solution).

I would prefer Option 2.  Option 2 doesn't mean that
issues with zone enumeration can never be addressed, but
it does make it less likely that major changes will be
made (because it makes the changes more painful to
implement).

I can live with Option 3, particularly if Opt-In (or
whatever a better name for it) is added back into the
mix of possible solutions.

I absolutely can't live with Option 1.  If I ever want
to have a prayer of having DNSSEC signed zones supported
in some fairly major software, we have *got* to get
DNSSECbis wrapped up and out the door.  It is deployable
today and I have no interest in waiting another 18
months for DNSSECbis-TNG (A/K/A DNSSECter).

Or, to put it more succinctly, I agree with recent messages
from Ted Lindgreen and Jim Reid that included the statement:

    Ted> So, I think that the working group should NOT delay DNSSECbis
    Ted> by trying to fold in NSEC2 this late in the process. If NSEC2
    Ted> needs to be worked out it should be done in a separate track.

  --Rip