Subject: Re: dictionary attack on nameservers

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 1 Sep 2004 11:14:52 +0200

Dear Colleagues,

I returned from vacation and saw that this thread, and the related
"What I mumbled at the mike today" had developed during my absense. I
started reading it with the intention to make an abstract of the
discussion. The shear amount of side tracks and circles in arguments
make this virtually impossilbe. I counted 191 messages with a total of
15127 lines (including headers).

I want to close this thread by giving every participant the
opportunity to state their concluding argument in not more than 20
lines of text.

Please make an abstract of your own concluding arguments (some people
may have changed their opinions) please do not start discussing these
arguments again. If you can phrase your arguments as a set of
(measurable) requirements for further protocol development that would
be fab.

Note that we are trying to take the work on preventing zone
enumeration seriously and that we are trying to get the requirements
done. At least one of the messages burried in the thread was relevant to
that and didn't get any followup.

Also read:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html

I am trying to get something sensible out of this that will allow us to
go forward or, if needed, conclude, in a decent fashion.

-- Olaf 
   DNSEXT Co-Chair.

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

--
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: 02 Sep 2004 17:25:39 +0000

"Olaf M. Kolkman" <[email-masked]> writes:

> ...

 1: my observations are:
 2:
 3:     - non-registry (SLD, et al) zone administrators are already
 4:       hiding their sensitive DNS data, if any, behind split views
 5:
 6:     - registry (mostly TLD) zone administrators have a competitive
 7:       interest in name secrecy not shared by registrars/registrants
 8:
 9:     - load increases due to more difficult enumeration will be felt
10:       by enumeration victims and third parties, not just attackers
11:
12: my recommendations are:
13:
14:     + ensure that NSEC is capable of covering a single name, so that
15:       a zone can use precomputed positive signatures and on-the-fly
16:       negative signatures, and let motivated/interested zone
17:       administrators add name secrecy by provisioning extra hardware.
18:
19:     + consider other, more compact encodings for nonexistence-proof,
20:       which are easier to generate on-the-fly than single-name NSEC.
-- 
Paul Vixie

---

From: Ben Laurie <[email-masked]>
Date: Mon, 06 Sep 2004 10:35:22 +0100

>  7:       interest in name secrecy not shared by registrars/registrants

I don't believe "competitive" is a correct characterisitaion for all 
registries, though it may be for some, and I'm not sure I agree that 
registrants do not share this interest, either. Certainly registrants 
register domains in order that a particular audience can see those 
domains, but that does not mean that all registrants want their domains 
to be visible to absolutely everyone.

For example, I have just registered a domain in order to get email - if 
I want to receive email from you, then I'll tell you what it is. If I 
don't, I won't. Having it published doesn't help me achieve that.

> 20:       which are easier to generate on-the-fly than single-name NSEC.

Why are you only interested in on-the-fly proofs? If its to avoid 
(major) changes to the protocol, then there's at least one problem with 
this type of solution, which is that outsourced DNS servers would have 
to have a signing key capable of signing anything.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 6 Sep 2004 12:10:40 +0200

I would like to conclude this thread. Please send your (about) 20
lines closing argument and try to refrain from discussing other
persons summaries.

-- Olaf

---

From: Danny Mayer <[email-masked]>
Date: Mon, 06 Sep 2004 13:16:34 -0400

At 05:35 AM 9/6/2004, Ben Laurie wrote:

>domains, but that does not mean that all registrants want their domains to 
>be visible to absolutely everyone.

I'm curious. Why would they register a domain if they didn't want
everyone to know about it? After all registering a domain means publish,
make it public and provide a means to get there. There are other ways
to provide directions to a site without registering it.

>For example, I have just registered a domain in order to get email - if I 
>want to receive email from you, then I'll tell you what it is. If I don't, 
>I won't. Having it published doesn't help me achieve that.

So don't register the domain. You can always just provide an IP address.
Mail servers only use the domain name to find out where to deliver the
mail.

Danny

---

