Subject: Re: dictionary attack on nameservers

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 03 Aug 2004 13:06:48 -0400

> Noone is asking for more any degree of functionality more than is
> currently present in BIND et al. 

The current functionality is, at best, an implementation artifact.  We
need a clear spec for "how good" any anti-enumeration defenses need to
be, in order to avoid wasted effort on a solution which is later ruled
not good enough.

Given the existence of other mechanisms for partial enumeration, "as
good as possible" is a frustrating non-starter.

At several different zone sizes, what fraction of the zone must be
protected from disclosure?  

If a partial zone enumeration contains 90% "chaff" entries, is it
still considered a successful attack?  How about 99%?  99.99%?

Is an enumeration which takes months or years (of a zone which is
changing on a daily or hourly basis) worth worrying about?

						- Bill

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

> 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.

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: Paul Vixie <[email-masked]>
Date: Tue, 03 Aug 2004 19:55:24 +0000

> 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.

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."

---

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: Fri, 13 Aug 2004 15:51:51 +0000

> ... So if we want to show that actually, no, zones like .de are not
> enumerable to a great extent now (which is what I believe as well), it
> would be good if we had some hard data to show it.

you'll have to think like a datamining spammer rather than like a
computer science researcher if you want to show what's possible.  use a
number of sources (inaddr, dictionaries, web crawls, buying lists) and a
lot of patience.  my own experience in trying to protect our privacy from
these people and their methods has given me some respect for their powers,
and no respect for "turn off AXFR" as a way to thwart them.  they aren't
children.  they're mean criminal bastards and they fight dirty.

but the most important issue to me in this discussion is still "who has
a reasonable expectation of privacy?"  domainholders do not intend to
keep their domains secret -- they have domains so they can use them in
public.  there is no reasonable expectation of privacy on the part of a
domainholder.  so, what about the registry?  for reasons of competition
and scam-attacks against the registry business itself, privacy seems to
be desirable at the "compilation" level.  dnssec's walkability clearly
hurts the business interests of registries.  registries clearly have an
expectation of privacy.  but how reasonable is that expectation?

---

From: Paul Vixie <[email-masked]>
Date: Fri, 13 Aug 2004 16:36:58 +0000

> > <http://www.netsys.com/ietf/1995/3167.html> bears on this somewhat.
> 
> Great quotations. Paul wrote:
> > There are ~140,000 .COM names today
> ...
> > I call .COM "full" because it takes eight (8) characters of typing
> > before a user has narrowed her possibilities to under 10% of the
> > total.
> 
> circa 30m subsequent registrants (now) disagree :-)

i don't think they disagree.  i think we gave them no choice.  but it's
very interesting to study the numbers.  this article was not considered
controversial at the time it was published.

---

From: Jim Reid <[email-masked]>
Date: Tue, 17 Aug 2004 09:45:13 +0100

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

    Alex> DNSSEC enumerability turns a risk of effective enumerability
    Alex> into a certainty.

So get over it :-) Zone enumeration is already a fact of life. The
quick and dirty dictionary attacks mounted by Marcos and Miek have
been fairly effective. A more concerted effort would yield even more
of the TLD. And a dictionary attack -- comparable to brute-forcing a
DES key in its crudeness -- isn't the only way of enumerating a
TLD. Most of those other techniques don't care either way about NSEC
and won't go away if NSEC gets superseded with some flavour if NSEC++.

To get things back on-track, the WG needs to answer these two
questions:

[1] Does the inevitability of NSEC walking create technical or
protocol problems? [Sure, it creates a deployment problem for some
TLDs but for policy, not technical, reasons.]

[2] Is it worth the time and effort to "fix" NSEC walking -- and no
doubt hold up the deployment of a Secure DNS for maybe another 5 years
-- when this issue only creates *policy* difficulties for a small
number of admittedly very significant corner cases?

IMO the answer to both questions is no.

It would also be interesting to find out from the owners of domain
names in .de and .uk what they'd prefer: securing the DNS for their
zones or preventing Bad People from generating a copy of the TLD.

---

From: Jim Reid <[email-masked]>
Date: Tue, 17 Aug 2004 23:00:52 +0100

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

    Alex> Not only that, but we (Nominet) have offered contributions /
    Alex> funding to fix it. The point is we /want/ to see it deployed
    Alex> and are prepared to help make it deployable (according to
    Alex> our definition of deployable).

