Subject: Re: Proposed NSEC/NSEC3 transition mechanism

From: Edward Lewis <[email-masked]>
Date: Wed, 17 May 2006 13:42:57 -0400

At 8:03 -0700 5/17/06, Ben Laurie wrote:
>In order to allow a rollover to NSEC3 from NSEC without going through
>insecure (although this is not a requirement), I propose the following
>mechanism.

Where can I apply to make it a requirement?  I'm sure that the 
advancements made in .SE and at RIPE to date will not want to fall by 
the wayside.  And by the time that NSEC3 is eligible for deployment, 
more TLDs will be contracturally required to be using DNSSEC.

>a) Choose a signalling mechanism that the child zone is NSEC3. I favour
>using the key signing algorithm since this is available to the client no
>matter how it comes into possession of the key (unlike the DS hash
>algorithm).
>
>b) This signal means "the child zone will use either NSEC or NSEC3".
>Absence of the signal means "the child zone uses NSEC".
>
>c) Call old keys "NSEC keys", new ones "NSEC3 keys".

I wish that we do not label keys in this way.  It leads us into the 
same alley where people say "keys expire in DNS."  I'd allow NSEC-era 
keys and NSEC3-era keys.  It's the "era" and not the key that changes.

>d) Let the time from a zone ceasing to publish a key to the time the
>world has stopped using that key (i.e. it has expired from all caches) be n.

So, if I have a key derived from the zug-endet-hier algorithm, i.e., 
algorithm 12, and am using NSEC records today.  I want to use the 
same key and algorithm to start doing NSEC3, I would then add to my 
DS set a key of the H-zug-endet-hier algorithm number (13).

So, now, how do I sign my zone?  Do I continue to sign the NSEC 
records with algorithm 12 or algorithm 13?  Both?  I assume that I 
only sign NSEC records with algorithm 13.  But then there's that 
tricky requirement:

RFC 4035, 2.2, last paragraph:

    There MUST be an RRSIG for each RRset using at least one DNSKEY of
    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
    itself MUST be signed by each algorithm appearing in the DS RRset
    located at the delegating parent (if any).

The reason for both records is to wait until enough of the world has 
adopted new validators.  Eventually I stop issuing the NSEC records 
and then remove the algorithm 12 keys.

>Time T-1: Zone is using NSEC keys.
>
>Time T: Zone switches to NSEC3 keys, dropping the NSEC keys. Zone
>continues to use NSEC. Zone is signed with both NSEC and NSEC3 keys.

But then how do validators find the keys to validate the previously 
cached NSEC records?

>Time T+n: Zone stops using NSEC, starts using NSEC3. Zone is signed with
>NSEC3 key only.
>
>Between time T and T+n, NSEC-aware resolvers may or my not be able to
>verify responses, depending on whether they can retrieve the NSEC key or
>not. If they can retrieve the key, then all works as expected for them.
>NSEC3-aware resolvers will be able to verify during this time (using
>NSEC records for negative responses, of course). After T+n, NSEC-aware
>resolvers no longer understand the zone at all, only NSEC3-aware
>resolvers do. So, for the whole transition, NSEC3-aware resolvers see a
>secure zone, and NSEC-aware resolvers either see a secure zone, or see
>an insecure zone. No-one ever sees a bogus zone.
>
>The reverse is similar, but not quite the same.
>
>Time T-1: Zone is using NSEC3 keys.
>
>Time T: Zone switches to NSEC keys, dropping the NSEC3 keys. Zone
>switches to NSEC records. Zone is signed with both NSEC and NSEC3 keys.

How big can a zone be and have this still be effective?

I'd rather see a mechanism in which I can pre-populate the zone with 
the new records (whether NSEC or NSEC3) and the switch them "on" with 
the flip of a key.

>Time T+n: Zone stops signing with NSEC3 keys and signs with NSEC keys only.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

--
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: Sam Weiler <[email-masked]>
Date: Wed, 17 May 2006 14:43:04 -0400 (EDT)

On Wed, 17 May 2006, Edward Lewis wrote:

>> insecure (although this is not a requirement),...
>
> Where can I apply to make it a requirement?

By resurrecting and replying to the "NSEC3 requirements question" 
thread from August 2005.

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01105.html
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01161.html

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Wed, 17 May 2006 17:38:17 -0400

>http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01161.html

Okay, here's my rationale for pushing for smooth transition.

For the sake of registries that have or will have DNSSEC running 
prior to the publication of the possible NSEC3 specification, I claim 
that a means to have a smooth transition from NSEC to NSEC3 and back 
is essential.

Registries are supposed to be run in a reliable, smooth manner. 
Expecting a registry to drop support for a feature and then pick it 
up as if it were a flag day to all of its registrants violates this. 
Flip-flopping is not smooth.

It may be true that today there are not many registries that are 
operating with DNSSEC.  But consider that the number may grow before 
NSEC3 is eligible for operations.  Before once again being too 
optimistic about a time table for NSEC3, recall that in 1999 we 
thought DNSSEC was ready based on software development only. 
Granted, I am not giving hard data here, but has anyone trialed NSEC3 
in a mixed (NSEC/NSEC3) environment?  Has there been sufficient 
operations testing of interoperable code?  This is why I am not so 
optimistic that NSEC3 can beat contractural requirement for the 
deployment of DNSSEC.

