Subject: Re: Proposal to fix NSEC

From: Olaf Kolkman <[email-masked]>
Date: Thu, 20 May 2004 22:36:45 +0200

Dear Colleagues,

Let me try and sumarise what I've seen so far and suggest a way
forward.

Ben proposed a mechanism to fix "NSEC zone traversal" that apparently
hinders TLDs in the deployment of DNSSEC. Although the discussion on
the validity of this reason is interesting it is not a protocol issue. 
We
will not be able to change TLD policies.

The proposed mechanism, I'll refer to is as NSEC2, may have technical 
merit.
I think it is fair to say that the working group is still digesting the 
technical
details of the proposal. Please continue to do so, having documented 
why a
technology will or will not work is a good thing.

As far as I understand the security properties of the proposed
technology are such that changes are needed to the protocol as in
DNSSEC-bis. This means that we have to introduce a flag day. That flag
day either is "now" or after the DNSSEC-bis protocol is out in the
field.

We as a working group have a choice.

- We take up this NSEC2 proposal as a working item.

   If we do so we will have to merge the technology into the current
   DNSSEC-bis document set. Having a flag day, after introducing
   DNSSEC-bis just does not make sense.

   Realize that taking up this as a working item would result in an
   unknown delay of getting the DNSSEC specifications done. Not only
   will the WG need time to assess the quality of the proposed
   solution but people currently funded to work on the effort may see
   that funding stop and walk away. Realisticly we are looking at
   significantly more than 6 months [*] delay. (We'll have to assess
   interaction with wildcards and other DNS elements. We'll have to
   test for corner cases, &c, &c). There are more pessimistic scenarios
   than the 6 months scenario.

- We do not take up NSEC2 as a working item

   This would not imply that the "NSEC zone traversal" is a non-issue.
   It may actually hinder deployment of DNSSEC some TLD zones.

   If we go this route we may have a proposed standard and start of
   deployment in some zones this year in less than 6 months [*].

   The DNSSEC-bis document set is clear on the fact that DNSSEC does
   not offer privacy. We just have to live with that.

I'll be tracking the discussion with the following in mind.

If I do not see rough consensus on taking up NSEC2 as a work item by 
June 1
I'll reject this as a work item.

If, after June 1, there is consensus on taking up NSEC2 as a work item
I'll try to make an inventory on how many participants of the working
group can commit resources to make this work. If it turns out we
cannot produce standards, documents and code on a reasonable time or
we alienate a significant fraction of the people that are now
committed on working on this we'll also not take NSEC2 up as a work 
item.

If we'll take NSEC2 as a work item then - in order to avoid a flag day -
the current DNSSEC-bis doc set will be put on hold until NSEC2 is cooked
enough to be merged into the DNSSEC-bis documents.

Olaf Kolkman
DNSEXT Co-Chair

(Olafur is away from keyboard for a week or two.)

[*] I've been telling people that DNSSEC will be ready in 6 months
    over the last 3 years. As a result the combination of "6 months"
    and DNSSEC in one sentence rises suspicion.

--
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 Badami <[email-masked]>
Date: Thu, 20 May 2004 22:16:36 +0100

>>>>> "Olaf" == Olaf Kolkman <[email-masked]> writes:

    Olaf> Ben proposed a mechanism to fix "NSEC zone traversal" that
    Olaf> apparently hinders TLDs in the deployment of
    Olaf> DNSSEC.

I had been intending to avoid making any further on-list comments,
given I haven't been a WG participant, and that much of this thread
has been discussing issues which are both outside the scope of this WG
and outside the expertese of this WG.

But I just want to make one further point.

Contrary to what you suggest, I don't believe anyone with authority to
do so has clearly stated that that zone file traversal is a serious
barrier to deployment in certain registries.  Ben very specifically
stated that he speaks for Nominet only on technical matters, not on
policy matters and, I believe, has avoided commenting in this thread
other than on the technical issues relating to his proposal.  There
may be other people who have expressed this view whose afiliations I
am unware of, of course.

I don't have a strong opinion as to whether zone file traversal is a
serious issue for adoption or not.  I'm just trying to suggest that
the answer to this question isn't as obvious as some particpants seem
to believe.

Nor am I expressing an opinion as to whether it would be appropriate
to consider modifying the DNSSECbis document set at this late stage.

However unless it is possible to get relevent input from those TLDs
that currently have a policy of not making their zone files available
to the public, then I suggest it would not be productive to persue
this issue at this stage, but that it should simply be noted as an
item for possible future study.

	-roy

---

From: Roy Badami <[email-masked]>
Date: Fri, 21 May 2004 01:41:13 +0100

>>>>> "Olaf" == Olaf Kolkman <[email-masked]> writes:

    Olaf> As far as I understand the security properties of the
    Olaf> proposed technology are such that changes are needed to the
    Olaf> protocol as in DNSSEC-bis. This means that we have to
    Olaf> introduce a flag day.

It's not obviously (to me) an incredibly nasty flag day.  If there is
a real desire to do this subsequently, zones can be given a choice of
publishing NSEC or NSEC2 records or both.  The flag day is then the
day on which publishing NSEC records ceases to be mandatory.  On this
day, old resolvers which don't understand the NSEC2 RR will start
getting resolution failures for non-existent domains, rather than
getting a clean NXDOMAIN answer.

Whilst not entirely ideal behaviour, this is potentially a manageable
scenario...

	-roy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 21 May 2004 10:45:47 +0200

Olaf,

> June 1 I'll reject this as a work item.

Thanks to the chairs for hearing the voices of those stating they have a 
deployment problem with the specification in its current form.

While it is true that DNSSec has a long and painful story tracking back to 
10 years ago, that's plainly because the protocol itself isn't so easy as 
thought in the beginning. I wouldn't like to see these kind of 
retrospective arguments bound to the future of proposals to solve the NSEC 
traversal.

Regards,
Marcos

---

From: Mark Kosters <[email-masked]>
Date: Fri, 21 May 2004 15:34:41 -0400

> retrospective arguments bound to the future of proposals to solve the NSEC 

I have mixed feelings about this. 

Despite us having zones available to download (after signing an agreement
not to use this data in a harmful way), NSEC walking is going happen.
They will do this out of ignorance or malfeasance.  Rate limiting will 
be of some limited benefit but will not solve the issue.* What it does for us 
is increase load on systems serving up responses that serve no purpose. Thus,
I would like to see some sort of way of reducing this behavior from occuring.

Also, registries have the convergence of protocol improvements, operational
realities, and political pressures. To that end, I sympathize with
other registries as they think about how to deploy this monster.
I hope that some of you who stomped your feet at Roy, Dave, and I over 
opt-in would open your minds, listen and help solve this issue.

On the flip side, I too like to see dnssec deployed in the near future.
Unfortunately, it will not happen if the pain is worse than the gain.

Thanks,
Mark

* I think that the rate-limiting sentence should be taken out of the
intro draft - it will not work except in the most trivial cases.

-- 

Mark Kosters            [email-masked]       Verisign Applied Research