Subject: Proposed NSEC/NSEC3 transition mechanism

From: Ben Laurie <[email-masked]>
Date: Wed, 17 May 2006 08:03:36 -0700

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.

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

--
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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 18 May 2006 06:57:17 -0700

> [mailto:[email-masked]] On Behalf Of Edward Lewis

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

I do not see such a need. 

In the first place one of the the original premises for NSEC3 was that a walkable zone would be in breach of EU privacy regulations the only transitions required would be between NSEC3 and a successor or NSEC3 and no DNSSEC.

Secondly as a security specialist I think that Ed vastly over states the degree of dependency that is likely to be created within the scope of the early deployment.

I think DNSSEC is important as a security specialist but it is going to take a huge effort to convince the world of that. Premature reliance has never been a problem in previous deployments.

It may be important to create such documents for specific deployment instances but there is a vast difference between operational documents relating to a specific deployment and a standards document. I see neither use nor justification for developing a document that describes a transition between every possible configuration of two schemes in the absence of any stated interest in making such a transition.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 May 2006 10:37:52 -0400

At 6:57 -0700 5/18/06, Hallam-Baker, Phillip wrote:

>In the first place one of the the original premises for NSEC3 was that a
>walkable zone would be in breach of EU privacy regulations the only
>transitions required would be between NSEC3 and a successor or NSEC3 and no
>DNSSEC.

This may be the case, but "original premises" often become historical 
footnotes.  (Recall my presentation about DNS to the MARID interim 
meeting where I was told to stop telling the amassed audience why 
things in DNS are the way they are - blaming it on original premises.)

Looking at what NSEC3 offers, it goes beyond EU privacy regulations. 
If it were just that, why hack the DNS when whois is the real culprit 
(in the disclosure of identifying information)?  (Yes, I know that 
NSEC's point a miner to the data in whois, but the data *is* in 
whois.)  The Brazilian registry is (alleged come to think of it) also 
interested in NSEC3.  One of the points made by Nominet engineers is 
that they are concerned by the traffic load zone walking attempts 
would engender.  I mention this because I think it would be foolhardy 
to restrict an analysis of NSEC3 to the context of the original 
premises.

I go further to say that NSEC3 may wind up being used in ENUM and the 
like zones.

>Secondly as a security specialist I think that Ed vastly over states the
>degree of dependency that is likely to be created within the scope of the
>early deployment.

Would you clarify what you mean by this comment?  I hope the 
"security specialist" doesn't apply to me, nor an I sure what you 
mean by "vastly over stat[ing]...dependency."

>I think DNSSEC is important as a security specialist but it is going to take a
>huge effort to convince the world of that. Premature reliance has never been a
>problem in previous deployments.

I am at a loss to respond to that too.  I would think that premature 
reliance has been a real pain in many arenas, I recall a lament that 
one vendor shipped DHCP code based on a draft, forcing a WG into 
sticking with a bad solution in 1999.  Not to demean the involved 
parties then, but it's the most descriptive example of premature 
reliance I know of.

>It may be important to create such documents for specific deployment instances
>but there is a vast difference between operational documents relating to a
>specific deployment and a standards document. I see neither use nor
>justification for developing a document that describes a transition between
>every possible configuration of two schemes in the absence of any stated
>interest in making such a transition.

Since the SiteFinder incident and fallout is that IETF protocols do 
not stand on their own.  IETF defined protocols assume a carefully 
crafted operational environment.  Although the introduction of the 
wild card into COM and NET back then fell well within DNS protocol 
design and specification, there was a huge operational backlash, with 
misaddressed mail suddenly getting delivered as if it were corrent, 
spam blockers failing to find names as not in DNS, etc.

An example of not considering operstions -  RFC 2065 and 2535.  These 
two earlier attempts at DNSSEC had no and then just some operations 
input.  RFC 403[345] are said to be improvements based on operational 
input.