We have long maintained that the DNS is critical to the operation of 
the Internet.  That is why it takes a long time to get any 
improvements rolled into it.  Why expect that this next change would 
be fast?

My requirement for a phase-in/phase-out plan include:

1) No need to stand up a separate DNS constellation (whether this is 
processes, CPU's, or sites) to fall from one to the other.

2) An incremental means to transfer the needed ancillary data that 
won't overwhelm other churn in a zone prior to any sort of cut over. 
I.e., I want the NSEC records prepopulated before going from NSEC3 
back to NSEC.

3) The ability to maintain positive DNSSEC validation for answers to 
queries (with positive answers) during the transition or cut-over. 
Remember that NSEC/NSEC3 is about just the "oops" cases.

4) Expect that software will be able to provide both an NSEC and an 
NSEC3 proof of non-existence in the same response packet.

5) "NSEC" and "NSEC3" ought to be thought of as any pair of options 
(the thought of NSEC5 should be accommodated) for this.

6) The expectation that a zone may want to continue with both NSEC 
and NSEC3 for an extended period of time.

7) The transition plan needs to consider that DNS data has 
persistence, i.e., in caches and in other uses.  DNS has never been 
real-time and no matter how hard we try to speed it up, nothing can 
happen on a strict slice of time.

8) The transition plan has to be simple to follow.  Each step will be 
taken and tested before the next.  If there are too many steps, then 
the process will have to be handed from one shift to the next.  It 
can be long or it can be complex - preferably neither - but it cannot 
be both.

There may be other requriements to add later.  Comments on these?

---

From: Roy Arends <[email-masked]>
Date: Thu, 18 May 2006 18:05:41 +0200

> keys and NSEC3-era keys.  It's the "era" and not the key that changes.

Sure.

> and then remove the algorithm 12 keys.

This is a key rollover, the same kind of rollover you have to have in 
403[345] ?

Nothing new here.

> >Time T-1: Zone is using NSEC keys.

Zone is using zug-endet-hier keys.

> >continues to use NSEC. Zone is signed with both NSEC and NSEC3 keys.

Time T: Zone switches to h-zug-endet-hier keys, dropping the 
zug-endet-hier keys. Zone continues to use NSEC. Zone is signed with both 
zug-endet-hier keys and h-zug-endet-hier keys.
 
> But then how do validators find the keys to validate the previously 

This is still a key-rollover. 

Nothing new here.

> How big can a zone be and have this still be effective?

It is a zone with 2 signatures on every record, as is the case with any 
other key roll. 
 
> the new records (whether NSEC or NSEC3) and the switch them "on" with 

Which is _exactly_ what happens here. We switch from DNSSEC to DNS for 
nsec-resolvers by the flip of a key. Meanwhile
nsec3 resolver never treats the zone as not secured. 

The key flip you want happens at point T.

I kinda like this 2-step approach. Simple and effective. It doesn't 
require the authoritative nsec3-server to have additional complexity to 
serve both records in a response. It also does not add any complexity to 
current resolvers or new nsec3-resolvers.

If what you want is both NSEC and NSEC3 records being served for a long 
period of time from a single zone, I'd have to dissappoint you: it is 
silly, since serving NSEC defeats the whole purpose of serving NSEC3, 
right ?

Roy

---

From: Ben Laurie <[email-masked]>
Date: Thu, 18 May 2006 09:25:22 -0700

Edward Lewis wrote:
> I wish that we do not label keys in this way.  It leads us into the same
> alley where people say "keys expire in DNS."  I'd allow NSEC-era keys
> and NSEC3-era keys.  It's the "era" and not the key that changes.

Sure thing.

> algorithm 12, and am using NSEC records today.  I want to use the same
> key and algorithm to start doing NSEC3, I would then add to my DS set a
> key of the H-zug-endet-hier algorithm number (13).

Nope, you'd replace the key, not add one.

> So, now, how do I sign my zone?  Do I continue to sign the NSEC records
> with algorithm 12 or algorithm 13?  Both?  I assume that I only sign
> NSEC records with algorithm 13.  But then there's that tricky requirement:
> 
> adopted new validators.  Eventually I stop issuing the NSEC records and
> then remove the algorithm 12 keys.
> 

They don't.

> I'd rather see a mechanism in which I can pre-populate the zone with the
> new records (whether NSEC or NSEC3) and the switch them "on" with the
> flip of a key.

This is an implementation issue, surely?

-- 
http://www.links.org/

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 May 2006 08:28:04 -0400

> Flip-flopping is not smooth.

While I am sympathetic to this observation (and all too painfully
aware of it), I think there's a practical problem with it: the whole
point of NSEC3 is to avoid a nasty consequence of NSEC.  So if you
think NSEC is dangerous today, what (aside from people clamouring
"just sign it") changes that calculation in the time between today
and the day NSEC3 is ready?

