Subject: Zone enumeration, requirements, and security redux

From: "Loomis, Rip" <[email-masked]>
Date: Thu, 2 Sep 2004 09:57:28 -0400

Previously, on 11 August, I sent a message to the list
which can be seen at
  http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01465.html

Based on Olaf's last e-mail I wanted to summarize that
message and talk about some other related issues (such
as getting one agreed-upon definition for "security by
obscurity") but I couldn't fit the full argument into
20 lines.  I also wanted to make one last call for
desirements and requirements related to NSEC/zone
enumeration/etc--so that Ben and I can get a next draft
of the collected requirements out for review and
prioritization.

Bottom line--I believe that a replacement for NSEC
that does not provide for easy zone enumeration is
both worthwhile (will make it easier to address both
privacy and security concerns that DNS users will
have) and realistic.  I further believe that it *should*
be possible to find a replacement for NSEC in parallel
with an initial roll-out of DNSSECbis to several
major zone.

I only wish I'd whined more about NXT zone walking back
in 1999, when I first decided that it might be a
real stumbling block for DNSSEC acceptance.

Comments on the above, and *any last requirements*
requested.

  --Rip    (And yes, I *still* went over 20 lines.)

--
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: Edward Lewis <[email-masked]>
Date: Thu, 2 Sep 2004 11:47:13 -0400

>Comments on the above, and *any last requirements*

These are derived from what I've mentioned in the past.  (It's hard 
to know what's meant by "last" in any last requirements without 
seeing the list.  So to be on the safe side...)

     [Find] a way to prove the non-existence of a name without
         - exposing any of the contents of the zone
         - muddying up the name space with fake names or data sets
         - on-line cryptographic operations
         - being vulnerable to replay attacks of the negative answer
         - incompatible changes with NSEC

...that's a bit strongly worded.  Of course, you pretty much have to 
break one of them to continue onward.  E.g., NSEC breaks #1.

Here's another...
      Find a way to deny the existence of a DS RR set, when appropriate.

(I.e., if the decision is to make auth denial optional, DNSSEC is 
toast unless you still account for saying "security stops" here.)

I'll add one more observation.  In the reverse map name space, zone 
enumeration is not something we can fight.  There's more to this 
though.

Many folks on this list are familiar with the Shared Registry Model 
that is in use by some of the ICANN-somethinged zones. 
(.com/.net/.biz/.org/etc.)  In the model, there is just one registry 
(organization) that is producing the zone.

Because the reverse map space predates the RIR system, the RIR's have 
to co-manage zones.  Kind of like a shared *registry* model, with 
multiple writers to a zone.  This makes operations a lot more 
complicated, especially when the different registries are globally 
dispersed.

Combining the futility of stopping zone enumeration in the 
in-addr.arpa and ip6.arpa with the extra complication of multiple 
management of some of the reverse map zones, I'd encourage any 
alternative to the NSEC proposal be

         - different only transparently to the resolver/validator
         - intended to coexist with NSEC for a long time
         - not require any undo operations effort on those content with NSEC

E.g., I can't see the four established and one emerging RIR having to 
manage all of the on-line keys needed to support the on-line 
approaches, no matter how true to the protocol the on-line signing 
approaches are.  It could be done, but quite a lot of work for 
nearly/absolutely no gain.

Perhaps - my requirements here aren't yes/no, but rather criteria (graded).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Sep 2004 18:31:41 +0200

>     [Find] a way to prove the non-existence of a name without
...
>         - muddying up the name space with fake names or data sets

What does this mean?

The simplest explanation is perhaps an example of a solution that
wouldn't fulfill the requirement.

The reason I ask is that some users may find it useful to fill up the
name space with fake names, when adding NSECbis records.  The reason
for doing so would be to make it more difficult to find (arbitrarily
precise) zone size estimates.  All NSEC replacement proposals so far
are vulnerable to remote zone size estimates, and DNS without DNSSEC
is not.  See section 3 of http://www.links.org/dnssec/requirements.txt

Thanks,
Simon

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Sep 2004 14:26:26 -0400

>wouldn't fulfill the requirement.

The EXIST record of NSEC2.  Having to add hashes of names to the zone.

>is not.  See section 3 of http://www.links.org/dnssec/requirements.txt

Is defending against size estimates a goal/criteria?  I haven't seen 
that presented as a problem (other than to know how successful a 
brute-force guessing attack has been.)

With the criteria I've listed, I don't think it's possible to solve 
the puzzle.  I'm listing what I think are the desirable features of 
the puzzle solution.  In my mind, requirements are "absolutely must 
have" desirable features.  So, by starting with all the desire 
features, whittling them down, we get to the requirements.  Then, we 
can design and evaluate solutions.