One the one hand, this is good. Nominet is putting its money where its
mouth is and taking a constructive approach. Excellent! OTOH, this is
bad because the end goal of that effort is to meet your (somehwat
vague) definition of deployable. What happens the next time someone
decides to move the goalposts? Does the protocol get tweaked forever
until everyone's definition of deployable gets met?

    Alex> I do not see how working to solve zone enumeration is going
    Alex> to delay deployability, as if those who think it isn't a
    Alex> problem are correct (and we are wrong), then it will get
    Alex> deployed notwithstanding our views.

Can you say opt-in? That was the last big controversial issue in the
DNSSEC protocol development effort. It took ~2 years for the WG to
kill that idea. Expect at least the same amount of time and effort
being expended by the WG on some flavour of NSEC++. Plus the same
again as the WG debates a type code change and/or version bit for
compatibility with the drafts that have just gone to IESG. And let's
not forget the interoperability and backwards compatibility problems
this will create with DNSSECbis either. It's also possible IESG won't
endorse the current drafts because the WG is working on a fix for zone
enumeration.

As for deployment, sure, some TLDs can and will deploy DNSSECbis
assuming it gets blessed by IESG. But if there's uncertainty about the
protocol -- because the WG is working on a fix for zone enumeration --
this creates a major headache for applications developers and
vendors. Do they ship code for the current spec or hold off until the
next version of the protocol is done? Whenever that may be... What do
they do about embedded devices -- say 3G mobile phones -- that can't
be easily upgraded once they're in the field? That's undoubtedly going
to delay deployment and getting a meaningful installed base of
DNSSEC-aware devices used in anger. End users are likely to face the
same dilemma: do harassed and overworked zone administrators get up to
speed with the current spec and deploy it or else wait for the next
version? Or the one after that? Hint: some of these people are still
running BIND4.

Meanwhile, large chunks of the name space continue to be unsecured.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 17 Aug 2004 23:02:31 +0000

> >> It seems like you are saying:
> >>   * in order to work on this we must demonstrate A
> >>   * it is impossible to demonstrate A
> >
> > ...  i'm one of those to whom "A" (in this example) is trivially observable
> 
> Let me get this straight: you are saying a dictionary attack (or some other
> enumeration attack) on say .de (or .uk or .nl) is "trivially observable"...

no.  what's trivially observable is that the names are not remaining secret,
and that the abuse seen by domainholders today is indistinguishable from the
abuse that would be seen if full enumeration were simple, by AXFR or FTP or
zone walking.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 17 Aug 2004 23:09:01 +0000

> > ...  No one can force you to work on the problem.
> 
> Not only that, but we (Nominet) have offered contributions / funding
> to fix it. The point is we /want/ to see it deployed and are prepared
> to help make it deployable (according to our definition of
> deployable). I do not see how working to solve zone enumeration is
> going to delay deployability, as if those who think it isn't a problem
> are correct (and we are wrong), then it will get deployed
> notwithstanding our views.

the current spec will absolutely be deployed.  (the wg already advanced
it, and i know of enough deployment-related efforts to be confident that
dnssec-bis as more-or-less currently specified will see rubber meet road.)

working to solve zone enumeration in a subsequent spec and then migrating
from dnssec-bis to that spec is a workable approach.  and for all my rants
about the non-utility of the approach, i know that isc is committed to
implementing whatever the community decides upon, even if it's something
i'd previously ranted against on a personal level.

i'm not sure why this debate is even occurring.  everything's been decided.

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 21 Aug 2004 11:46:11 -0400

> Do you propose that the colour state be a per-querier per-name attribute
> (in which case it's going to be defeated by a distributed attack) or simply
> a per-name attribute?

The intent was a per-name attribute; my assumption is that all attacks
will be distributed.

> One thing I can't quite understand is what "get creative" means in this
> context. Delay a reply? (in which case just say add a "-" to the name and
> retry), or start leading the querier "down the garden path" by fabricating
> names within the appropriate interval (in which case at face value you need
> online signing, though admittedly this can be rate-limited).

My focus was on scan detection under the assumption that Someone Else
could think up appropriate countermeasures once a scan was detected.

I didn't consider the possibility of Chris Thompson's
divide-and-conquer random-order scan, so this is likely moot.

						- Bill