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: Tue, 03 Aug 2004 19:43:35 +0000

> becomes harder at a rate more than linearly related to the size of the

that's a fine suggestion but dataminers are way smarter than you're
giving them credit for.  they know how to craft dictionary attacks based
on actual name allocation patterns, and they know these patterns are
language specific, and they aren't just going to be looking for english
words, or native-language words, or combinations of words, or mutations
of words.  with respect, i'd be a lot more interested in reading about
attacks and measured success rates than theoretical predictions, and i'd
rather hear about this from others who have been involved in preventing
network abuse (datamining, spamming, phishing, etc) for a decade or longer.

in other words, trivializing the attackers in order to justify a trivial
(but expensive and universal) defense is not the way to win me over.

i am particularly struck by the fact that registrants are being held
hostage to the concerns of their registries and registrars.  domainholders
don't want their domainnames kept secret -- they are intended to be made
visible.  the problems of enumeration are felt by registries and registrars,
and the desire of registrants to use dnssec in their own zones are not
being given any weight in this debate.

small zones are not just hard to enumerate because there's less name-density;
they are also harder to enumerate because there are so many of them -- tens
of millions of times more of them -- than there are large zones.  and the
payback for an attacker is much lower.  (they can probably just guess "www".)

in other words, we're debating whether to add technology to defend against
a trivial attack that will only be launched against a small number of zones
(the large registry-based ones) but incurring implementation and deployment
costs (complexity, time, perhaps money), while the actual nontrivial attacks
continue to be "successful enough" to justify their continuation.

this is just crazy.

---

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

--On 03 August 2004 19:43 +0000 Paul Vixie <[email-masked]> wrote:

> visible.

This is just not true (based on what we hear from registrants). If you
run a domain for email only, you do NOT want everyone and their dog
to know how to send you email, because they will.

Alex

---

From: [email-masked]
Date: Tue, 3 Aug 2004 13:11:52 -0700

On Tue, Aug 03, 2004 at 07:43:35PM +0000, Paul Vixie wrote:
[...]
> being given any weight in this debate.

Realizing the weakness of the methodology, I did a bit more systematic
analysis of the domains in use on this list.  I pulled 143 domains from
my recent archive of the namedroppers list, and checked one nameserver
for each of the zones to see if axfr was allowed.  Of the 143
nameservers, 51 allow zone transfer, and 92 do not. 

That is, at least from this sample, your assertion is incorrect -- the
evidence suggests that the majority of clueful registrants prefer NOT
to make their full zones visible.

> payback for an attacker is much lower.  (they can probably just guess "www".)
But with easy enumeration, enumerating small zones becomes trivial, and
therefor mass enumeration of their millions of zones becomes quite
doable. 

> (the large registry-based ones)

The attack will not be only against large zones, it will also be
against small zones. 

-- 
Kent Crispin

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Aug 2004 16:23:59 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:
    Paul> in other words, we're debating whether to add technology to
    Paul> defend against a trivial attack that will only be launched
    Paul> against a small number of zones (the large registry-based
    Paul> ones) but incurring implementation and deployment costs
    Paul> (complexity, time, perhaps money), while the actual nontrivial
    Paul> attacks continue to be "successful enough" to justify their
    Paul> continuation.

    Paul> this is just crazy.

  What he said.
 
  (looking for WG session discussion summary)

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Jim Reid <[email-masked]>
Date: Tue, 03 Aug 2004 21:28:41 +0100

>>>>> "Alex" == Alex Bligh <[email-masked]> writes:

    Alex> This is just not true (based on what we hear from
    Alex> registrants). If you run a domain for email only, you do NOT
    Alex> want everyone and their dog to know how to send you email,
    Alex> because they will.

I don't understand this logic or the flawed user expectations behind
it. Everyone and his dog will soon find out how to send these people
email, with or without zone enumeration. Whether it's done by NSEC
walking or some other method.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 03 Aug 2004 20:29:48 +0000

