Subject: DNSSec NXT records

From: Ramakrishna Gummadi <[email-masked]>
Date: Mon, 20 Aug 2001 03:42:06 -0700 (PDT)

Hi,
RFC2535 specifies that the NXT replies should contain the existing next
name in the zone but observes that query chaining through NXT records
can reveal all the names in a zone, even though zone transfers are
administratively prohibited. It also says that alternate NXT formats can
be specified in the future to avoid this.

I propose an alternate mechanism that avoids having to give out 
valid name in NXT replies: 
simply replace names with one-way hashes. This way, two signed one-way
hash values would be returned to prove that the non-existant name would be
translated into a hash that would lie within this interval.  

Everything else should just work fine.

-ramki

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

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 20 Aug 2001 10:46:32 -0400

ramki,

It's been suggested to replace the next domain name in the NXT record with a
hash of the name.  The proposal has been called the NO record
(draft-ietf-dnsext-not-existing-rr-01).  The current opinion/leaning of the
DNSEXT group has been to go with the NXT record instead of the NO (which is
still experimental, so some implementers may be using it).  Until someone
comes up with a "killer reason" for going with NO or some better way of
offering authenticated denial.

Your idea sounds different, but the NO record is very similar to your
suggestion.  If you think I've gotten something incorrect, feel free to
write up your idea as an Internet Draft and submit it to the IETF as an
alternate proposal to the NXT record.  It might bring the authenticated
denial discussion thread back to life (which may not be the best thing for
people suffering during the current list mail glut ;-)

Scott

---

From: Roy Arends <[email-masked]>
Date: Mon, 20 Aug 2001 18:00:17 +0200 (CEST)

> Everything else should just work fine.

Good idea, but already has been thought of:

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr-01.txt

Authenticating denial of existence in DNS with minimum disclosure
               (or; An alternative to DNSSEC NXT records)
                  draft-ietf-dnsext-not-existing-rr-01

Abstract

   This draft present an alternative to NXT records, used to achieve
   authenticated denial of existence of a domain name, class and type.
   Problems with NXT records, as specified in RFC 2535, are identified.
   One solution, the NO record, is presented.

   The NO record differ from the NXT record by using a cryptographic
   hash value instead of the domain name.  This prevent an adversery
   from collecting information by "chaining" through a zone.  It also
   remove delegation point concerns that was a side effect of NXT
   records.  The document also describe hash truncation and record
   merging that reduces storage/network load.

Regards,

Roy Arends
Nominum
-------------
0-14-023750-X dcrpt ths 43.0D.01 01.05.0C 84.18.03 8A.13.04 2D.0B.0A

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Mon, 20 Aug 2001 11:39:26 -0700 (PDT)

My thanks to all the folks who pointed me to this reference. I somehow
missed this completely. 

There is another unrelated idea I have been tossing about, that I think
can reduce public key data  required for TLDs within
KEY records, and can thus reduce traffic at root-servers when using DNSSec. 
I think this is an interesting idea (at least conceptually), and would
like to know if it has been brought up somewhere as well. 

The basic idea is to use names themselves as public keys; a name,
such as foo.com, can itself specify a public key k_p that
anybody can derive *offline* (given public constants of the algorithm, of
course). Like other public key schemes, a client should have beforehand 
the required algorithm 
constants for the "." zone; once there are known, however, a client can also 
automatically derive the public keys of gTLDs and ccTLDs, unlike in 
traditional public key cryptosystems such as RSA and DSA where 
public keys have to be separately created and explicitly delegated via
certificates, KEY RR data, etc.

One way to derive a publick key, k_pub, from a name, foo.com, could
be: k_pub=g^(h(foo.com)), where g is a generator in Z_n^*, n is the
RSA modulus, and h is a one-way hash function. This n can be the 
same one used in the RSA/MD5 algorithm by the "." zone. 
Like in RSA/MD5, it should be statically known to every client.

The corresponding private key, which only the "." zone will be able to
derive because only it knows the factorization of n, is k_priv such that 
h=k_pub*(k_priv)^d mod n, where d is the RSA decryption exponent of n, and 
h can be a public constant known statically to all, and same for all TLDs.

The "." zone would then give the k_priv private key to foo.com, which can
then prove to anyone it knows k_priv for foo.com, sign discrete
logarithm-based messages using k_priv, etc. Any gTLD and ccTLD can 
obtain private keys this way, playing the role of foo.com in the above
description.

This is basically a Brands/Okamoto algorithm whose security has been
proven elsewhere. Its attractiveness here is its ability to create
"self-certifying" tld's. 
One can think of the entire scheme as an public key mechanism that binds
names to keys tighter than alternate schemes using explicit certificates
would.

Any feedback is appreciated.

cheers,
ramki

---

From: Derek Atkins <[email-masked]>
Date: 21 Aug 2001 09:11:02 -0400

> Any feedback is appreciated.

While a clever algorithm, this presents a number of problems (mostly
operational):

 - The root zone has complete power over everyone (and knows
   everyone's private key)

 - Nobody can secure their own zone until the root buys into the
   process.

 - Anyone who wants to secure their zone must wait until they are
   handed their key by the root, which means they cannot pre-sign
   their data.

 - Re-Keying is a nightmare.  You effectively have to rekey everyone
   at once, and somehow have to tell all clients the new 'N' or 'H'
   values.

 - If 'N' is ever broken, it is hell in a handbasket to recover.  Keep
   in mind that the 'global N' would be a mighty appealing target.

Personally, I don't think the problems with DNSSec stem from the
amount of data stored in the DNS, or the size of KEY records or
anything like that.  Yes, the 512-byte problem _is_ a problem, but
that's easily surmountable.  

I don't think we need (or want) to change the current KEY/SIG
definitions or uses much, we just need to solve the delegation-point
problem.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available