Subject: What I mumbled at the mike today...

From: [email-masked]
Date: Tue, 3 Aug 2004 00:08:09 -0700

...may not have been terribly clear.  Here's an attempt to put it in a 
more coherent form:

Roughly speaking, a dictionary attack on a zone costs an attacker the 
same regardless of the size of the zone -- one query per dictionary 
word.  The cost is a function of the dictionary size, and is 
independent of the number of entries in the zone under attack.

On the other hand, the payoff (number of domain names discovered) is a
function of the zone size, as well as the dictionary size.

Hence, dictionary attacks on large zones are intrinsically more
efficient than attacks on small zones.

That is, dictionary attacks on small zones are less efficient, and
therefore, attackers who value their time won't waste their it in
mass attacks on small zones.  We can expect that would change, if there
were a convenient and efficient way of getting the contents of
small zones.

It would be interesting to know how many managers of small zones see
value in obscuring the contents of their zones.  As an exercise I tried
doing zone transfers from the domains in some of the email addresses on
this list, but I gave up after a dozen or so -- not a single one
allowed axfrs.  :-)

Regards
Kent

-- 
[email-masked]    p: +1 310 823 9358  f: +1 310 823 8649
[email-masked] SIP: [email-masked]

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

> efficient than attacks on small zones.

That is probably true comparing small to medium zones (I'd never thought of
it that way), but I suggest it becomes false at some zone size in the case
of TLD (open registration type zones) esp. when the size of zone far
exceeds the size of the dictionary. This is because those registering are
likely to register words in the dictionary first, and thus subsequent
registrations have decreasing probability of dictionary discoverability (or
rather increased cost of discoverability).

To put it another way, I would expect a dictionary attack of given CPU
power to reveal a greater percentage of a randomly selected 1000 names from
.org as against .com (approximately 10 times larger).

So while discovering "some" names from a larger zone is going to be easy,
discovering a substantial large percentage of that zone I would suggest
becomes harder at a rate more than linearly related to the size of the
zone.