> analysis of the domains in use on this list.  I pulled 143 domains
> from my recent archive of the namedroppers list, and checked one
> nameserver for each of the zones to see if axfr was allowed.  Of the
> 143 nameservers, 51 allow zone transfer, and 92 do not.
> 

i still do a fair bit of bind support and nameservice design consulting,
and i draw the opposite conclusion -- most people are knee-jerk about this
and have a "be as closed as possible" attitude, just as with inetd.conf,
but are not specifically concerned about zone data visibility.  the ones
who are concerned about zone data visibility -- who you call "clueful" --
are running split dns.

> But with easy enumeration, enumerating small zones becomes trivial,
> and therefor mass enumeration of their millions of zones becomes quite
> doable.

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

---

From: kent crispin <[email-masked]>
Date: Wed, 4 Aug 2004 14:48:53 -0700

[ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

On Tue, Aug 03, 2004 at 08:29:48PM +0000, Paul Vixie wrote:
> but are not specifically concerned about zone data visibility.  

I would not call this an "opposite conclusion".  Whether or not they
are "specifically" concerned about zone data visibility, they certainly
have some level of concern about it, and there's no point in haggling
about the level.  Also, whether one wants to call it "knee-jerk" or
"bitter experience" depends on how one wants to spin it. 

> the ones

That is, we can assume a higher level of concern on the part of those 
who use split dns, since split dns is more work to configure and 
maintain. 

The very existence of split dns, BTW, is particularly strong evidence
that concern about zone data visibility is considered a reasonable
thing; in fact one could go so far as to say that the "view"
implementation in bind is an endorsement by the bind authors of the
proposition that concern about visibility of zone data is a reasonable
thing. 

>From my perspective the most worrying payback is in how efficient one
can be in conducting attacks.  The information contained in a zone file
can be quite helpful in mapping someone else's network -- for example,
an enterprise network can span multiple address ranges in multiple
locations, including completely private connections using rfc1918
space, and a complete listing of a zone will likely contain a great
deal of information about these internal network connections that would
be quite hard to gain otherwise.

You are arguing that the "clueful" way to do this is to use split dns. 

But at the same time, you agree that in practice, only the very large
zones are subject to attacks that can collect the contents of the zone,
and even in that case there is question about how successful you can
be.  

The conclusion, therefore, is that denying transfers has in
practice been a successful way for the average registrant to accomplish
the same privacy, without requiring the same level of "clue".  And, 
independent of "clue", there is simply more work in maintaining split 
dns. 

Regards
Kent

---

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

> 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: Andrew Brown <[email-masked]>
Date: Sun, 8 Aug 2004 03:03:41 -0400

[ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or
   because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. 
]

-- 
|-----< "CODE WARRIOR" >-----|
[email-masked]             * "ah!  i see you have the internet
[email-masked] (Andrew Brown)                that goes *ping*!"
[email-masked]       * "information is power -- share the wealth."

---

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 26 Aug 2004 15:20:07 +0700

Date:        Tue, 3 Aug 2004 13:11:52 -0700
    From:        [email-masked]
    Message-ID:  <[email-masked]>

Another very delayed reply (apologies again...)

  | That is, at least from this sample, your assertion is incorrect -- the
  | evidence suggests that the majority of clueful registrants prefer NOT
  | to make their full zones visible.

I'm probably one of the addresses of the "majority" - you can't AXFR
the oz.au domain (or not from my servers anyway) - but the reason has
nothing whatever to do with any desire to control zone visibility, it is 
because AXFR is TCP, and using TCP for a transaction service simply
costs too much, it simply doesn't scale at all - so I don't allow it
except from those few hosts where it is needed, I don't want everyone
in the universe doing AXFRs.   If they want to get the data via NSEC
(once DNSSEC gets deployed here) I couldn't care in the least, in fact,
I'd prefer than dictionary type attempts, which cannot be prevented in
any reasonable way (regardless of how successful you define them to be).

kre

ps: apologies if this issue is long dead - one would hope it would be,
but from a quick glance at the subjects at the end of the list of
my pending namedroppers messages suggests that it is still dragging on...