Subject: I-D ACTION:draft-ietf-dnsext-nsec3-00.txt

From: [email-masked]
Date: Thu, 27 Jan 2005 15:53:40 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: DNSSEC Hash Authenticated Denial of Existence
	Author(s)	: B. Laurie, et al.
	Filename	: draft-ietf-dnsext-nsec3-00.txt
	Pages		: 17
	Date		: 2005-1-27
	
The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be
   used to provide authenticated denial of existence of DNS ownernames
   and types; however, it permits any user to traverse a zone and obtain
   a listing of all ownernames.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-nsec3-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-nsec3-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Gilles Guette <[email-masked]>
Date: Fri, 28 Jan 2005 08:27:12 +0100

Hello,
I read your draft and maybe I missed something but with NSEC3 RR, how do 
you proove a NXDOMAIN ? Or how do you proove that the NSEC3 received is 
a covering NSEC3 ?

On the example given in the draft, if a resolver ask for "aa.example.com 
NS" it will receive the answer containing :

bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \
           SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \
           A TXT RRSIG NSEC3

How the resolver can deduce that this NSEC3 is a covering NSEC3 without 
the original ownername ?

Regards

--
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: Roy Arends <[email-masked]>
Date: Fri, 28 Jan 2005 09:11:36 +0100 (CET)

> How the resolver can deduce that this NSEC3 is a covering NSEC3 without

It can't deduce the original ownername from a hashed ownername (well, it
is highly unlikely).

The resolver knows what it has send, i.e. a query for 'aa.example.com.
NS'. It will then compare HASH(aa.example.com) with the received NSEC3
record.

Roy

---

From: Gilles Guette <[email-masked]>
Date: Fri, 28 Jan 2005 09:54:04 +0100

>It can't deduce the original ownername from a hashed ownername (well, it
OK

>NS'.
OK

> It will then compare HASH(aa.example.com) with the received NSEC3
>record.
>  
>
Assuming that HASH(aa.example.com)= GFA.........

The resolver sends a query for 'aa.example.com. NS'

It receives the NSEC3 of a.example.com

If you compare this to the NSEC3 of a.example.com, HASH(aa.example.com) is not in the range [ bfe6ea21dee9d228889ae11fa58c4bd551d15801...
F519593E82969842A136E0F47814C881FA163833]

what is the resolver's behaviour then ?

Could you correct or finish this scenario ?

---

From: Roy Arends <[email-masked]>
Date: Fri, 28 Jan 2005 10:06:18 +0100 (CET)

> what is the resolver's behaviour then ?

Short answer: the resolver will give a 'servfail' or similar error.

The long answer:

If the resolver sends a query for 'aa.example.com. NS',
it will NOT receive the NSEC3 of HASH(a.example.com).
It will receive (given that aa.example.com does not exist) the covering
NSEC3 over HASH(aa.example.com).

Before a zone is being served by an NSEC3 capable authoritative server:
1) Hashes are made for every ownername
2) Hashes are canonically ordered
3) NSEC3's are added, so that:
 (1st hash) NSEC3 (2nd hash)
 (2nd hash) NSEC3 (3rd hash)
 (Nth hash) NSEC3 (N+1th hash)
 (last hash) NSEC3 (1st hash)

4) zone is signed

In that way, HASH(aa.example.com), given it doesn't exist, will always hit
an interval, therefor will always be treated as non-existant.

Roy

---

From: Gilles Guette <[email-masked]>
Date: Fri, 28 Jan 2005 10:24:42 +0100

>an interval, therefor will always be treated as non-existant.
OK. When a name server receives a query for a non existant name, it must 
compute the hash of this name,
and send the covering NSEC3.

Thanks for explanation, maybe this can be written in the draft after the 
example.

---

From: Roy Arends <[email-masked]>
Date: Fri, 28 Jan 2005 10:31:51 +0100 (CET)

> Thanks for explanation, maybe this can be written in the draft after the

Good point !

Will add this to the draft.

Thanks,

Roy