Subject: NSEC3 requirements question

From: Samuel Weiler <[email-masked]>
Date: Mon, 1 Aug 2005 12:15:22 -0400 (EDT)

I don't see this addressed by our requirements doc,
draft-ietf-dnsext-signed-nonexistence-requirements-01.txt (now
expired).  Please tell me if I missed something.

-- must it be possible to smoothly roll between NSEC and NSEC3?

Specifically I mean:

-- During roll between NSEC and NSEC3 (and vice-versa), must a
   properly configured resolver that supports both NSEC and NSEC3
   always see the zone as Secure (never Insecure)?

-- Or is it okay to require that the roll between NSEC and NSEC3 go
   through an Insecure state?

-- I'm assuming that when switching between them, no properly-signed
   zone should be marked as Bogus by any properly-configured
   validator, whether it supports NSEC only, NSEC3 only, or both.

Posing the question in table form, is Table 1 necessary, or is Table 2
sufficient (notice the difference in the last line of each)?

                     Table 1: Smooth Rollover
             Validation Result at Stage of NSEC--->NSEC3 rollover
Resolver Supports   pre-roll        during roll      after roll
NSEC only           Secure          ?                Insecure
NSEC3 only          Insecure        ?                Secure
NSEC and NSEC3      Secure          Secure           Secure

          Table 2: Unsmooth Rollover (through Insecure)
             Validation Result at Stage of NSEC--->NSEC3 rollover
Resolver Supports   pre-roll        during roll      after roll
NSEC only           Secure          ?                Insecure
NSEC3 only          Insecure        ?                Secure
NSEC and NSEC3      Secure          ?                Secure

? = Insecure or Secure, perhaps cache-dependent, but never Bogus

--
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: Mon, 01 Aug 2005 17:56:05 +0100

>    always see the zone as Secure (never Insecure)?

I actually think there are a number of possible questions there:

1. Is it a requirement that an authoritative server [*] which supports
   both NSEC and NSEC3 can be "rolled-over" so that a zone initially
   using NSEC (only) can be reconfigured so as to support NSEC3 (only)
   such that in the intervening time, the zone is never seen as insecure
   by any compliant resolver that supports both NSEC and NSEC3.

   [Note: "never seen as insecure" is less stringent than "always
   seen as secure" as the latter could be read as not allowing the
   server to be taken off air at all.]

2. Is the reverse of (1) a requirement (i.e. roll back to NSEC).

3. Is it a requirement that a caching resolver, which supports NSEC
   can be "rolled over" to one which supports NSEC and NSEC3, without
   any adverse security implication on its clients (whether or not
   they only support NSEC). [it would be pretty dumb to break that
   requirement, but no doubt possible by selective record serving]

I think the answer to all 3 is yes, and I think you probably meant (1)
only :-)

Alex

---

From: Namedroppers-owner <[email-masked]>
Date: Thu, 04 Aug 2005 10:34:05 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

<chair-hat off>
This is real important question and there are multiple possible answers
IMHO I think it is going to come down to cost which solution to select.

>    always see the zone as Secure (never Insecure)?

This is real hard, as for this to work the zone must use both NSEC
and NSEC3 at the same time in order to work and validator pics one
to follow at any given moment.

>    through an Insecure state?

Yes, I think so, and this is the option that is the least expensive for
resolvers and has the lowest risk to the infrastructure, as there is
no special code path for this case.
IE. zone picks a time that it goes insecure, and  for how long an
interval it is insecure.

         Olafur

---

From: Alex Bligh <[email-masked]>
Date: Thu, 04 Aug 2005 12:08:40 +0100

> to follow at any given moment.

I'd blithely assumed that was exactly what happened. Why is this bit hard?
(or rather why is it harder than having a resolver which supports both
NSEC plus NSEC3).

I presumed the hard bit was how to deal with potentially conflicting
NSEC/NSEC3 information (my answer: don't do that).

Alex

---

From: Ben Laurie <[email-masked]>
Date: Mon, 15 Aug 2005 12:51:39 +0100

Namedroppers-owner wrote:
>   a non-subscriber, or because it was over 20K.    With the massive 
> amount of spam, it is easy to miss and therefore   delete relevant posts 
> by non-subscribers.   Please fix your subscription addresses. ]
> 
> <chair-hat off>

