Subject: RE: whois and zone enumeration

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Aug 2004 09:45:08 -0700

I stand by my original statements.

Paul is repeating a dogma he does not understand to make an argument that is
false.

the nsa requested this particular feature five years ago. It made sense then
it does now.

The split dns model is not sufficient for serious security needs. My clients
are concerned about internal threats as well as external. In the age of
mydoom the split dns solution is a weak one. In the age of web services and
deperimeterization it is nonsense.

 -----Original Message-----
From: 	Danny Mayer [mailto:[email-masked]]
Sent:	Tue Aug 03 06:53:43 2004
To:	Hallam-Baker, Phillip; [email-masked]
Subject:	RE: whois and zone enumeration 

At 10:53 PM 8/2/2004, Hallam-Baker, Phillip wrote:

> > what we have here is a divergence of vision.  security is not
> > obscurity, and obscurity is not an intended feature of either
> > "dns classic" or any extension ever made to dns.
>
>As a security professional who is engaged as such I can assure
>you that it is a very bad idea to remove security controls
>from an existing system unless you understand their effect.

I agree with Paul. He is not advocating the removal of anything. He's
saying that depending on obscurity for security is no security at all.

>The fact that a control is unintended or is rejected on
>ideological grounds does not mean that it can be dispensed
>with. I am currently dealling with the consequences of
>an industry abandoning certain controls that were present
>in the ATM systems but are not present on the Internet.
>As a result I spend a great deal of time talking to
>law enforcement.

You misread his statement.

>Removing imperfect security controls without replacing them
>is one of the main ways that security protocols fail in
>practice.

Where did he advocate removing imperfect security controls?

>The common sense ideas that preceded the dogmas are still
>generally accepted. But you are advancing a dogmatic interpretation
>that is rejected by the field. It certainly has no place in a
>security design argument.

He's not advancing any dogma. He wants to advance real security.
Preventing zone enumeration through DNSSEC records should not
give the illusion that thereby you are preventing zone enumeration,
just making it more difficult. If the goal is to make it more difficult,
then that should be stated up front.

Danny

--
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: 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.

---

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: Alex Bligh <[email-masked]>
Date: Tue, 03 Aug 2004 21:03:20 +0100

--On 03 August 2004 10:40 -0700 Edward Lewis <[email-masked]> wrote:

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

I agree

> 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?)

Interesting: Given Ben has done some work (no idea how far he has got) on
proof-of-concept NSEC2 in Bind, do we have real-world code that would tell
us what the cost 2b2 over 2b1 is? (albeit non-optimized, and on one
platform)?

Alex

---

From: Ben Laurie <[email-masked]>
Date: Wed, 04 Aug 2004 03:12:15 +0100

Alex Bligh wrote:
> Interesting: Given Ben has done some work (no idea how far he has got)

"about half-way" - I can generate and sign the zone. I do not currently 
have a working resolver or responder.

> on