Subject: Re: dictionary attack on nameservers

From: Roy Badami <[email-masked]>
Date: Tue, 7 Sep 2004 22:57:30 +0100

I hadn't been intending to respond to the chairs' call for 20-line
summaries, since I regard myself as an intersted bystander rather than
an active WG member...  However Olaf contacted me privately requesting
I do so, so here goes...

--------

I regard it as highly desirably to reach some sort of consensus that
includes those ccTLDs that have concerns about enumeration, and
realistically I think that means addressing their requirements, rather
than convincing them to change their requirements.  I'm pleased that
the co-chairs seem to concur that this is worth persuing...

I don't have any strong feelings as to the shape that the technical
solution should take though I note that Bloom filters have been
completely neglected in recent discussions, and I think they may still
be of possible value -- see for example Steve Bellovin's ID
http://www.research.att.com/~smb/papers/draft-bellovin-dnsext-bloomfilt-00.txt

I would argue that authenticated denial is important in a TLD, and
that provably-insecure delegations are vital, as without them the
level of security offered to customers of that TLD is diminished.

I note also that if some TLDs choose not to offer these security
guarantees, then there will be no incentive for their customers to
migrate away from transitional mechanisms such as Paul Vixie's DLV
(which does offer those guarantees, at least to participating resolvers).

       -roy

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 8 Sep 2004 10:20:59 +0200

On Tue, 7 Sep 2004 22:57:30 +0100
Roy Badami <[email-masked]> wrote:
> However Olaf contacted me privately requesting

For the record this was my request:
 
 Hello,

 I am sending this message to a few people that where had an
 outspoken meaning in this discussion. With reference to 
 http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01600.html
 would you mind giving a 20 lines conclusion of your arguments?

 Thanks,

 -- Olaf

---

From: Miek Gieben <[email-masked]>
Date: Wed, 8 Sep 2004 11:55:46 +0200

Hello,

I could only manage to write 17 lines :-) But here is goes:

First of all, any solution to be found for the "problem" of enumeration is
a solution that will only work for 50% (as there are other ways of getting
the data). If think a protocol change is a big sacrifice for a non optimal
solution.

Secondly only a few TLD's have expressed their concern about this, which is,
IMO, again another reason not to fiddle with the protocol.

That said, I also take the view that enumeration in DNSSEC should not be made
easier than it is today. 

The requirements from Ed [1] are a good starting point. But as Ed said
- you will never have a solution that will satisfy all these
contraints.

[1]
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01610.html

grtz Miek

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 08 Sep 2004 12:10:25 +0200

Okay, here's my 20 lines.

--start line count--
I think Lewis summed it up pretty well, and I don't see any way to 
satisfy all these constraints either, it would be great if someone else 
would. One of the biggest problems I have with all this is that DNS(SEC) 
is complicated enough as it is, and we should be really really really 
sure that it is a problem (...of DNS (...on the protocol level)), before 
we start adding yet more complexity to it all (which is a security risk 
itself).

For those who have problems with enumeration, online signing shall 
probably not be a solution either, but muddying up the namespace will 
not make administrating zones any easier. Insofar i have read the 
proposals I have serious doubts if they solve the enumeration problem, 
but that can probably be fixed, and I haven't given them much attention 
(see above).

The 5 requirements mentioned by Lewis should be at least present in the 
requirements documentation, be it as hard requirements or strong 
considerations, as the trade-off for any solution should be well considered.
-- line 20 --

Jelte