Surely not? The server only ever has to use one, since the resolver 
supports both. So, this seems to me to be trivial - the server switches 
from an all-NSEC zone to an all-NSEC3 zone, and everything Just Works(tm).

-- 
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: Mon, 15 Aug 2005 12:56:11 +0100

Samuel Weiler wrote:
> On Sat, 23 Jul 2005, Samuel Weiler wrote:
> 
> 
>>  -- the lack of specification of a signaling mechanism for indicating
>>     that NSEC3, rather than NSEC, is in use.  I think we agreed this
>>     could be deferred, but the selection is necessary for
>>     implementation to go forward.
>>
>>  -- the lack of clarity re: which hash algorithms are
>>     required/mandatory and/or a way to signal which may be in use in
>>     a given zone, which may be needed to prevent a downgrade attack.
>>     (Or drop to a single algorithm, and remove the field.)
> 
> 
> dnssec-trans-02 recommends a partial typecode roll, rolling the NSEC
> and DS types as well as the DNSSEC-OK bit.  As I recall the joy of
> finding a new protocol bug every two months in late 2002 with DS, I
> find myself longing for something else.
> 
> I propose:
> 
> We use the DS message digest number field for signaling BOTH:
>   1) that NSEC3 is in use in the child zone, and
>   2) which SINGLE hash algorithm is used by those NSEC3 RRs.
> 
> This requires a new DS message digest assignment (in a Standards
> Action registry), whether using SHA-1, as before, or something new.
> It also depends on resolvers treating DS's with unknown digest
> algorithms as they would DS's with unknown public key algorithms,
> which is not described in 4035, but is described in bis-updates
> section 3.1.

I do not understand why it is necessary to signal that the child zone is 
using NSEC3. Also, if we introduce an interaction between parent and 
child in order to use NSEC3 it has impact on all sorts of other things 
and is, IMO, to be avoided.

> We could also then remove the NSEC3 hash algorithm field along with
> the need to have rules for handling unknown values in that field.
> Simiplicity is a good thing.  It also removes the need for a new IANA
> registry.

Having to link the parent's response to interpretation of the child's 
response does not strike me as a simplification. It also doesn't work 
for the root of any island of trust.

Cheers,

Ben.

---

From: [email-masked]
Date: Sat, 20 Aug 2005 14:14:33 +0000

> from an all-NSEC zone to an all-NSEC3 zone, and everything Just Works(tm).

	er... how do you -KNOW- all the resolvers that will touch these
	servers support "both" NSEC and NSEC3?

	by several educated estimates, there are perhaps 1 or 2 orders of 
	magnitude more resolvers out there than servers... and we have 
	emperical evidence that getting server code upgraded is a real PITA
	and takes years/decades.

--bill

---

From: Ben Laurie <[email-masked]>
Date: Sat, 20 Aug 2005 15:20:32 +0100

> 	emperical evidence that getting server code upgraded is a real PITA

I don't, but that wasn't the question.

---

From: [email-masked]
Date: Sat, 20 Aug 2005 14:25:50 +0000

> I don't, but that wasn't the question.

	true, but there was that assertion in you last statement above...
	"...The server only ever has to use one, since the resolver 
	supports both..."  which tickled my response.

--bill

---

From: Ben Laurie <[email-masked]>
Date: Sat, 20 Aug 2005 15:32:46 +0100

> 	supports both..."  which tickled my response.

That was the question asked.

---

From: [email-masked]
Date: Sat, 20 Aug 2005 15:03:28 +0000

> That was the question asked.

	thats not a question. thats an assertion based on a premise w/o
	factual basis. the assertion "the server only ever has to use one"
	is based on the premise "the resolver supports both" ... and
	you give no indication as to WHY you believe "the resolver" will
	have such capabilities.  What was the question again?

--bill

---

From: Alex Bligh <[email-masked]>
Date: Sat, 20 Aug 2005 17:03:22 +0100

Ben / Bill,

You guys are talking straight past each-other.

The original question was:

> properly configured resolver that **** supports both NSEC and NSEC3 ***

So based on the original question, Ben answered (in effect that it
only ever has to use one).

I think Bill's (now) asking a different question - which is what happens
if the resolver does not support both NSEC and NSEC3.

And I think the answer to it is as follows:

If the resolver supports NSEC, but does not support NSEC3, that:
* a zone that is rolling from NSEC (only) to NSEC3 (only) will in the
  end appear insecure at the end of the roll anyway, so who cares what
  happens in the middle