My raising this issue now could be seen as a means to delay NSEC3, in 
the sense that asking for "one more thing to be defined."  The 
"victims" of this are zones that have reasons to not deploy NSEC, but 
not discussing this will cause problems for zones that are under 
pressure to deploy NSEC now and in the coming time - and then may be 
told to transition later.  Because I think such considerations are 
distasteful, I've held back from making comments, but I'm also tired 
of seeing history repeat itself.

Meaning - we need to consider operations.  Might as well be now.

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

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

---

From: Alex Bligh <[email-masked]>
Date: Thu, 18 May 2006 15:58:17 +0100

--On 18 May 2006 10:37 -0400 Edward Lewis <[email-masked]> wrote:

>> transitions required would be between NSEC3 and a successor or NSEC3 and
>> no DNSSEC.
>
> meeting where I was told to stop telling the amassed audience why things
> in DNS are the way they are - blaming it on original premises.)
>

I agree with Ed here in as much as I think having a path between NSEC2 and
NSEC3 (and possibly vice-versa) that does not at any time make the zone
less secure/functional than the least secure of the start point and end
point of the transition is probably a requirement. In practice I think that
boils down to a transition between NSEC2 and NSEC3 (and possibly
vice-versa) not making the zone return bogus or insecure results where it
would not have done so as a "pure" NSEC2 or NSEC3 zone ab initio (obviously
taking an NSEC2 zone and making it NSEC3 only is at some point going to
cause NSEC2 only resolvers to fail).

Similarly between no DNSSEC and NSEC3.

But I'm not sure the requirement goes a long way beyond that, does it?

I also agree that if we are looking for wide adoption, our security
yardstick should be the protocol itself, not merely looking at the
likely use-cases of those who advanced it.

Alex

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 18 May 2006 09:07:46 -0700

> From: Edward Lewis [mailto:[email-masked]] 

> This may be the case, but "original premises" often become 
> historical footnotes.  (Recall my presentation about DNS to 
> the MARID interim meeting where I was told to stop telling 
> the amassed audience why things in DNS are the way they are - 
> blaming it on original premises.)

What people were complained about was your refusal to listen to anyone. Assuming you know what someone is going to say and then talking over them as they attempt to say it is not a particularly efficient form of communication even when you know what they are going to say which you did not.

I had to personally ask you to stop interrupting six times before I managed to say my first sentence.

I am not sure how you would know what I intended to say in the meeting since I am pretty sure that I forgot half of it while you were heckling. 

It is one thing to interrupt someone who has been talking for five minutes with a well placed point of information, quite a different thing to do as you did and drown out their attempt to complete a single sentence. 

> Looking at what NSEC3 offers, it goes beyond EU privacy regulations. 

True, but the point I was making was that NSEC has been determined to be incompatible with those regulations and so it is illogical to posit a requirement to plan a transition from NSEC3 to NSEC absent either contrary legal advice or a liklihood that the relevant laws will be changed.

> My raising this issue now could be seen as a means to delay 
> NSEC3, in the sense that asking for "one more thing to be 
> defined."  The "victims" of this are zones that have reasons 
> to not deploy NSEC, 

No the victims would be the billion plus users of the Internet who have waited far too long while this committee and others have traded concerns over minutiae and constantly argued and re-argued the question of whether to actually take account of real world operational constraints. Meanwhile we have an infrastructure that everyone agrees is critical that falls far short of providing acceptable security.

Operational issues are an issue for registrars and the customers they serve. 

In DKIM we are building infrastructure that effectively presupposes a certain level of security in the DNS infrastructure. I have no involvement in the VeriSign work on DNSSEC but I am most certainly working on infrastructures that presupose their timely deployment.

I have been asking this WG to deliver a set of standards that the registrars are prepared to deploy for six years now. Each time it appears that delivery of a standard that the registrars are prepared to deploy it has been trumped by procedural tactics and last minute invention of 'operational requirements' that are not endorsed by a registry planning to actually deploy the proposed scheme.

I suggest that unless Ed plans to actually deploy NSEC3 he should not be permitted to attach new requirements for advancement at this late stage in the process.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 May 2006 12:24:31 -0400

