Subject: DNSEXT WGLC: NO record

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 13 Mar 2001 11:37:08 -0500

This document proposes an alternate mechanism to NXT records to give
authenticated denial of existence answers. This proposal attempts to
address many of the shortcomings of NXT in a different way:
	- NO record encodes all names as digests using SHA-1
	- NO records are all stored in ._no.<zone> name space thus avoiding
	  the two NXT sets at the delegation point.
	- NO doubles the number of names in a zone.

This document obsoletes the NXT record, thus updates RFC2535.

This WG last call ends April 4'th 2001.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr.00.txt

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Brian Wellington <[email-masked]>
Date: Tue, 13 Mar 2001 21:00:52 -0800 (PST)

> This document obsoletes the NXT record, thus updates RFC2535.

I'm sure it's been said many times before, but it seems like a bad idea to
obsolete the NXT record before there's any real operational experience
with DNSSEC.  Replacing NXT with NO would take a non-trivial amount of
time and effort.

Also, a problem with the NO draft (as well as other drafts, including
opt-in) is that there's no way to specify security characteristics of the
zone.  Having a resolver support either NO and NXT is hard enough;
supporting both with no method of determining which is used for any
specific zone is much worse.  The SEC RR proposed by Ed Lewis a few years
ago would work, and it or something like it needs to be introduced again
before specifying alternate mechanisms for authenticated denial.

It hasn't been conclusively shown that replacing NXT with NO has enough
benefits to outweigh the problems.

I don't see a problem with NO continuing as a working group draft, and
possibly becoming a standard in the future, but I don't think now is the
right time.

Brian

---

From: Simon Josefsson <[email-masked]>
Date: 16 Mar 2001 18:44:04 +0100

> with DNSSEC.  Replacing NXT with NO would take a non-trivial amount of

I agree that more operational experience of DNSSEC/NXT would be good,
but I also think that the lack of deployment would make now a good
time for us to replace NXT and get away cheaper in the end.

Any "real" operational experience is still some years ahead, getting
DNSSEC in .com, .se etc is only a first step before organization's
start to use it for anything useful (secure name lookups, SSH keys,
PGP keys etc) and it's not until then "real" operational experience
can be collected.

> before specifying alternate mechanisms for authenticated denial.

I'm dense; could you elaborate on this?  Why do you need to know
before-hand if a certain zone uses NXT or NO?

I don't see how it affects how you construct the query -- if the query
doesn't return useful information, you either get nothing, NXT or
perhap NO back.  If you try to verify whatever you get back, you'll
end up in either one of two cases A) you trust that the query doesn't
have an answer, or B) you can't tell anything securely.  And that's
it.  Please enlighten me.

---

From: Brian Wellington <[email-masked]>
Date: Fri, 16 Mar 2001 10:37:06 -0800 (PST)

> time for us to replace NXT and get away cheaper in the end.

Maybe, but there is a widespread implementation implementation of NXT, and
not one of NO.  Adding NO support would take a while.

> PGP keys etc) and it's not until then "real" operational experience

That's arguable.  The European registries experimenting with DNSSEC (.nl,
.se, and maybe others) are getting real operation experience.  Hopefully,
if something is unusable, they'll find it.  It's not as widespread as if
.com is signed, but signing .com before others have operational experience
would be a disaster.

> have an answer, or B) you can't tell anything securely.  And that's

For a simple negative answer, it's probably easy enough to just look at
the answer and see if it contains NXT or NO records.

What happens if a (possibly spoofed) response contains both NXT and NO
records?  Attempting to validate both makes an already complicated state
machine even worse.  How does the resolver know which one to verify?

I don't think this is an unsolvable problem; it's just that the validation
process can be simplified by knowing whether to look for NXT or NO before
beginning the negative proof.

We will definitely need something that gives information about a zones
security (and other) status for the opt-in draft.  It doesn't make sense
to complicate validation for this and then go back and add an "NXT or NO"
bit later.

Brian

---

From: Simon Josefsson <[email-masked]>
Date: 16 Mar 2001 21:33:05 +0100

> .com is signed, but signing .com before others have operational experience

I agree with this.

What I thought about was that some of the problems with NXT might not
be visible at the registry level -- like the zone walking problem.
Registries won't consider it to be an issue, they don't store SSH host
keys, personal PGP keys etc in DNS.  Registries aren't the "end-users"
of DNS data. Once the registries (the infrastructure) use DNSSEC,
end-users are going to trust DNS more (SSH host keys etc) and maybe
then NXT will be regarded as a larger problem than before. I dunno.
My point is that we don't get much "end-user" operational experience
unless DNSSEC is already deployed within the infrastructure, and then
the cost for changing things might be too high.

But this is irrelevant if we reserve an enumerated type for different
authenticated denial mechanisms in a to-be-designed
zone-security-status information today.

>From a security point of view; if either one verifies, that's good
enough.  From a technical point of view; reject the packet as invalid
or outdated (it must be either one) and talk to someone else to get
more recent data.  There are some alternatives.