* a zone that is rolling from NSEC (only) to NSEC3 by addition of NSEC3
  records, and intends to retain NSEC records indefinitely, will ignore
  the NSEC3 records anyway, and thus appear secure. But why would one
  want to do that?

If the RESOLVER supports NSEC3, but does not support NSEC, that would
appear to be a banned condition, as NSEC support should be a mandatory
requirement of an NSEC3 resolver, at least until some future flag day.
But the answer is surely that the zone appears secure (as it did
before) until the NSEC3 records disappear.

Alex

---

From: Ben Laurie <[email-masked]>
Date: Sat, 20 Aug 2005 18:15:01 +0100

[email-masked] wrote:
>>>>>>from an all-NSEC zone to an all-NSEC3 zone, and everything Just 
>>>>>
>>>>>>Works(tm).
>>>>>
>>>>>

Since scrolling up seems to be a problem, I'll quote it here at the bottom:

"During roll between NSEC and NSEC3 (and vice-versa), must a properly 
configured resolver that supports both NSEC and NSEC3 always see the 
zone as Secure (never Insecure)?"

Cheers,

Ben.

---

From: [email-masked]
Date: Sat, 20 Aug 2005 17:18:20 +0000

> zone as Secure (never Insecure)?"

	ah... i see. i was talking about something else then.

--bill

---

From: Ben Laurie <[email-masked]>
Date: Sat, 20 Aug 2005 18:25:42 +0100

> if the resolver does not support both NSEC and NSEC3.

Bill may want to ask that question, but the question he asked was: "how 
do you -KNOW- all the resolvers that will touch these servers support 
"both" NSEC and NSEC3?" and my answer is that it was assumed in the 
question I was answering.

> before) until the NSEC3 records disappear.

In this case it goes from being insecure to secure, surely? Since the 
resolver did not understand the NSEC version of the zone.

However, clearly, we would not standardise such foolishness.

---

From: Alex Bligh <[email-masked]>
Date: Sat, 20 Aug 2005 18:42:16 +0100

> resolver did not understand the NSEC version of the zone.

urm, yes.

Alex

---

From: [email-masked]
Date: Sat, 20 Aug 2005 17:55:55 +0000

> question I was answering.

	two questions there ...

> However, clearly, we would not standardise such foolishness.

	good answer.  seems to point out that "secure" state
	of a zone is (almost) exclusively defined by the capabilities
	of the quering resolver...

	why should NSEC3 only be a banned condition?

--bill

---

From: Ben Laurie <[email-masked]>
Date: Sat, 20 Aug 2005 19:11:05 +0100

> 	why should NSEC3 only be a banned condition?

It shouldn't - what should be banned is resolvers that don't understand 
NSEC.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 20 Aug 2005 19:20:06 +0000

# However, clearly, we would not standardise such foolishness.

ben, you now owe me one new keyboard. --paul

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 23 Aug 2005 14:27:08 -0400 (EDT)

>    through an Insecure state?

In the three weeks since I posed the above requirements question, I've
read (only) two answers, from Alex and Olafur, and they seem to
disagree.

In the interest of simplifying the work of testing NSEC3, hence
getting NSEC3 out the door faster, I propose that the default answer
should be consistent with Olafur's: no smooth roll is required -- it's
acceptable to have to roll thorugh Insecure to switch between NSEC and
NSEC3 (and vice-versa).  Accordingly, any NSEC3 testing efforts don't
need to look for problems with rolling between NSEC and NSEC3 -- they
merely need look for problems rolling from unsigned to NSEC3 (and
vice-versa).

Absent a more overwhelming statement of "yes, this is a requirement"
in the next week or two (which will have left this question on the
table for a month, including a physical IETF meeting), I suggest that
the requirements doc editors document smooth rollover as a
non-requirement.

-- Sam

---

From: Alex Bligh <[email-masked]>
Date: Wed, 24 Aug 2005 10:16:08 +0100

> read (only) two answers, from Alex and Olafur, and they seem to

I don't feel that strongly about it & I am happy to go with your
suggestion.

Alex

---

From: Ben Laurie <[email-masked]>
Date: Thu, 25 Aug 2005 17:17:11 +0100

> the requirements doc editors document smooth rollover as a

I still claim it isn't an issue, but I'm also totally happy with it 
being a non-requirement.