Subject: Re: dictionary attack on nameservers

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Aug 2004 15:09:06 +0200

On Fri, Jul 30, 2004 at 07:19:25AM +0200,
 Olaf M. Kolkman <[email-masked]> wrote 
 a message of 40 lines which said:

> This working group will need to get the requirements for making informed 
> decisions on how to design NSEC++.  Remember that Rip and Ben have 
> volunteered to put such a list together. Please send your requirements 
> to these to friendly volunteers.  If you have a threat model in mind, 
> please document and send to Ben &  Rip.

Well, I regret it has to be specified but I add a requirment, the
"Nightingale requirment":

At the very least, DNSsec should not lower security and should not
make existing attacks (e.g. zone enumeration) easier.

--
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: [email-masked]
Date: Tue, 3 Aug 2004 14:02:30 +0000

> Stephane Bortzmeyer <[email-masked]> wrote

	Here we enter semantic entanglements.  You assert
	that zone enumeration is an attack on the DNS.

	I don't see it that way.  Zone enumeration is 
	simply a series of legitimate DNS queries.  This is
	not a protocol problem.  At some layer -above- the DNS
	some entity or entities wants to use data collected 
	by/through legitimate DNS protocol transactions in a 
	manner that is offensive to the authorized manager of
	a particular delegation.  

	At least two problems here:

	) this is not a DNS issue, per se
	) it is not likely that a single "policy" wrt keeping 
	  data "private" will work. if this maddness continues,
	  i expect that we will end up describing a policy grammer
	  and language in addition to methods for enforcing same.

but as usual, YMMV.
-- bill

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 Aug 2004 16:11:21 +0200

On Tue, Aug 03, 2004 at 02:02:30PM +0000,
 [email-masked] <[email-masked]> wrote 
 a message of 32 lines which said:

> 	) it is not likely that a single "policy" wrt keeping data
> 	"private" will work.

Yes, it will. At the present time, a ccTLD which does not care about
the access to its zone file allows AXFR or posts the zone file on a
Web site or anonymous FTP server. A ccTLD which does care disallows
AXFR. The ccTLD manager has a choice. The protocol (and
implementations: I remember a time where BIND did not allow to disable
AXFR) does not dictate a policy.

With DNSsec 1, the protocol dictates the policy: you can no longer
make zone enumeration difficult, should you wish so.

>         if this maddness continues, i expect that we will end up
> describing a policy grammer and language in addition to methods for
> enforcing same.

