Subject: Re: NSEC3-01 - more wildcard nits

From: Alex Bligh <[email-masked]>
Date: Fri, 01 Apr 2005 00:35:38 +0100

--On 31 March 2005 10:04 -0500 Edward Lewis <[email-masked]> wrote:

>
> PS I still have my doubts about finding a successor to NSEC.  A flag day
> would be needed to erase existing NSEC from the DNS and be seamless.
> Even if the thought is that "NSEC-era" verifiers will be upgraded to
> overcome this, that's the flag day.

Why does existing NSEC data need to be "erased from the DNS"? Why can
it not continue living there? Surely if we do the rollover suggested
several months ago, then we can leave NSEC data in, people may wish
to publish zones with both in (to support old resolvers if they aren't
worried about enumeration), and those new converts who adopt NSEC3
only will appear to have insecure zones to "old" (i.e. DNSSECbis)
resolvers.

Sure, zone publishers will need to pick a day when they don't want to
support old NSEC anymore. But why an internet wide flag day?

Alex

--
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: Alex Bligh <[email-masked]>
Date: Fri, 01 Apr 2005 10:49:51 +0100

> Fair 'nuf question.  This is what I'm thinking.
>
> The problem I can't get over is that I presume that admins using NSEC*
> are the ones that don't want to use NSEC.  It's not like NSEC* adopters
> will be happy to also do NSEC.  Although the two do not interfere, the
> reason for NSEC* is that NSEC shouldn't exist.

Nit: Some NSEC* adopters may be happy to do NSEC initially. IE some
existing NSEC operators may adopt NSEC* either to get (for instance)
opt-in (to reduce zone file size), because they don't like enumeration
but can live with it, because they know all resolvers will eventually
go NSEC* only, etc. - but the common theme here is they'll all want
to get rid of NSEC support eventually.

> Assuming there will be NSEC-era validators out there before NSEC* gets
> rolling, once there are NSEC* zones out there, these validators will see
> the NSEC* zones as broken because there are no NSEC records there.

I think the NSEC-era validators will see such NSEC* zones as insecure. Just
like they do now. Worst case, they will not understand the DNSSEC-ter
records at all, and will see vanilla DNS records. If there are DNSSEC-bis
records there too then they'll use them (but as you point out, at least
a subset of NSEC* adopters will not have such records, and the remainder
will want to get rid of them).

>  All
> of the NSEC-era validators would have to be replaced - that's the flag
> day or event - because in the meantime, the "extra secure" NSEC* zones
> may just be cut off if these zones are judged to be broken.

Yes, they will have to be replaced. But I don't see why it's a flag
day (i.e. a single event) - until they are replaced, the NSEC* zones
will just appear insecure ("oooh look this zone has a bunch of RR types
I don't understand").

> Maybe its only negative answers that will be broken.  Questions remain.

Worst case TCR etc. may break authenticated positive answers too. I still
don't see why it's a flag day. Perhaps we mean different things by "flag
day".

Alex

---

From: Ben Laurie <[email-masked]>
Date: Fri, 01 Apr 2005 11:03:06 +0100

> to get rid of NSEC support eventually.

Note that we have never suggested that NSEC++ should replace NSEC - it 
is an alternative which can be used, or not, at the operators discretion.

> will just appear insecure ("oooh look this zone has a bunch of RR types

Failure to understand RR types does not make a zone insecure. What will 
appear insecure in negative responses, which will lack the appropriate 
proof.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Ben Laurie <[email-masked]>
Date: Fri, 01 Apr 2005 11:09:23 +0100

> overcome this, that's the flag day.

Remember that the plan does not include erasing NSEC.

---

From: [email-masked] (Geoffrey Sisson)
Date: Fri, 1 Apr 2005 11:11:30 +0100 (BST)

Edward Lewis <[email-masked]>:

>                                 Although the two do not interfere, the

As I see it the reason for NSEC* is that enumeration is an issue for
some (maybe many) DNS operators, but certainly not all.  I don't see
why multiple denial of existence methods can't coexist.  NSEC3 requires
authoritative name servers to do more work (hashing QNAMEs), so if
enumeration isn't an issue then NSEC would be the method of choice.

Regards

Geoff

---

From: Alex Bligh <[email-masked]>
Date: Fri, 01 Apr 2005 11:15:00 +0100

> appear insecure in negative responses, which will lack the appropriate

Clarification: I was being lazy in expressing my argument. If you
can get away with "just" impacting negative answers, then fine (that's
introducing another RR type for NSEC3 only). Ed says (putting
words into his mouth) "this may cause problems - perhaps for instance
a resolver might adversely treat answers from a server that never
gave NSEC responses, because that's currently a 'MUST'" (I take
it that's what he meant by 'questions remain'). My response to this
is "OK, so worst case, you make new type codes for ALL the DNSSEC
stuff, so we have RRSIG3 etc. which have to be present with NSEC3
records - then any NSEC-era resolver will see a NSEC3 zone that does
not also have NSEC records as also lacking (for instance) RRSIG records
(coz it would have RRSIG3 instead), and hence treat the entire zone
as insecure".

Now I'm not suggesting we do the above if we can avoid it, but it
seems better than avoiding a flag day.

Personally I think Ed's question is valid one to ask, because the
corollary of the "well of course there is no problem" response is
that those who don't want to deploy NSEC could *currently* deploy
DNSSECbis omitting the NSEC records, and no harm would come except
for the lack of authenticated denial. Lots of people on this list
said this would be a bad thing (TM) not so long ago. But it's exactly
the position we'd find ourselves in with respect to NSEC-era resolvers
if NSEC3 was 'merely' a new RR type code.

Again, apologies precaffeinated post.

Alex