I want to add - not all proposals involving hashes "muddy up the name 
space."  It's when the hashes are to be added to the zone that I get 
queasy.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 02 Sep 2004 20:52:30 +0200

> The EXIST record of NSEC2.  Having to add hashes of names to the zone.

Why is that a problem?  Is it something more than the increase in the
number of owner names in the zone?

> brute-force guessing attack has been.)

I don't know, but I wanted to be bring it up for discussion.  Similar
to zone enumeration, zone size estimate is a vulnerability that didn't
exist with vanilla DNS, which DNSSEC (even with NSECbis) would
introduce.

I know I'm going to make use of this property to collect statistics
about zones.  Perhaps some operators doesn't like that idea.

Note the subtle wording of my requirement.  The requirement isn't that
NSECbis should protect against zone size estimate attacks.  The
requirement is that NSECbis should not exclude implementations to
protect against the attack by, e.g., inserting fake names when
generating NSECbis records.

> space."  It's when the hashes are to be added to the zone that I get

I think you lost me here.  Could you give an example of a NSECbis
proposal that _doesn't_ add hashes to the zone?  I thought they all
did that.

Thanks,
Simon

---

From: Ted Hardie <[email-masked]>
Date: Thu, 2 Sep 2004 12:16:14 -0700

This is an engineering trade-off, and I believe it is an appropriate one.
The risk (zone enumeration) introduces a new mechanism by which data
stored in the DNS is made available (discovery vs. lookup), but all
of the data so exposed is already a public part of the zone.  Even with
the introduction of IRIS (the CRISP protocol) there is no doubt that
the introduction of the new mechanism does create operational concerns
for some deployments, but dropping it without a replacement loses
authenticated denial, which is a far more fundamental part of the
system.  Any new mechanism introduced to achieve authenticated
denial without zone enumeration will have its own trade-offs,
which are unknown at this time.  An optimist can assume they
will be better; a pessimist notes that they must be worst on
time of initial deployment and may be worse in other ways.

I would support the creation of a working group item for development
of DNS-with-ACLs, to be applicable to DNS or DNSSEC zones; I think
that would refocus the problem in ways that make the trade offs more
clear.  The WG may, of course, decide the result is not DNS, but some 
other service,
and that service can go forward on the merits of that need.  In the mean
time, though, we need to move forward with the current system, which meets all
the requirements it was originally intended to meet.

				regards,
					Ted

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Sep 2004 15:17:51 -0400

>number of owner names in the zone?

One of the things I look out for is any definition of the protocol 
that "determines the shape of the tree."  I.e., DNS specifications 
don't describe what zones are in existence (com.).  The SRV record 
does add prefixes to names (_tcp.<hostname>), I'm wary of that still. 
(The SRV is also "just" a Proposed Standard.)

Why worry about this?  I've stated a general bias, so the reasons 
vary by proposal.  Specifying that certain zones exist, or that 
labels are reserved tread into non-engineering matters.  Using 
prefix's on names causes some heartburn with wild cards - i.e., those 
who use * MX are tempted to then assume they can add _marid._tcp.* 
records.

When it comes to hashed names - if you add hashes as extra labels in 
the zone, where do you stop?  (Note: I am stating this as an example 
concern.  Please don't try to pick this apart, it's out of context of 
a developed proposal.)

    Ex.    example.com         SOA
           a.example.com       A
           HASH(a).example.com NSEC2

Do you now have to also have HASH(HASH(a)).example.com too?  Or are 
you now saying that half the names in the zone are treated one way 
and the other another way.  What if HASH(a) equals a name that is 
supposed to be in the zone - how is that name special cased.

I mention this as an example.  The time to discuss this will be when 
we get to discussing a proposal that does this.  Let's not get into a 
thread on this until there are requirements laid out.

>generating NSECbis records.

I'd suggest a new mail thread on that.  I'm ambivalent on the topic, 
but a nice subject line would be good to draw in those who might have 
strong thoughts.  Please don't take my words to say that I think this 
is a non-issue for others, but it is a non-issue for me.

>proposal that _doesn't_ add hashes to the zone?  I thought they all

Well, we aren't at the stage of solutions now, but I know of some 
discussions about on-line signing that do not need hashes.  (If you 
find key management bearable, you can sign on-the-fly a negative 
answer using the query name in places.)

I think it's possible to use name hashes without putting the hashed 
names in the DNS.  But I'm waiting until I see requirements before 
pursuing the idea.