Subject: Re: Proposal to fix NSEC

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.

--
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: [email-masked] (Geoffrey Sisson)
Date: Mon, 31 May 2004 15:29:34 +0100 (BST)

[email-masked] (Ted Lindgreen) writes:

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

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: [email-masked]
Date: Mon, 31 May 2004 19:08:28 +0200 (CEST)

On Mon, 31 May 2004, Ted Lindgreen wrote:

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

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