There's no mathematically argument here - it's about what is likely
to be in zone files. And I have no stats (right now) to prove the point
(just as those who claim zones are already in effect enumerable now
don't have stats).

Alex

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Aug 2004 02:09:30 +0000

> >what's the payback from learning the names of internal dns-named resources?
> 
> speaking from the point of view of one trying to break in, it
> establishes a priori targets before entry is gained.  simply put,
> names that don't need to be exposed should not be exposed.

the people who agree with you and are serious about such, are already
using split-view dns.  outsiders don't see things that they shouldn't
see.

therefore, the people who are serious about attacking are using nmap,
not axfr, to locate vulnerable systems.

can we please not complicate a design having global implementation costs
when the maximum payback for doing so won't have any effect on the trivial
attacks?

> the simple defense against this is to run with a much smaller piece of
> the zone in question visible from the internet.  this used to incur
> running two name servers on a given machine, but the views that bind9
> offers make it easy easier to run one instance for two...well...views
> of the same zone.
> 
> of course, views don't solve everything...  :)

they're a better solution than NSECxx for the needs now under discussion.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Aug 2004 10:49:54 -0700

> using split-view dns.  outsiders don't see things that they shouldn't

Split DNS has absolutely no viability in a Web Services extranet
application.

None

Nada

Zip

Zero

The UDDI services used to advertise an connect the services is protected
using SSL and access control.

If it is not possible to store names securely in DNS then either that 
function will have to be served in UDDI or we will have to develop
a suitable DNS security fix in another forum.

The ratio of useful discussion on technical issues to trying to talk 
down real world requirements in this list is very very low. I would
estimate about 1:20 or less.

If a significant constituency declares that an issue is a showstopper 
then further discussion of the issue is pointless. There is no argument
that the European registries are not a significant constituency.

The DNS is nowhere near so pretty that it needs preservation as a 
national treasure.

---

From: "Loomis, Rip" <[email-masked]>
Date: Mon, 9 Aug 2004 14:49:42 -0400

> > the people who agree with you and are serious about such, 
> > are already using split-view dns.  outsiders don't see things
> > that they shouldn't see.
> 

I think that you're still saying that zone enumeration is a
security issue and not a privacy issue.  Am I correct?

If you think that by not having a world-accessible DNS entry for a
network-connected system you significantly improve its security
posture, then I strongly disagree.  I've done penetration testing
for many years and I also monitor IDS devices.  The simple facts
today are that
  - If a system is connected to a network and it is vulnerable,
    then it will eventually be attacked.
  - The systems that are most likely to be attacked manually may
    be those most easily found in (DNS, Google, etc.) but the
    vast majority of attacks (both those being stopped and those
    successful) are automated.
  - If you have a system that is significantly appealing for
    someone to find it and target it specifically (for example
    by its name found in an enumerated zone file) then that
    system needs a very good set of safeguards and perhaps a
    name less appealing to attackers.

DNS data is only one of the inputs to the target selection
process for network-based attacks and it's a minor one.  I
don't expect that zone enumeration is going to suddenly
change that, based on personal experience.

I'm not saying that I want every outsider to have a perfect map
of the internals of an enterprise network--but spending a lot of
time preventing zone enumeration will also not keep bad guys from
mapping networks or provide a useful improvement in security
posture.  For my part, though, I do believe (as I have for
several years) that there are reasons why we should make a more
conscious choice about the trade-offs with allowing/preventing
zone enumeration (and I won't be sorry if we can eliminate it.)

I think that perhaps your statements about DNS in the context of
a "Web Services extranet application" need a little more explanation.
You say there's "no viability" but provide no hard data.

> then further discussion of the issue is pointless. 
Strongly disagree.  Declaring something as fact does not make
it fact.  Providing a real list of requirements each with a
basis would be more reasonable than saying "can't live with/without
it".  I'm one of the folks tasked to collect the requirements and
bases and I believe that there are "significant constituencies"
who have desirements that they would like to make requirements.

If there are conflicting requirements, though, then we will all
have a choice.  It sure would help if we made sure that we
all understood the real basis for each requirement--and when
different TLDs look at the same privacy laws and have interpretations
that are 179 degrees out of phase it makes things interesting.
That's assuming that we're looking at zone enumeration as a
privacy issue (which I think it is) and not a security issue
(which to me it is not.)

> The DNS is nowhere near so pretty that it needs preservation as a 

Agreed.  Simultaneously, the DNS is already ugly enough that
continuing to add features and capabilities without considering
all the impacts may be hazardous.

  --Rip (still looking for more inputs on the requirements
    related to zone enumeration, NSEC, and DNSSEC in general, BTW)

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Aug 2004 12:01:43 -0700

> Okay, so don't use it there.  Split DNS, by definition, would be
> considered tangential to an extranet.  ie, the extranet is on 
> one side of
> the split and doesn't know about the other.  If your extranet 
> needs a peek
> inside, I suggest evaluating a VPN or alternate solution.

Without meaning disrespect here, I don't think you appreciate
the scale of this issue. We are not talking about trivial numbers of
participants here. 

Think infrastructure to support merchants using RFID applications.

We are talking about very large, deperimeterized networks here.
And no, deperimeterization does not mean throwing away your 
firewall as many in the IETF seem to think, an idea considered 
so kooky in the real security world that it took me several 
minutes to convince some of the folk in the deperimeterization
movement that there are serious advocates.

I can't have a VPN that includes every manufacturer in north 
america. IPSEC is still not up to the task - in part because 
DNSSEC is not there.

If you make DNSSEC dependent on IPSEC for deployment then you
have just created a dependency cycle.

Ben knows what he is doing here. From a security point of view
the requirement is absolutely sound. 

> ...unrelated...?

No, the point is that the directory mechanism does not leak DNS names.

> define "store names securely" -- the machine can be secured, the split
> horizons (or views) can be secure.  

It is possible to publish a name in DNS without alerting an attacker 
to the existence of the node.

> the network can be secure.  what part
> of secure do you really want?  The ability for it to not be 
> enumerated?  I thought this discussion was over.

So did I, but folk seem to keep re-opening it and trying to kill the
requirement.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Aug 2004 12:10:38 -0700

> security issue and not a privacy issue.  Am I correct?

Yes

> for many years and I also monitor IDS devices.  The simple facts

How many Web Services devices have you managed?

> change that, based on personal experience.

If your model of the Internet is limited to today's applications.

> posture. 

the effort required to fix this issue is a trivial fraction of 
the effort trying to argue that it does not exist.

> it fact.

It is a fact that DNSSEC affects the visibility of data in the DNS
in ways that have significant security consequences.

The subjective issues are in the evaluation of those security 
consequences.

> all the impacts may be hazardous.

So why not do the job properly this time round instead of arguing
to do yet another half baked job?

>     related to zone enumeration, NSEC, and DNSSEC in general, BTW)

Fix wildcards so that mid point wildcards work.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 09 Aug 2004 20:20:23 +0100

--On 09 August 2004 12:01 -0700 "Hallam-Baker, Phillip" 
<[email-masked]> wrote:

> DNSSEC is not there

Equally the suggestion to introduce a VPN when the underlying data is
already SSL encrypted, merely to prevent the leak of information from DNS
seems a bit bizarre.

AIUI (going back to Rip's request to collect inputs for the requirements),
your concern, Phillip, is that enumeration does not leak (potential) names.
You are thus presumably not concerned (here) about wire-tap /
man-in-the-middle type attacks where queries (and answers) get recorded
by third parties - IE it is not a requirement in your book to (for
instance) encrypt the query and/or response?

Alex

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Aug 2004 15:48:21 -0400

>     related to zone enumeration, NSEC, and DNSSEC in general, BTW)

I'm at the same train station.  But I'll settle for reqt's on zone 
enumeration and NSEC. ;)

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

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

