Subject: Preventing enumeration with the CURRENT DNSSECbis specification

From: "Michael A. Patton" <[email-masked]>
Date: Mon, 7 Jun 2004 00:53:42 -0400 (EDT)

[ Moderators note: This post needed manual approval.

   Either because it was posted by a non-subscriber or because it contained
   to many characters (> 20000).

   With the massive amount of spam, it is easy to miss and therefore
   delete posts that need manual approval.

   Please fix your subscription addresses or shorten your postings by adding 
   links instead of attachments ] 

Disclaimer: I think the WG needs to concentrate on getting the current
specs finished and out.  I thus hesitate to add yet another idea for
fixing NSEC, but felt that I needed to get this written down and out
for other eyes to see before I lost the idea.  So, please don't stop
work on the current docs, but if you otherwise have some time, I'd
appreciate any input.

This is all only half-baked so far, so it's not clear how tasty it
will be when it finally comes out of the oven.  But, unless we finish
cooking it, we'll never know. :-)  It occurred to me during that
semi-hallucinatory period between waking and full consciousness this
morning.  However, I've been thinking about it on and off for about 19
hours and it seems even better now than when it first occurred to me,
so I thought I should commit it to bits.  This scheme is entirely an
"implementation detail" and requires no change to the protocol and
docs as they presently exist.  However, there is one potential
improvement that can be added to the existing spec (after suitable
time to finish baking) that might improve things, but it can be
reasonably done later and should not hold up current work.  This
scheme does involve a tradeoff, but for zones that couldn't deploy
DNSSEC at all without it, the tradeoff should be a no-brainer.

The scheme comes in two parts:

The first idea is not especially novel, I've had it in the back of my
head ever since the initial discussions of NO, and it seems
sufficiently obvious that I expect others have had it, too.  It seems
simple for implementations to have a configuration to eliminate (or
possibly restrict to a small number of "debugging" hosts) direct
retrieval of NSEC RRs.  In normal use there is no reason to retrieve
these, they only exist as a means for the zone to prove that some
other queried name doesn't exist.  This is analogous to the way
implementations can already limit AXFR by means outside the protocol,
and just applies to QTYPE=NSEC rather than QTYPE=AXFR.  The reason I
never mentioned it before is that, by itself, it only complicates the
attacks by a small amount.  The reason I mention it now is that it
helps the main scheme, and was part of the inspiration for it.  The
inspiration was from realizing that the major problem with NSEC
records is that each one gives away TWO valid names.

Now, the main idea is to have an option in the auth servers that
generates synthetic NSEC records for each negative answer.  This NSEC
would cover as small a piece of the name space as possible, in fact
only the one name queried for.  Furthermore both names in the NSEC are
themselves invalid in essentially all cases (the "next" might
accidentally be a valid name, but since it's algorithmically derived
it doesn't give the attacker any information).  The tradeoff comes
here, this would only work if the key to sign these was online (more
on this later) since you only get authenticated denial when the NSEC
has an accompanying RRSIG.

Say for example, you are running the server for the TLD xx. and get a
query for foo.xx. which doesn't exist.  You return a NSEC with
foo.xx. as the owner name, _none_ of the type bits set, and the next
name field set to the next _possible_ name.  Thus this NSEC denies the
existence of one name (well, to be pedantic it says the name exists,
but that there are no RRs), and gives no information about any legal
names.  The thing that might seem hard is generating the next possible
name, but that's simply the same name as the owner, with one
additional zero byte in the first label (unless the label is already
63 bytes long, in which case increment the last byte, overflowing into
earlier bytes).  This name is not a host name (in fact, it's probably
non-existent), so the non-ASCII character doesn't matter.  You also
need to generate and return an RRSIG for this NSEC, thus such a zone
would need to run with (at least one) key online.

Therefore, for zones that have a non-disclosure requirement, the
tradeoff is between not running DNSSEC at all or running it with an
online key.  Presumably, since they have that requirement (and for
many other reasons), they are already being very careful with security
of all their auth servers, this tradeoff should be pretty simple.  Any
attack that could compromise the online key could have done as much
damage if they hadn't deployed DNSSEC at all, and anything short of
that can't compromise the secured zone, but might compromise the
unsecured one.  Thus while not as secure as "standard" DNSSEC, it's
much better than the defalut unsecured operation and "almost" as good
as full DNSSEC (operationally the same, with the extra exposure of the
online key).

The exposure of having an online key could even be alleviated by
having multiple keys for the zone: a set that changes very slowly, is
kept off-line and is used for the signing of the positive info; and a
second set, changed more often, with shorter lifetime, used only for
signing the NSEC responses.  With this scheme, the exposure in the
case of a compromise of the online key is limited by its shorter
lifetime, but the bulk of the zone, signed with the longer lived and
more securely held key, doesn't need to be signed any more often.
There would be some additional administrative overhead to manage the
extra short-lived key(s), either you need to generate and distribute
the private part to all servers, or you could have one in each server
that it generates itself, and then updates (with dynamic update and
TSIG?)  the public part at the master.  The first has only one key,
but requires moving the private part over the net, while the later has
some added exposure from multiple keys, but never passes the private
parts over the net...

The one thing that might be added to the existing specs (later, not
now) that would help out here is allocating one of the 14 unused flag
bits in the DNSKEY RR to convey the intent of only signing NSECs.  By
doing this, resolvers that understand the bit would be even more
immune to compromises of the online key, the compromised key could
only be used for invalidating existing delegations, and would be
ignored for positive data, thus eliminating the possibility of
introducing new authenticated data using that key.

	-MAP

--
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/>