Subject: NXT design choices

From: Edward Lewis <[email-masked]>
Date: Tue, 3 Aug 2004 10:40:18 -0700

(If I've missed "choices" let me know - I'll update this with any new 
material.)

In an effort to move the discussion away from the reasons why zone 
enumeration is a problem and the reasons why zone enumeration is not 
a problem, I'd like to review the design decisions behind the 
original NXT record.

To provide authenticated denial, the first choice made is whether to:

1) Sign a tailored response to the query you are saying No to
2) Pre-compute all of the responses you will give out

Choice 1 was ditched because this meant that we needed on-line keys. 
In the early days of DNSSEC (DNSSEC WG) the emphasis was more 
security minded than operations minded, the thought of on-line keys 
was abhorrent.

(It seems like this may be coming back in vogue.  But the concerns I 
have are the transfer of the secret material between servers and the 
role of encrypting it.  Back in the first DNSSEC implementations, 
crypto export controls and patents combined to discourage encryption. 
This is one reason why BIND's dnssec-keygen leaves the private key 
file in plaintext.  I'm not up to date on crypto-business, so maybe 
the old concerns are out moded.)

Choice 2 breaks down into:

2a) Send one message to deny data in the zone
2b) Send fine-grained messages

Choice 2a is basically what we have pre-DNSSEC - sending the SOA (now 
an option).  This was ditched because of the threat of replay 
attacks.  Someone could replay the one negative answer to all queries 
against the zone and make it "disappear."  This replay vulnerability 
(because DNS does not do time) is the killer here.  But, zone 
enumeration and sorting is not a problem.

(Choice 2a won't fly with the DS record either.)

Choice 2b requires that the sender reveal to the client what exists 
at the sender so that the client can deduce it's a negative answer. 
There are two ways to do this

2b1) Reveal what exists in plaintext
2b2) Reveal what exists in a one-way mapping (hash of names)

Both choices assume that the server orders the relevant data in the 
same way the client would - allowing the client to say "if there's an 
A followed by a C, and I want B, B doesn't exist because it would be 
between A and C."

Choice 2b1 has the cost of 1) requiring that the server store all 
names in a canonical order and it makes getting the names in the zone 
easy (zone enumeration).  This choice also has impacts on largely 
delegated zones with sparse secured delegations (like .com).

Choice 2b2 has the cost of creating a new name space (the mapped-onto 
names), as well as having the same burden on zones like .com.

Choice 2b2 has been discarded because the community was happy with 
the costs of choice 2b1 - not because choice 2b1 was optimal.

Choice 2b1 has some variants.  One is what NSEC does now, that is 
reveal the span between all names.  The "white lies" proposal is a 
variant, in which the span is segmented to make it seem like there 
are more names in the zone, combining this with barriers to asking 
for NSEC's directly.

I personally don't think it's a matter of how important or why zone 
enumeration is a problem/distasteful.  Zone enumeration is not and 
has never been a desired feature of DNSSEC.  It was ignorable by the 
original designers, so it persists.  Looking back - a big cost is the 
sorting of the data in the authoritative server.  "We've" "paid" that 
by developing BIND 9.  (Is BIND 9's perceived slowness a result of 
storing data in sorted order?)

Defending NSEC as it is now is not defending an optimal solution. 
2b1 is the least offensive solution, or it was at one time.

Today we have Choice 2b1.  If we want to avoid zone enumeration, 
we'll have to give something else up, what will that be?  On-line 
keys?  Replay defense?  Muddled name space?  Even if we combine 2b1 
with on-line keys - we need to break an old assumption (no keys 
on-line).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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

--
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: Paul Vixie <[email-masked]>
Date: Tue, 03 Aug 2004 19:16:45 +0000

> (Is BIND 9's perceived slowness a result of storing data in sorted order?)

somewhat.  it makes loading slower.  once loaded, the queries-per-second
limitation is caused by things other than security ordering.

---

From: "Loomis, Rip" <[email-masked]>
Date: Tue, 3 Aug 2004 16:42:30 -0400

Halloo Ed--

> security minded than operations minded, the thought of on-line keys 

Choice one was ditched for more reasons, because not only were
on-line keys needed but the signing of a tailored response needed
to be done in real time.  It may be less significant an issue now,
but at the time the extra CPU cycles spent for "real time" crypto
as compared to "pre-computed" crypto were a major concern.

> (It seems like this 
on line storage of keys? (since your "this" isn't a clear reference)

> may be coming back in vogue.  But the concerns I 

There are a much longer list of issues and concerns that need to
be expressed somewhere, some of which are unrelated to the NXT/NSEC
design choices (but I'm throwing 'em in anyway):

 - For zones that want to allow dynamic update of a signed zone,
   at least the master (or stealth master) server must have a
   zone-signing key available.  With several common usages of
   SRV records and/or DHCP, I see dynamic updates of signed zones
   to be extraordinarily likely.

 - For methods of authenticated denial that involve "real time"
   crypto, *all* authoritative servers must each have at least
   one zone-signing key available.  That makes life much harder
   to deal with securely than the dynamic update case above.

 - Hardware crypto devices may be able to provide both acceptable
   secure storage and speed (CPU) improvements to allow realistic
   signing of both zone data and authenticated denial responses
   in real time.

 - From my viewpoint, the organizations which are most concerned
   about zone-enumeration-through-NSEC are also those best able
   to afford a hardware crypto device to assist with things.

 - The fact that a hardware crypto device might be useful (and
   that a DNSSEC-TNG designed around them might be far superior
   to the current design) does not mean either that further delays
   in fielding DNSSECbis are acceptable, or that the current
   DNSSECbis design is broken.
 
[...]
> the costs of choice 2b1 - not because choice 2b1 was optimal.

Well, I would describe it as "the community accepted the costs of..."
since I don't think happy was the best adjective to describe things.

[...]
> original designers, so it persists.  

I agree with your statement above about zone enumeration. At the same
time, I agree with Paul and others who point out that obscurity of
DNS data has never been a designed-in feature of DNS (although it
may have been and may remain a desired feature.)

[...]
> with on-line keys - we need to break an old assumption (no keys 

I think that there are solutions that address perceived issues with
zone enumeration without requiring on-line keys.  If we can find
a method that meets "enough" of the requirements and desirements,
then I believe it's probably worth doing--but if it requires on-line
keys on all the authoritative servers for a zone for real-time
crypto then I believe it doesn't meet at least one of *my*
requirements.  I guess I'd better get with my esteemed co-editor
and get that added to the initial requirement/desirement list.

  --Rip