Subject: Re: comments on nsec3-01

From: [email-masked] (Ted Lindgreen)
Date: Thu, 3 Mar 2005 12:37:35 +0100

[Quoting Ben Laurie, on Mar  3, 11:37, in "Re: comments on nsec ..."]

> As Alex has pointed out, no new complications. This issue is there 
> throughout DNSSEC.

I'm affraid, I do not agree, and I think most of the protocol
community here feels that NSEC3 does introduce new complications.

What bothers me is that the desire of a few to obscure part of the
data for which DNS is designed to make it available, now seems to
lead to a situation where part (or most?) of the users (all but the
members of the dnssec-of-the-month-club) must settle with either
reduced functionality (SERVFAIL) or reduced security (or be "plain
stupid" to quote Roy).

Regards,
-- ted

--
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: Thu, 03 Mar 2005 11:59:02 +0000

> community here feels that NSEC3 does introduce new complications.

You are conflating two issues: complexity internal to the resolver
(everyone agrees some of that is introduced), and different external
data state (i.e. complexity of the resolver interface) - whilst you
may think the external interface is more complex, I do not think
"most of the protocol community" agrees.

> data for which DNS is designed to make it available,

That is a disputed premise which I would suggest we have been asked
not to debate here again.

> now seems to
> reduced functionality (SERVFAIL) or reduced security

This is palpable nonsense - sorry. The *users* of the DNSSEC protocol
will
a) See no change in functionality AT ALL except in zones where NSEC3
   is deployed
b) See no change in functionality AT ALL if a zone signed using NSEC
   were changed to NSEC3 (without opt-in) and the hash algorithm used
   was known to the resolver (which is no higher a hurdle than requiring
   the signature algorithm is known to the resolver).
c) Can see unauthenticated denial of existence (i.e. the opt-in
   non-existence condition) exactly the same as the legacy unauthenticated
   denial of existence (i.e. NXDOMAIN unauthenticated) unless they choose
   to go into things more deeply and dig into why the result is
   unauthenticated (opt-in, vs vanilla DNS) - how many users will care?
d) See unsupported hash protocols in the same way they see unsupported
   signature RRs.

Exactly HOW does this reduce functionality for the user, or security,
given that the resolver must already code with non-DNSSEC names, and
with signature algorithm incompatibilities? Certainly it doesn't
affect functionality when resolving non-NSEC3 signed zones AT ALL,
nor NSEC3 (as opposed to NSEC signed zones) when hash algorithms are
supported and opt-in is not used.

Clearly NSEC3 signed zones that do use opt in do reduce security in terms
of denial of existence. BUT THAT IS THE POINT! However, they increase
security over (entirely) unsigned zones.

Alex

---

From: Ben Laurie <[email-masked]>
Date: Thu, 03 Mar 2005 12:02:35 +0000

> community here feels that NSEC3 does introduce new complications.

I meant no new complications in the interface between the resolver and 
the application.

> reduced functionality (SERVFAIL)

SERVFAIL is suggested as the consequence of failure to validate a 
supposedly secure response. This is not caused by NSEC3, it can happen 
with any DNSSEC response.

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