Subject: Re: this week in dnssec, 10 years ago.

From: Mark Andrews <[email-masked]>
Date: Fri, 21 May 2004 10:05:31 +1000

> Surely someone would have come up with the following "solution" sooner or
> later, I just didn't know it was as soon as 10 years back :-)
> 
> > > Subject: Thought on non-existant and wildcarded names
> > > Date: Mon, 09 May 94 14:55:42 -0400
> 
> > > If it is desired to block NX walking, the recommended method is to add a
> > > zone wide wildcard of the KEY type which asserts the nonexistence of
> 
> Obviously a wildcard in the "registry zone" eliminates the need for any
> NXDOMAIN response and thus any "link" information coming from NSEC RRs, so
> that the "pointer" part may carry bogus information. Now, that's replacing th
> e
> devil with ... and I can't believe me writing this.
> 
> -Peter

	Actually it doesn't "registry zones" are treated like any
	other zone for validation.

	The wildcard response still need the NOQNAME proof to be
	sent to prove that the wildcard is actually the correct
	response and not a forged the response.  The NOQNAME proof
	will also prove if it is the correct wildcard answering the
	query or not. 

	NSEC2 does not supply the information to determine if the
	correct wildcard has been presented.  This is in the owner
	and next names of the NOQNAME NSEC proof.
 
	NXDOMAIN needs two proofs to be sent NOQNAME and NOWILDCARD
	(these may be the same NSEC record).  A wildcard response
	remove the need for the NOWILDCARD proof.

	For NSEC2 to work you would also have to send additional records.

	If the qname was a.b.c.d.e.f.example the NOQNAME proof becomes.
	one of:

	f.example does not exist.
	or
	a proof that f.example exist and a proof that e.f.example does not
	exist.
	or
	a proof that e.f.example exists and a proof that d.e.f.example does
	not exist.
	or
	a proof that d.e.f.example exists and a proof that c.d.e.f.example
	does not exist.
	or
	a proof that c.d.e.f.example exist and a proof that b.d.e.f.example
	does not exist.
	or
	a.b.c.d.e.f.example does not exist and a proof that b.d.e.f.example
	exist.

	The additional proof is to prove that there is no delegation,
	empty non-terminal.  From the above you can determine the
	correct wildcard that should be matched or the correct
	NOWILDCARD proof to look for.

	NSEC2 would also require a NSEC record for every empty
	non-terminal node.  ENUM will love this:-).

	Under NSEC there is implicit information buried in the
	names.  This has to be made explicit under NSEC2.

	Note: This is *just* a technical analysis of the proposal.

	Mark

> --
> 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/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Simon Josefsson <[email-masked]>
Date: Fri, 21 May 2004 10:33:02 +0200

> 	and next names of the NOQNAME NSEC proof.

No, I believe sufficient information is present.  To verify that any
wildcard RR doesn't cover the queried name, you compute a few SHA-1
hashes on the only possible wildcard owner names that can be relevant,
and compare with the additional NO records returned.  This logic was
described in the NO draft.

Regards,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 21 May 2004 16:13:40 +0200

[email-masked] writes:

> 	thats a bit presumptious, don't you think?  how can you 
> 	possibly determine relevant, possible owner names?

I may have misunderstood something.  Here is how I perceive things.

Consider any query for a non-existing name a.b.c.d.e.f.com in the zone
f.com.  To prove that a.b.c.d.e.f.com doesn't exist, the server has to
return records proving that the following names do not exist:

a.b.c.d.e.f.com
*.b.c.d.e.f.com
*.c.d.e.f.com
*.d.e.f.com
*.e.f.com
*.f.com

This is the same for NXT, NSEC and presumably all alternatives as
well.

With NXT/NSEC, the verifier can read the "next owner name" field of
the RRs, and make sure all above names are included in the range of
some of the returned RRs.

Since alternative solution doesn't have a "next owner name" field,
this technique doesn't work.  But the above set of possibly relevant
owner names is always a small number, so the verifier can compute the
hash of each of the above strings and verify that all are included in
the range of all NO RRs returned.

The only difference in processing is that during each wildcard
iteration, you compare the hash of the name instead of the name, with
what is stored in the returned RRs.

The second complication due to wildcard names is that when the
response exists and is a wildcard name, you must also prove that no
more specific owner name exists.  The logic is a bit different, but I
believe there is no problem implementing it with hashed names.

Were you thinking of some other problem?  Or is my reasoning flawed?

Regards,
Simon

---

From: [email-masked]
Date: Fri, 21 May 2004 12:23:33 +0000

> Simon

--bill