It already exists :-) Caller-ID (rejected by the MARID WG but the
current SPF-like language is quite complicated also). Or SAML
(http://xml.coverpages.org/saml.html).

---

From: [email-masked]
Date: Tue, 3 Aug 2004 14:24:57 +0000

> (http://xml.coverpages.org/saml.html).

	those are -not- part of the DNS specification, nor
	have they been presented as such.  I fear that the 
	end game, IF this is determined to be a DNS protocol
	issue, will be extensions tothe protocol to support
	a robust policy language and access controls....
	which will have the effect of fracturing the namespace.

	and we will end up - yet again - in the space where local
	optimizations irrepairably damage the global utility of
	the system.  

--bill

---

From: Alex Bligh <[email-masked]>
Date: Tue, 03 Aug 2004 15:36:51 +0100

--On 03 August 2004 14:02 +0000 [email-masked] wrote:

> 	simply a series of legitimate DNS queries.

I am taking it you are using the word "legitimate" to mean "in
conformance with the RFC" else you are rather begging the question.

Putting in purely technical terms, zone enumeration may be a series of
legitimate DNS queries, but it was not a possible series of legitimate DNS
queries prior to DNSSEC. Effectively, DNSSEC allows a database to be
searched by another key. For some DNS users, allowing searches by that key
is undesirable. I don't believe that a change in the protocol layer should
be the determinant of what keys can be used to query a database; that's a
policy decision. Therefore retaining having an option to restrict search
keys to the previous set seems a reasonable requirement upon a protocol
change.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Tue, 03 Aug 2004 15:41:14 +0100

> 	which will have the effect of fracturing the namespace.

Noone is asking for more any degree of functionality more than is
currently present in BIND et al. - I didn't notice that fracturing the
namespace. Noone is asking for policy language and access controls in
the protocol standard. They are merely asking for the protocol standard
not to be constructed in such a manner that access controls similar to
those in existing non-secure DNS applications are not impossible to
implement in DNSSEC applications.

What is more likely to fracture the namespace is if half the world
deploys DNSSEC and half doesn't, which is what we are all (?) trying
to avoid, I thought.

Alex

---

From: [email-masked]
Date: Tue, 3 Aug 2004 14:47:58 +0000

> conformance with the RFC" else you are rather begging the question.

	yes... this is a discussion about the DNS protocol

> queries prior to DNSSEC. 

	again, we dance on the head of a pin. does enumeration infer a
	100% complete and accurate listing of all the elements in a set?
	In my understanding, and based on previous threads, the answer
	is no.  So i would characterise your statement above as misleading
	or even false. If my presumptions are wrong, then you might be
	correct.

> Effectively, DNSSEC allows a database to be

	as may be.  and that is the discussion underway.  I remain 
	convinced that the results of these discussions will cause
	more harm to the DNS - as a useful system - than good.  

--bill

---

From: Alex Bligh <[email-masked]>
Date: Tue, 03 Aug 2004 16:17:08 +0100

--On 03 August 2004 14:47 +0000 [email-masked] wrote:

>> legitimate DNS queries, but it was not a possible series of legitimate
>> DNS queries prior to DNSSEC.
>

Sorry - I meant the PROTOCOL used to allow applications to prevent
enumeration USING ONLY PROTOCOL QUERIES, but DNSSEC as-is removes that
ability to prevent enumeration. I think that's uncontentious?

The argument as to whether a partial enumeration can be gained through
other mechanisms (google, nameserver logs, tendancies to list the similar
data in inaddr.arpa, whatever) and the difficulty thereof is a separate
question.

Alex

---

From: [email-masked]
Date: Tue, 3 Aug 2004 15:15:33 +0000

On Tue, Aug 03, 2004 at 03:41:14PM +0100, Alex Bligh wrote:
> namespace. 

	thats not quite how I see it, and -recognizing BIND is an 
	implementation of the DNS standard with its own, non-standard
	extentions- ....  its already started... :)

		VIEWs
		delegation-only

> Noone is asking for policy language and access controls in

	not yet.  they will -if- the DNS is asked to enforce
	policy.
> deploys DNSSEC and half doesn't, which is what we are all (?) trying

	don't think that the existance of a single tree with parts
	signed and parts not signed is a problem.  DNSSEC designers
	did consider that possibility. :)

	but...  this started out w/ my questioning the assertion
	that zone enumeration was an attack on the DNS.  Nothing
	I've seen so far has swayed me to belive that zone enumeration
	is an attack on the DNS.

	todate, the emphasis is on the attacks launched using data 
	collected through the DNS.  protecting the DNS is one thing.
	preventing people from using the DNS to gather intel is something
	else.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 03 Aug 2004 16:22:31 +0100

> 	not yet.  they will -if- the DNS is asked to enforce

Don't understand. Are you suggesting it's the same "they" in your sentence
as mine? If so, what makes you think those people (presumably including
Nominet) will want policy language and access controls in the standard?
If they need to be put anywhere, I'd suggest the application. I'm either
totally missing your point or this is just FUD.

Alex

---

From: [email-masked]
Date: Tue, 3 Aug 2004 20:57:21 +0000

i was asked to make some sort of comment wrt DLV in public and this
seems like as good an opening as any.  Like Paul, I am happy that DLV 
exists, is documented in some, albeit currently restrictive, forms.
His rational and mine are perhaps polar opposites.  I am all in favor 
of interesting and novel ideas being developed, documented, and perhaps
even being implemented as/in proof of concept ways.  The business case(s)
for deploying stop-gap techniques always seem compelling and are almost
always more costly in the long run. Actually putting a DLV registry 
into play requires someone to be convinced that the costs for doing so 
will be (nominally) recovered as a bare minimum.  Many/Most orgs tend
to have minimum ROI targets on investment. So while public benefit is
a fine platitude (and in some cases is much more than that), I think that
if we (as DNSSEC potential users) are pushed/prodded into depending on
DLV deployment, we are going to have a much longer transition cycle
with attendent cost/confusion/troubleshooting as the tradeoff for  "rapid"
start times for signed/validating zones.  as usual, YMMV.

--bill

On Tue, Aug 03, 2004 at 07:55:24PM +0000, Paul Vixie wrote:
> the longer this debate goes on, the happier i am that something like DLV
> exists.  domainholders want dns security and don't (for the most part)
> care about enumeration since they can use split-dns or just live safe
> with the knowledge that their zones are too numerous and too sparse to
> be worth a dictionary attack.  registry operators are very concerned
> about enumeration, for operational or business (or both) reasons.  without
> something like DLV, i'm convinced that the part of the world who would
> have the ability to deploy DNSSEC is far smaller than half of it.  with
> something like DLV, i'm convinced that the half of the world who implements
> DNSSEC will incentivise the other half to get with the programme, "somehow."