---

From: "Loomis, Rip" <[email-masked]>
Date: Mon, 9 Aug 2004 15:44:33 -0400

Dr. Hallam-Baker--

> How many Web Services devices have you managed?
Apparently not enough to participate in a discussion
of DNS Security in an IETF context.  Funny, I didn't
see that on the "required qualification" list.

> If your model of the Internet is limited to today's applications.

My model of the future foundation of the Internet is unfortunately
limited to incremental improvements (to the existing foundation)
ideally while not screwing things up.  I'm still not clear
how XML-based "web services" are such a fundamental change to
the way Things Get Done that current security principles and
practices no longer apply.

> the effort trying to argue that it does not exist.

The effort required to fix this issue correctly once-and-for-all
is a non-trivial fraction of the available resources and may
cause further delays in widespread DNSSEC usage without producing
a significant benefity to many users.  With all due respect, I
believe you're still handwaving.  I share your impatience with
some IETF processes, but they are the constraints within which
we're working.

> The subjective issues are in the evaluation of those security 

It is a fact that DNSSECbis (through NSEC) affects the visibility
of data in the DNS in ways that have been well-known and well-
documented since RFC 2065 gave us the NXT RR in 1997.  I wasn't
happy about it then, but I decided I could live with it as
did many others--based on a realistic evaluation of the risks
involved.

The subjective issues are in the evaluation of the potential
consequences (security, privacy, or otherwise) of the effects,
resulting security risks (if any), and in the decision as to
what to do now.  I *still* don't understand why this discussion
got into security issues, and I need to understand things in
order that the requirements document is complete and comprehensible
(unless Ben can give me a Vulcan mind-meld or something, assuming
he does understand the issues to your satisfaction.)

> Fix wildcards so that mid point wildcards work.

Wow--I agree that mid-point wildcards would be very useful in
some contexts but I see them as very painful and/or a Bad Idea
in others.  I'm afraid that may also be beyond the immediate
scope of requirements that Ben and I were asked to compile,
but I do think it needs to be discussed at least once more--
and very soon since it needs to be taken into account as part
of the DNSSEC-what-now discussions.

Okay, who's doing wildcard requirements?

  --Rip

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Aug 2004 13:28:23 -0700

> see that on the "required qualification" list.

It would seem to be a useful qualification if you are going to 
argue the security requirements thereof.

> practices no longer apply.

Actually what I am saying here is that the security principles
considered in the Internet security field DO apply. What I reject
are the superstitious nonsense and pseudo-security doctrines that
pass for security arguments here.

> a significant benefity to many users. 

It will cause no delays whatsoever. You are so far from being 
deployed in the real world that it is just not funny. 

> in others. 

Wildcards ARE a really bad idea. But they are also used. And since
SRV appeared there are significant problems with the way they are
used.

Having been subjected to endless arguments about why wildcards make\
it impossible to use prefixes in the context of SPF I think we should
fix 'em.

I can draw up some requirements next week.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 9 Aug 2004 13:35:59 -0700

> instance) encrypt the query and/or response?

Actually I do have real concerns here, but confidentiality is not
something that can be addressed in an end to end protocol in the
context of DNS while authenticity is.

Encrypting DNS is something like issue number 37 on my list of
urgent fixes to Internet security protocols. It will not be 
relevant until a whole host of other stuff is fixed first and 
there will be no viable way to address it until there is 
DNS authentication security.

Basically my approach would be to perform point to point 
encryption using session keys generated through an ephemeral 
key exchange.

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Tue, 10 Aug 2004 13:50:41 +0200

> what's the payback from learning the names of internal dns-named 
resources?

The attack described in Bellovin's Paper 
http://www.research.att.com/~smb/papers/dnshack.ps starts by assuming that 
the names of the target machines are known to the attacker.

Best,
Marcos Sanz