At 18:05 +0200 5/18/06, Roy Arends wrote:

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

I used to agree, but not post-workshop and not trying to work this 
into an operational scenario.  If the goal is to conform with a 
requirement to use NSEC3 and still support NSEC-era validators, there 
is a reason to return both.  Being able to do both affords much more 
flexibility in transition, affords greater stability.

---

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

> flexibility in transition, affords greater stability.

If we didn't happen to already pass this station a long time ago, I'd make 
this an explicit NON-requirement. 

Domain-holders have to choose between serving to NSEC-only resolvers or 
NSEC/NSEC3 capable resolvers, where the tradeoff is between deployed base 
and zone-enumeration.

Roy

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 May 2006 15:21:03 -0400

>If we didn't happen to already pass this station a long time ago,

I've heard this statement quite often in IETF discussions.  I think 
it is a symptom of what is wrong in the IETF approach to solving 
problems.  Requirements shift.  And sometimes people don't speak up 
until they can spend time on it.

In particular, I didn't have time to slog through a lot of the early 
discussions on NSEC3, especially the crypto talk.  I had to wait 
until it got to some level of solidity before I could imagine it in 
an operations setting.  That's why I'm passing the station again.

>NSEC/NSEC3 capable resolvers, where the tradeoff is between deployed base

I think this is an unrealistic expectation.  Once you force the 
server to choose among what dialect of clients it speaks to, you've 
split the network.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: bert hubert <[email-masked]>
Date: Fri, 19 May 2006 01:17:08 +0200

On Thu, May 18, 2006 at 09:07:46AM -0700, Hallam-Baker, Phillip wrote:

> No the victims would be the billion plus users of the Internet who have
> waited far too long while this committee and others have traded concerns
> over minutiae and constantly argued and re-argued the question of whether
> to actually take account of real world operational constraints. Meanwhile
> we have an infrastructure that everyone agrees is critical that falls far
> short of providing acceptable security.

Amen to that. So can we drop DNSSEC already? It has become so complex it is
a running gag in many places. Duke Nukem Forever is rumoured to appear
before DNSSEC is deployable. How about DNS2. It worked for POP3 and IPAM4.

This would give us the ability to add a signable "empty recordset" answer and
change the awkward semantics that have made DNSSEC the elephant it is today.

Think how simple life would be if we could send out recordsets instead of
sets of records, and sign such recordsets...

We could also sign empty recordsets, which would Just Work.

Registries could start offering DNS2 services, recursors would transparently
translate back to DNS1 for the vast masses that can't yet talk DNS2.

Etc etc. Think how much fun it would be to actually *achieve* something that
could be deployed! 

The amount of effort sunk into DNSSEC would've given us DNS2, 3 and 4 by
now..

Oh well, I can hope.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Roy Arends <[email-masked]>
Date: Fri, 19 May 2006 01:31:04 +0200

> until they can spend time on it.

Sure, it is easy for me to say "we're past that station", but what else is 
there. Should I blindly accept random requirements, stop process, go back 
to the drawing board, stall, convince others that this new item is really 
a new requirement ? 

I guess I did the following: Looked at what you're proposing, did not 
agree with what you're trying to propose. Trying to tell you why I don't 
agree with your proposal. As a result, I see most of my comments 
disappear.

Note that we bend over backwards to satisfy the new 'secure during 
transition' requirement. We _have_ satisfied it. Maybe not to _your_ 
satisfaction, but we can only do so much.

> discussions on NSEC3, especially the crypto talk. 

Luckily, the rest of us did have _lots_ of time, especially for the crypto 
talk.

> I had to wait 

What we're trying to do is built something that might actually work. What 
you're proposing is not realistic (read below why), and when I try to tell 
you that, you're not listening. Would you rather have the train wait until 
you catch up? 
 
> server to choose among what dialect of clients it speaks to, you've 

