Subject: Re: NSEC3 signalling mechanism

From: Samuel Weiler <[email-masked]>
Date: Thu, 13 Oct 2005 16:24:06 -0400 (EDT)

On Mon, 15 Aug 2005, Ben Laurie wrote:

> I do not understand why it is necessary to signal that the child
> zone is using NSEC3.

With all due respect, this WG seemed to conclude that signalling was
necessary well over a year ago.  Unless you have some specific
argument that we were wrong, I'd rather not revisit the topic.

Most of the relevant messages can be found in the namedroppers
archives between May 20th and June 2nd of 2004, specifically the
discussion bounded by these two messages:

http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00489.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00824.html

Notable specific messages include:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00672.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00594.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00656.html

As well as:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00893.html

-- Sam

--
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: Ben Laurie <[email-masked]>
Date: Thu, 13 Oct 2005 21:59:36 +0100

> http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00893.html

With all due respect, discussion is not conclusion. Futhermore, the 
discussion isn't that illuminating - all I can work out from it is 
concerns that if you don't understand NSEC3 you can't work properly in 
an NSEC3 world. This is not surprising.

If you want comment on a concrete proposal, then propose one.

Cheers,

Ben.

-- 
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: David Blacka <[email-masked]>
Date: Thu, 13 Oct 2005 18:09:50 -0400

>>> I do not understand why it is necessary to signal that the child

A Blast From The (not-so-distant) Past!  I had to scroll back quite a  
ways in my mail client to find the genesis of this thread.

> concerns that if you don't understand NSEC3 you can't work properly  
> in an NSEC3 world. This is not surprising.

No, it isn't surprising.

Signaling is desired so we can have all the following conditions  
simultaneously true:

1. There are non-NSEC3-aware resolver/validators deployed.
2. They have trust anchors to zones above NSEC3 signed zones (like root)
3. NSEC3-aware validators have the same trust anchors (like root)
4. NSEC3-signed zones are not broken the to validators in group 2.

Signaling is to protect the legacy validators.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 25 Oct 2005 14:34:13 -0400 (EDT)

On Thu, 13 Oct 2005, Ben Laurie wrote:

> ... all I can work out from it is

If "can't work properly" means "you (the NSEC-classic-only resolver)
see NSEC3 zones as Insecure", that's fine.  That's a tolerable form of
"can't work properly".

Without a signaling mechanism, I think we instead have "you see
negative answers from NSEC3s zone as Bogus (when you have a secure
entry point into that zone, perhaps as a DS record in an NSEC-classic
parent)".  That's a form of "can't work properly" that I see as
dangerous.

Assuming the root were signed with NSEC-classic and you sign your TLD
with NSEC3 -- if you have the root publish a DS for your zone, BIND
9.3-era resolvers (and perhaps later) may see your zone's negative
answers as bogus, and not through any fault of their own.  Do you
really want to sign your TLD with NSEC3 under those circumstances?

> If you want comment on a concrete proposal, then propose one.

I did.  See:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01087.html

-- Sam

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 Oct 2005 10:18:54 +0200

> really want to sign your TLD with NSEC3 under those circumstances?

One option is to have one NSEC record to deny everything in the zone,
just so that legacy resolvers can accept the data.  Attackers can deny
everything in the zone, but I believe that would be an acceptable risk
given the circumstances.

On the other hand, I seriously doubt that the deployed base of
application that require DNSSECbis is large enough so that this is a
practical problem.  If you switch to pure-NSEC3 and forget about NSEC
users, these users will realize they bought a poor solution and
switch.

Thanks,
Simon

---

From: bert hubert <[email-masked]>
Date: Wed, 26 Oct 2005 10:47:38 +0200

> users, these users will realize they bought a poor solution and

No, they will realise that the adage that DNSSEC is perpetually "ready 6
months from now" is as true as ever.

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

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Oct 2005 12:08:18 +0100

> parent)".  That's a form of "can't work properly" that I see as

Why? Anyone who cares can investigate, observe that in fact the problem
is that they are getting NSEC3 records and their resolver doesn't
understand them, and fix the resolver.

> really want to sign your TLD with NSEC3 under those circumstances?

It doesn't sound like a massive risk to me.

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

OK. If the WG decides that signalling is necessary then either of these
proposals works for me.

Perhaps the productive thing to do at this stage is to figure out
whether we think signalling is needed or whether the fact that DNSSEC
has such limited deployment means we can forget about it this time
(despite the theoretical need for it)?

Cheers,

Ben.

---

From: Matt Larson <[email-masked]>
Date: Wed, 26 Oct 2005 11:14:20 -0400

> (despite the theoretical need for it)?

Another factor to consider in making this determination is the
unlikelihood that .com and .net will be signed using NSEC.  VeriSign
is quite interested in NSEC3, especially its authoritative-only
feature.  Dave Blacka has implemented NSEC3 in his authoritative
server, which we will test in the NSEC3 workshop that Olaf is
arranging.

We are focusing our efforts on kicking the tires of NSEC3.  Multiple
parties have expressed interest in the features it provides, so we
think it's important that the working group keep NSEC3 moving along.

Matt
--
Matt Larson <[email-masked]>
VeriSign Naming and Directory Services

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 Oct 2005 15:26:15 +0000

# > Without a signaling mechanism, I think we instead have "you see negative
# > answers from NSEC3s zone as Bogus (when you have a secure entry point into
# > that zone, perhaps as a DS record in an NSEC-classic parent)".  That's a
# > form of "can't work properly" that I see as dangerous.
# 
# Why? Anyone who cares can investigate, observe that in fact the problem is
# that they are getting NSEC3 records and their resolver doesn't understand
# them, and fix the resolver.

i don't think that a failure mode this unpleasant should be the result of
not caring enough to investigate.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 Oct 2005 18:28:41 +0200

> not caring enough to investigate.

There are no non-experimental DS delegations in live zone's today, as
far as I know.  So I believe a flag day would be fine, since there are
no real users that would be harmed by that.

Cheers,
Simon

---

From: Ben Laurie <[email-masked]>
Date: Wed, 26 Oct 2005 22:02:18 +0100

> not caring enough to investigate.

How unpleasant is it to get "bogus" for a domain that doesn't exist? As
opposed to "I can't resolve anything securely in this domain", that is?

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 28 Oct 2005 10:25:58 -0700

> everything in the zone, but I believe that would be an acceptable risk

It is hard to assess 'acceptable risk' but I would rather keep the  
property that data modification leads to "BOGUS" results instead. It  
feels bad to change the security properties of DNSSECbis to get NSEC3  
deployed.

Personally I would like to keep backwards compatibility. I do not  
agree with the notion that people wo deploy DNSSEC bis bought a poor  
solution.

There is real DNSSEC deployment happening --- on a small scale, I  
agree. Lets not dismiss those initiatives and demotivate early  
deployment by forcing a flag date.

I would have to check the archives but I think that at the time we  
forwarded DNSSECbis we decided that privacy protection could be added  
while maintaining backwards compatibility. The work on the particular  
mechanism is still in progress.

--Olaf
    namedropper, not wearing hats.

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/