Subject: Re: Proposal to fix NSEC

From: [email-masked] (Ted Lindgreen)
Date: Mon, 31 May 2004 14:58:19 +0200

[Quoting Olaf Kolkman, on May 20, 22:42, in "Re: Proposal to fix  ..."]
> Dear Colleagues,
....
> 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.

After following the discussion with great interest, I think that:

1. The virtues of making NSEC-walking difficult seem to be largely
   overestimated by some people. For all devious purposes (spamlist
   building, whois lurking, etc), there are already numerous ways
   to build a close enough list of domainnames with or without NSEC.
   I really think that the problems at hand will hardly be
   influenced by having NSEC or NSEC2 in practice.

2. The time, the work, and the funding needed to redo DNSSEC once
   again seems largely underestimated. Having been involved in the
   work to go from 2535 to the current docset, I don't believe
   anyone who says that we can stamp out a DNSSECter docset before
   2006 or perhaps even 2007.
   As for funding such work, I will have a large problem to defend
   further funding for NLnet Labs on DNSSEC if we go back to the
   basic design. NLnet Labs must then most likely drop their work
   on DNSSEC on the floor.

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

Regards,
-- ted

--
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: Jim Reid <[email-masked]>
Date: Mon, 31 May 2004 15:27:23 +0100

>>>>> "Ted" == Ted Lindgreen <[email-masked]> writes:

    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.

I agree wholeheartedly with Ted.

Folding NSEC2 into DNSSECbis will delay a DNSSEC standard for at least
a year, more likely two. This would represent a design change, not
just a few tweaks of the current document set. The 11th hour arguments
of the NSEC2 people and their stakeholders notwithstanding, the WG has
a document set today that has rough consensus, working code and has
benefitted from a lot of work and detailed analysis. We have something
that works and is deployable. Apart of course from layer-9 issues in
some quarters that IMO should not concern this WG. I think the WG
should go with the DNSSECbis drafts and the immediate priority should
be to review these while they are in Last Call.

If NSEC2 is to be worked on, this can be considered after DNSSECbis
has gone to IESG. I'd like the NSEC2 supporters to come back with 
completed, well worked out drafts that not only defined the new
protocol but also showed how this will interwork with DNSSECbis, any
migration strategy and so on.

For now, the WG needs to focus on a technical review of the current
document set. To some extent this appears to have been overshadowed by
a debate on the layer-9 issues that motivated NSEC2.

---

From: [email-masked] (Geoffrey Sisson)
Date: Mon, 31 May 2004 15:29:34 +0100 (BST)

>    influenced by having NSEC or NSEC2 in practice.

Please note that information leakage is not the only issue attributable
to NSEC RR elaboration: resource depletion due to possibly frequent,
multiple simultaneous chains of elaboration could also be significant.
Making zone files available via some other mechanism, e.g. FTP or HTTP,
without restriction, seems to be the only way to make NSEC RR
elaboration less rewarding than other methods of spammer/scammer list
construction.  Even ICANN TLDs which have a policy of making their
register database available to requestors may find that a
non-negligible number of users would prefer to use NSEC RR elaboration
tools, perhaps to avoid bureaucracy or to conceal their identities.

In other words, I don't believe this is strictly a European ccTLD
problem.  It may be a problem for any nameserver administrator --
especially of large registries -- who is unwilling or unable to make
zone file information trivially available via alternate means.

Regards

Geoff

---

From: Greg Hudson <[email-masked]>
Date: Mon, 31 May 2004 11:00:12 -0400

(I agree with Ted.)

> multiple simultaneous chains of elaboration could also be significant.

Two answers:

(1) The normal load on most of these servers is pretty high.  An awful
lot of spammers would have to be doing simultaneous nsec walks (which
are rate-limited to some extent by needing to wait an RTT for each
request) before it would become a noticeable factor.

(2) An nsec walk is an awful lot more efficient than a PTR walk.

---

From: [email-masked] (Geoffrey Sisson)
Date: Mon, 31 May 2004 16:25:58 +0100 (BST)

> request) before it would become a noticeable factor.

Except . . . (Copy of my reply to kre on Friday)

------------------------ Begin included text ------------------------
It would be surprising if NSEC RR elaboration techniques didn't
incorporate considerable parallelism, especially for large zones.  This
could impose arbitrarily high loads on a busy nameserver.  For example,
multiple simultaneous elaborations could be run, one starting at
'aaa.co.uk', another starting at 'aab.co.uk', and so on.

This isn't idle speculation: prior to incorporating token bucket into
the WHOIS server at whois.nic.uk [note: reference to WHOIS for
illustrative purposes only!] we used to have a one-second sleep to
limit the impact of scripts.  Impatient data miners designed tools
which sent queries in parallel -- sometimes hundreds per second -- in
order to collect data at higher rates.  The consequences to server
performance were, well, predictable . . .
------------------------- End included text -------------------------

> (2) An nsec walk is an awful lot more efficient than a PTR walk.

True, though PTR walks are probably more distributed (i.e. involve
traversing many different servers, not just RIR servers), though
perhaps Daniel or Ed may have more insight into this phenomenon.  Also,
I suspect that PTR walks are much less rewarding (require much more
effort for more lossy results) so would not be as ubiquitous.

Regards

Geoff

---

From: [email-masked]
Date: Mon, 31 May 2004 19:08:28 +0200 (CEST)

> to be worked out it should be done in a separate track.

I agree with this conclusion. 'fixing' DNSSECbis for NSEC2 means delay.
The fix is not trivial. Ship the docset and start work on NSEC2 in a
seperate track.

Roy

---

From: "Jay Daley" <[email-masked]>
Date: Mon, 31 May 2004 22:26:01 +0100

Greg

> request) before it would become a noticeable factor.

Let me just put this one in perspective.  Each of our nameservers has an 
average load of 100 million queries per day with about 4 million records 
in our zone files.  That means it will take only 25 spammers doing a full 
walk in one day to double the load on that server (this is on top of the 
huge increase in traffic that DNSSEC means).  As we have on average 3,000 
new domains registered per day we can safely expect these spammers to do 
this every day.  Once the script kiddie tools are out then we can expect 
many, many more than just 25.

Jay

---

From: Ted Hardie <[email-masked]>
Date: Mon, 31 May 2004 16:51:23 -0700

>The fix is not trivial. Ship the docset and start work on NSEC2 in a

I also agree with this conclusion.
			regards,
				Ted Hardie