Okay Ed, one more time: You are proposing to serve hashed data to avoid 
enumeration, and at the same time clear data to help those not 
understanding the hashed data, which leads to enumeration.

As an analogy: Serving encrypted text to avoid evesdropping, while at the 
same time serving cleartext for those who do not understand the crypto 
algorithm.

Sure this is technically feasible. Sure we did not test it in a test 
environment. Sure we need to built a lot of code for that. Sure it brings 
new complexities. We didn't do it because it makes no sense. It is the 
exact same reason why this is not a requirement: it makes no sense; and 
why I will try to make it an explicit NON-requirement when that station is 
going to be moved to the train again: because it makes no sense.

Meanwhile, we have satisfied the 'secure during transition' requirement.

Lets move on!

Roy

---

From: Roy Arends <[email-masked]>
Date: Fri, 19 May 2006 01:36:52 +0200

> Luckily, the rest of us did have _lots_ of time, especially for the 
crypto 

Forgot the smiley:    ;)

Roy

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 21 May 2006 01:48:20 -0700

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

If it is necessary to do so: yes.

I don't think that it is necessary to develop a general transition strategy that guarantees a successful transition from every possible NSEC configuration to every possible NSEC3 configuration in order to successfully transition those domains.

I do not believe that the transition between NSEC and NSEC3 is any different to any other DNSSEC transition. If the DNSSEC transition mechanism is broken then its broken for all transitions. I do not believe that any further theorising is going to be useful until we collect experience of actually making a transition.

If you are operating core Internet infrastructure then expect to be required to make constant security upgrades. 

We are under attack from organized crime. Their tactics keep changing. We must be prepared to adapt and adjust our strategy in response.

---

From: bert hubert <[email-masked]>
Date: Sun, 21 May 2006 11:37:02 +0200

On Sun, May 21, 2006 at 01:48:20AM -0700, Hallam-Baker, Phillip wrote:

> We are under attack from organized crime. Their tactics keep changing. We
> must be prepared to adapt and adjust our strategy in response.

We must be scaring the pants of these people with our non-zug-endet-hier
algorithms.

Also, to quote Kernighan: 

	Everyone knows that debugging is twice as hard as writing a program
	in the first place. So if you are as clever as you can be when you
	write it, how will you ever debug it?

The applies just as well to programs as to protocols. Most people would
agree DNSSEC is "as clever as we can be". It is at least for my limited
brain.

So who here honestly thinks we won't be needing NSEC4 or DNSSEC-ter?

I'm still hoping for common sense to break out. Most of us here have been
around the block more than once with protocol design, and most of us should
therefore recognise the writing on the wall by now.

Oh well..

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 21 May 2006 09:09:44 -0700

> From: bert hubert [mailto:[email-masked]] 

> We must be scaring the pants of these people with our 
> non-zug-endet-hier algorithms.
> 
> The applies just as well to programs as to protocols. Most 
> people would agree DNSSEC is "as clever as we can be". It is 
> at least for my limited brain.

Fortunately when we debug the program we have the help of the computer which has a much better understanding of what its response to the commands we issue will be than we have ourselves.

When debugging a program I start with a very clear idea of what each part of the program is intended to do. I then design test procedures that are intended to verify that it does in fact perform as I expect.

It seems to me that at this stage the group has captured as much understanding of the problem that can be usefully gained by theory. It is time to test this particular module. Six years is ample time to have waited.

Requirements capture is not the same as debugging. Until you build the system and observe how it is used by P-E-O-P-L-E you won't understand the real requirements. We are dealling with a bunch of people that are not even users, they are wreckers.

> So who here honestly thinks we won't be needing NSEC4 or DNSSEC-ter?

We could have got to this point five years ago if people had been willing to accept the validity of the use cases and requirements raised. I find it somewhat ironic to see that the possibility we might not have captured every imaginable requirement and fulfilled it is being used to argue against this attempt to meet requirements that have been identified.

If you have a requirement that you think is a show stopper then raise it. But don't ask for the whole world to stop while we wait on the possibility that you might come up with something.