From: Alex Bligh <[email-masked]>
Date: Mon, 06 Sep 2004 18:44:02 +0100

--On 06 September 2004 13:16 -0400 Danny Mayer <[email-masked]> wrote:

> everyone to know about it?

I have to agree with Olaf's comment that this discussion is becoming
circular - this in particular has been covered at great length (from both
directions) before. Whilst I'm always happy to discuss Nominet's policies
etc. Olaf has made the point this is not / no longer the place to discuss
the rationale behind it. Can I suggest we either take this off-list, or go
dig up things from the archive, and provide closing statements/arguments as
requested?

Alex

---

From: Alex Bligh <[email-masked]>
Date: Tue, 07 Sep 2004 14:42:03 +0100

> opportunity to state their concluding argument in not more than 20

[ This is a response from me personally and not from Nominet/Geoff/Ben;
  apologies for it being 21 lines ]

=====

Defense against Zone Enumeration is desirable for reasons including:

1. Principle of least surprise - Current DNS implementations allow it

2. Many users require it, e.g: certain registries who for honestly held 
policy reasons (expounded at length, but outside IETF's remit to debate); 
enterprise uses where split DNS is not feasible (e.g. web services).

3. For both, there is a qualitative difference between publishing a node & 
associated RRs, and publishing an index of all nodes. For the former, and 
possibly the latter, discovery of a significant number of RR's is less 
undesirable than discovery of a complete or near complete zone.

4. Those registries that publish data normally do so under specific Ts&Cs, 
and would chose mechanisms more efficient than DNSSEC enumeration.

5. The argument that the data is freely available "anyway", through 
(for-instance) dictionary attacks, web-server logs etc. has not been 
supported by empirical evidence; what empirical evidence has been put 
forward suggests that not all zones are significantly susceptible to 
dictionary attack, and those that are, are far from wholly susceptible.

I recommend that there should be an optional server side alternative 
mechanism for authenticated denial that does not expose an index to the 
zone contents, but retains protection against replay attack, and without 
online signing of denials (impractical, computationally expensive, DoS 
vector). This should be based upon NSEC, and making as few changes as 
possible.

=====

Alex

---

From: Ben Laurie <[email-masked]>
Date: Thu, 09 Sep 2004 16:03:30 +0100

> opportunity to state their concluding argument in not more than 20

The central idea is that people should not be worse off by deploying 
DNSSEC than they are by deploying DNS, So, zone file enumeration should 
be no easier in DNSSEC than it is in DNS.

That said, DNSSEC introduces other considerations, in particular the 
potential exposure of private keys, so a solution should not require 
private keys to be kept online.

And then there are "ordinary" DNS requirements: the solution should be 
compact and minimise change to existing protocols. If it introduces 
extra processing, storage or bandwidth requirements, it should also be 
optional.

Cheers,

Ben.

---

From: Peter Koch <[email-masked]>
Date: Thu, 09 Sep 2004 19:50:35 +0200

> opportunity to state their concluding argument in not more than 20

Zone file enumeration is a deployment obstacle for DNSSEC and it should be
made no easier than it is without DNSSEC. I'd also like to steal from
Ed Lewis' excellent set of items to avoid (sorted kind of top down):

	o Exposition of any existing names (regardless of data owned)
	o Breaking namespace invariants ("muddying up the name space")
	  or namespace consistency
	o Opening attacks against positive answers or against authenticated
	  denial of RRSet existence
	o Exposition of more than a very limited number of not existing names
	o Protocol incompatibilities other than TCR
	o Enforcing major operational efforts by those satisfied with NSEC
	o Enabling replay attacks for authenticated denial

As long as complexity allows, zone enumeration avoidance may be optional
since not only the structured {IN-ADDR,IP6,E164}.ARPA zones but also the
majority of zones containing no more than @, "www" and maybe "mail" won't
probably need it.  Defining a set of reasonable prerequisites (e.g. "no
wildcards", "delegation only", etc) is acceptable.

-Peter