Subject: Re: KEY/SIG/NXT classless (was Re: [Design] Re: the KEY debate)

From: [email-masked]
Date: Tue, 06 Aug 2002 08:12:40 +1000

> 
> > [email-masked] writes:
> > 
> > > 	There is no shortage of types.  If we exhaust IN then we can
> > > 	add another class.
> > 
> > Actually KEY/SIG/NXT apparently isn't restricted to IN.  From
> > dnssec-records:
> > 
> >    The KEY RR is class independent.
> > 
> >    The SIG RR is class independent, [...]
> > 
> > The IANA DNS registration page should probably be updated, it says
> > KEY/SIG/NXT is for IN only.
> 
> 	No.  KEY/SIG/NXT are for securing the DNS *independent* of

	I just re-read what you said.  Yes IANA's page needs to be
	updated if it says IN only.
 
> 	You missed the entire point of the statement I made.
> 
> 	If you exhaust the type space in IN then you have additional
> 	classes that you can use.
>  
> > Also, NXT doesn't provide authenticated denial across IN boundaries.
> > 
> 
> 	This makes no sense.
> 
> 	Mark
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--
Mark Andrews, Internet Software Consortium
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: Tue, 06 Aug 2002 01:33:10 +0200

>> 	You missed the entire point of the statement I made.

It was a side comment, I was not trying to rebute your statement.  I
should have made that more clear.

>> > Also, NXT doesn't provide authenticated denial across IN boundaries.

Sorry, try parsing it again after s/IN/class/.

My point is that there is no authenticated denial when different
classes are specified in a query.  Consider a query for
(www.example.org., HESIOD, KEY), what data is returned that securely
convince the client that there isn't an answer?  We are back to
trusting NOERROR with empty answer field, or something similar.
Again, this was a side remark and is probably not important until
there is any serious non-IN deployment.

---

From: [email-masked]
Date: Tue, 06 Aug 2002 09:54:13 +1000

> there is any serious non-IN deployment.

	HS is local secure.  You configure your nameservers with
	the top of the local heirarchies and the keys for them.

	If you are moving to a new class because we have exhausted
	the type space in IN then you publish new roots for the
	new class (they may be the same as the existing roots),
	You publish the keys for the new roots (again if the roots
	a co-located with IN roots you could use the same key).

	This could actually start out being globally secure.

	Mark