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.
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".
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.
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.
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.
Time T+n: Zone stops signing with NSEC3 keys and signs with NSEC keys only.
Cheers,
Ben.

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.

Wed, 17 May 2006, Edward Lewis wrote:

>In order to allow a rollover to NSEC3 from NSEC without going through
>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.

-- Sam

At 14:43 -0400 5/17/06, Sam Weiler wrote:
Wed, 17 May 2006, Edward Lewis wrote:

In order to allow a rollover to NSEC3 from NSEC without going through
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.
>
>
>

, 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?

Edward Lewis wrote:
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.

Sure thing.


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

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:

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?

They don't.


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

This is an implementation issue, surely?


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

Wed, May 17, 2006 at 05:38:17PM -0400, Edward Lewis wrote:
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.

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

At 8:28 -0400 5/19/06, Andrew Sullivan wrote:

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

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

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

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

Fri, May 19, 2006 at 11:27:15AM -0400, Edward Lewis wrote:
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. 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.

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

At 12:09 -0400 5/19/06, Andrew Sullivan wrote:

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

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

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

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.

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

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.

Fri, May 19, 2006 at 12:19:45PM -0400, Edward Lewis wrote:

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

[. . .]

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.

, 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

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.

At 12:43 -0400 5/19/06, Andrew Sullivan wrote:

>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

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

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?

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

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?