That said, if someone has the magic necessary to make smooth
bidirectional transistions possible, I'm all ears.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 May 2006 11:27:15 -0400

>and the day NSEC3 is ready?

The conventional wisdom of the NSEC3 developers is that NSEC3 can 
coexist with NSEC, that NSEC3 will only be used where it is necessary.

I have two reasons to doubt that conventional wisdom.  One is that it 
has been long said that we should hold no zone to be unusual, to be 
treated differently in the protocol.  The other is that I don't know 
of any situation in which a protocol has two viable alternatives for 
a core function that remain in common use.

To illustrate what I mean reverse map zones, widely delegated zones, 
enterprise zones all should get equal treatment under port 53.  We do 
have OSPF an IS-IS as alternative internal routing protocols but they 
never interact.

There is no reason to say that the conventional wisdom here is dead 
wrong.  My doubt lays in the inability to see any precedent that 
supports the conventional wisdom.

Given that, what "changes the calculation" regarding NSEC and NSEC3 
over time?  Regulation, customer requirements, lessons learned in 
trying to simplify operations come to mind.  By "customer 
requirements" I mean organizations that set forth the operations 
requirements, like ICANN, and not the domain name registrants.  E.g., 
what might be thought of as a NSEC3-agnostic zone today may be asked 
to take up NSEC3 in the future.

>bidirectional transistions possible, I'm all ears.

With enough time and money, anything is possible. ;)  It depends on 
where we place the workload.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 May 2006 12:09:45 -0400

> a core function that remain in common use.

That sounds like a reductio argument to the conclusion, "NSEC3 won't
be everywhere, therefore NSEC3 won't be anywhere."  But I doubt
that's what you meant, so could you clarify?

We know that we can't use NSEC in some applications -- if nothing
else, it appears to cause trouble under some data protection laws.  I
also believe it to be inconsistent with some contractual obligations
that some gTLDs work under.  So some people will have to use
something else.  NSEC3 is that something else, and the availability
of an NSEC3+NSEC mode for those zones won't help that, because those
people are never going to be able to deploy NSEC anyway.  Right? 

In that case, is your argument that they're never going to be able to
deploy at all, because NSEC/NSEC3/NSEC chains won't work?

A

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 May 2006 12:19:45 -0400

>that's what you meant, so could you clarify?

That or NSEC3 will be everywhere and NSEC will fade out.

>people are never going to be able to deploy NSEC anyway.  Right?

No.  If a registry never does NSEC, then it'll not be bothered by 
NSEC+NSEC3.  But for those who have to enter DNSSEC with NSEC, they 
will benefit from being able to provide both in responses.

>deploy at all, because NSEC/NSEC3/NSEC chains won't work?

I never said that NSEC/NSEC3/NSEC chains don't or won't work. 
They've not been demonstrated, tried, tested, etc.

Why do people think I am saying NSEC3 is not going to work?  There's 
a proposal for NSEC3.  Due diligence is to hack at it to make sure it 
is solid.  To do that you have to question the unclear parts for more 
definition and you have to test the clear parts.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 May 2006 12:43:46 -0400

> That or NSEC3 will be everywhere and NSEC will fade out.

[. . .]

> will benefit from being able to provide both in responses.

Ok, so can I restate your argument this way:

We will end up with NSEC or NESEC3, but not both.  Some people must
use NSEC3.  Therefore, we'll end up with NSEC3.  But some people must
start before NSEC3 is ready, so they will have to start with NSEC. 
Therefore, it is necessary to plan now for a mechanism whereby
servers may speak both NSEC and NSEC3 at the same time, for the
inevitable transition period that we'll have to live with

?

> Why do people think I am saying NSEC3 is not going to work?  

I'm not claiming anything at all about what you're saying: I'm trying
to restate it such that it's clear to me what you've said (i.e. when
you say "yes", I know what you're claiming).

If I have your view right this time, I think the objections will come
from the premise, "We'll have NSEC or NSEC3, but not both."  I think
someone has already argued in this thread that such a premise seems
to rely pretty heavily on relatively rapid deployment of NSEC, and I
am not convinced the evidence so far warrants such a belief.  

A

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 May 2006 13:12:45 -0400

I get the sense that folks think it is impossible to have a 
transition plan, therefore my request is a delaying tactic.  My 
comment was driven by a discussion midway or late in the workshop 
when it was realized that no one had thought much about a plan.

There were a few quickly sketched plans made then, but nothing 
well-baked, and nothing vetted.

>inevitable transition period that we'll have to live with

Yes, more or less.  I'd say "we will *probably* end up with..."  But 
other than that, yes.

Or to say it on the flip side, if we fail to consider transition, you 
place a large burden on the decision making process of zones ready to 
sign today - would you want to commit to NSEC now if it's possible 
that the rest of the world adopts NSEC3 in two years?

>am not convinced the evidence so far warrants such a belief.

Let's just take the .SE and RIPE zones.  What if they are the only 
ones running NSEC when NSEC3 rolls out?  Do we force them to undo 
DNSSEC for a transition phase to be like the rest of the world as a 
penalty for being early adopters?