Subject: Re: dictionary attack on nameservers

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 13 Aug 2004 09:16:58 +0200

On the heels of Miek's communication about the success of a dictionary 
attack on the nl-zone (size ca 1 million), I replicated the attack on the 
de-zone (size ca 8 millions). Thanks to Miek for the scripts.

Based on a combined German-English dictionary with more than 100,000 words 
and feeding John the Ripper with it to produce a wider attack base, I was 
only able to recover 80,000 domains, accounting to 1% of the total zone.

I guess it could be postulated that, by means of a dictionary attack, the 
amount of the domains that can be recovered from a zone remains constant, 
and that its effectivity diminishes inversely proportional to the growing 
size of the zone.

Best regards,
Marcos

--
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: Fri, 13 Aug 2004 10:12:35 +0100

--On 13 August 2004 09:16 +0200 "Marcos Sanz/Denic" <[email-masked]> wrote:

> Based on a combined German-English dictionary with more than 100,000
> words  and feeding John the Ripper with it to produce a wider attack
> base, I was  only able to recover 80,000 domains, accounting to 1% of the
> total zone.

Interesting - is that after a full run? IE you didn't stop because you
got bored.

Anyone have an obvious large source of in-addr.arpa PTR
records that we could do use to extract .de names and get the percentage of
the total .de zone size that yields (even with false positives)?

Alex

---

From: Peter Koch <[email-masked]>
Date: Fri, 13 Aug 2004 11:23:03 +0200

> the total .de zone size that yields (even with false positives)?

given that a very large fraction of the names/zones within DE points to a
relatively small number of IP addresses (which has been a result of the
various hostcounts during recent years), and, in turn, most of the PTR RR
targets then differ only at the third, fourth, fifth level, I'd be surprised
if this approach would change the result dramatically.

-Peter

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 13 Aug 2004 11:44:01 +0200

> Interesting - is that after a full run? IE you didn't stop because you

That was a full run. It didn't require much patience because the attack 
was performed directly over the zone file and not via DNS queries.

Regards,
Marcos

---

From: Alex Bligh <[email-masked]>
Date: Fri, 13 Aug 2004 11:08:29 +0100

--On 13 August 2004 11:23 +0200 Peter Koch <[email-masked]> 
wrote:

> targets then differ only at the third, fourth, fifth level, I'd be
> surprised if this approach would change the result dramatically.

My guess would be the same. But some people here whose knowledge re DNS we
should respect have asserted that if in-addr.arpa (for instance) could
equally be used as an attack to enumerate a zone file. 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.

I suspect most zones have nothing but www and MX records. In which case
iterating through .de and reporting the number of unique www and MX
IP addresses would set an upper bound on the number of records discoverable
through in-addr.arpa attack (operating on the assumption there are not
a large number of IP addresses with forwards in other zones, or no forwards,
that have reverses that resolve to .de addresses, which I think is fair).

Alex

---

From: Jim Reid <[email-masked]>
Date: Fri, 13 Aug 2004 11:21:23 +0100

>>>>> "Marcos" == Marcos Sanz/Denic <[email-masked]> writes:

    Marcos> Based on a combined German-English dictionary with more
    Marcos> than 100,000 words and feeding John the Ripper with it to
    Marcos> produce a wider attack base, I was only able to recover
    Marcos> 80,000 domains, accounting to 1% of the total zone.

Thanks to you and Miek for doing this. Another way of looking at the
result is 80% of your dictionary got a successful hit in .de.  Which
shouldn't be a surprise. I wonder what the success rate would be with
a bigger dictionary: ie <word>-<digit>, <plural-word>-<digit>,
<word><word>, <word>-<word>?

    Marcos> I guess it could be postulated that, by means of a
    Marcos> dictionary attack, the amount of the domains that can be
    Marcos> recovered from a zone remains constant, and that its
    Marcos> effectivity diminishes inversely proportional to the
    Marcos> growing size of the zone.

I'm not sure if a statistician would draw that conclusion from a
sample of two (attacks and zones).

---

From: Roy Arends <[email-masked]>
Date: Fri, 13 Aug 2004 13:46:56 +0200 (CEST)

> and that its effectivity diminishes inversely proportional to the growing

Another interesting test would be to hash the entire .de zone, and do a 7
character wide (ie. 37^7) bruteforce on the hashes (since it is trivial
to enumerate hashes using NSEC++ ).

My cpu is capable of about 300000 h/s.

So an entire OFFLINE bruteforce takes about

37^7/300000/86400 = 3 days, 16 hrs.

To optimise, given that changing salt is costly, a dictionary of
truncated, non colliding hashes(bruteforce/salt) can be built, which is 89
Gbyte (or 3Gbyte using rainbow tables), after which lookups are trivial.

This is just to show that hashing does not do wonders.

Marcos, could you share with us the percentage of the .de zone which have
labels < 8 characters ?

Thanks,

Roy Arends

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 13 Aug 2004 15:09:23 +0200

> Marcos, could you share with us the percentage of the .de zone which 
have

Sure. That brute force on the hashes would deliver 13% of the zone.

Best,
Marcos

---

From: Roy Arends <[email-masked]>
Date: Fri, 13 Aug 2004 15:18:50 +0200 (CEST)

> Sure. That brute force on the hashes would deliver 13% of the zone.

Okay,

Not a big vector,

Thanks,

Roy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 13 Aug 2004 15:34:38 +0200

> > Sure. That brute force on the hashes would deliver 13% of the zone.

What had you expected? German words aren't precisely well-known for their 
information density.. :-)

---

From: Roy Arends <[email-masked]>
Date: Fri, 13 Aug 2004 16:10:01 +0200 (CEST)

> information density.. :-)

Heh,

I still remember the german word for computer:

datenverarbeitungsmachine

:-)

Roy

---

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 15:59:51 +0000

> Marcos, could you share with us the percentage of the .de zone which have

<http://www.netsys.com/ietf/1995/3167.html> bears on this somewhat.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 13 Aug 2004 17:34:17 +0100

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 :-)

Alex

---

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

> 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: Peter Koch <[email-masked]>
Date: Fri, 13 Aug 2004 18:50:42 +0200

> public.  there is no reasonable expectation of privacy on the part of a

There's a difference between "keeping the registration secret" and "not
wanting the fact of registration/modification instantly visible". The first
may be arguable while the second seems reasonable to me. I'm not sure 'privacy'
is the best term to cover this.
The 'requirement' then would be that any 'diff' of the zone be not made easier
by DNSSEC than it was computable without DNSSEC (whether or not non DNS methods
were used or contributed to the collection).

-Peter

---

From: Danny Mayer <[email-masked]>
Date: Fri, 13 Aug 2004 17:40:50 -0400

><http://www.netsys.com/ietf/1995/3167.html> bears on this somewhat.

It would be interesting and useful to rerun your perl script on today's .com
domain and see the new numbers based on the length of the domain name.

Danny

---

From: Miek Gieben <[email-masked]>
Date: Mon, 16 Aug 2004 13:58:57 +0200

[On 13 Aug, @09:16, Marcos wrote in "Re: dictionary attack on names ..."]
> On the heels of Miek's communication about the success of a dictionary 

just for the curious, I've just done the following:

What is the best dictionary on the planet to attack a zone file? 
Indeed, the .com and .net zone files. So that's what I did, I tried
to see how much of .com/.net is in the .nl zone.

Note: I did an OFFLINE attack, which took a few hours. (This can be
optimized, the script I use is lame)

The results:
.com contains about 29 million names. After some time I got 495913
names out of the 1187008 names in the NL zone.  This is 41.77 percent
of the NL zone

.net contains 4861825 names. After some time I got 285674 names. That
is 24.06 percent of the NL zone.

If I combine .com and .net (taking into account some overlap) I get
504758 out of 1187008 names. This is 42.52 percent of NL zone.

grtz Miek

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 16 Aug 2004 14:52:12 +0200

...
> 504758 out of 1187008 names. This is 42.52 percent of NL zone.

Care to repeat this for, e.g., josefsson.org?  The zone walking issue
is not limited to the zones that are best suitable for dictionary
attacks.  I believe enumerating small zones is more difficult.
Further, it may be more useful to be able to enumerate small zones,
compare:

  Steven M. Bellovin, "Using the Domain Name System for System Break-Ins", in
  Proceedings of the Fifth Usenix UNIX Security Symposium, Salt Lake City, UT,
  June, 1995. http://www.research.att.com/~smb/papers/dnshack.pdf

Btw, AXFR is permitted for josefsson.org, if you want to compare
success rate of a dictionary attack.

Thanks,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Mon, 16 Aug 2004 18:34:24 +0000

> to see how much of .com/.net is in the .nl zone.

i expect that an ambitious and committed data miner would buy spammer
cdroms, run their own web crawlers, buy the ISC Domain Survey (see
www.isc.org/ops/ds/) and add both local- and international-language
common word dictionaries, along with combinations (with and without
hyphens) and abbreviations and misspellings and all kinds of suffixes
and prefixes (like number-strings).

the hard part of proving this is that to do a proper job, one would have
to have the same kind of monetary incentive that a true data miner would
have.  but that monetary incentive invariably comes with a disincentive
to publish one's results and methods.

so, unless we can sponsor some kind of contest for creatively minded
people (sort of like "capture the flag" or the international programming
olympics), the best we'll see published from the academic / research /
commercial sector will be derivatives ("i can prove that data miners are
using the following methods because there's no other way information X
could have been learned and used") or approximations ("i got 20% without
even half trying") or guesses ("all useful enumerations are already
possible.")

---

From: David Blacka <[email-masked]>
Date: Mon, 16 Aug 2004 15:28:30 -0400

> to publish one's results and methods.

What are we trying to prove, again?  It seems to me that all we need to prove 
is that for a dictionary attack to be "successful", it requires a non-trivial 
amount of effort.  A point which you seem to already concede, and we seem to 
be slowly showing.

I could be wrong, but it seems to me that the folks arguing for protection 
against zone enumeration are just asking that zone enumeration not be made 
worse.  So, if it takes a significant amount of effort to enumerate a zone 
without DNSSEC, and a similarly significant amount of effort to do so with 
DNSSEC, I think they would all be satisfied.

This argument that because a sufficiently creative and determined data miner 
might be able to enumerate a zone today, we should have no problem making it 
trivially easy with NSEC chain walking seems either obtuse or disingenuous to 
me.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    VeriSign Applied Research

---

From: Paul Vixie <[email-masked]>
Date: Mon, 16 Aug 2004 19:54:40 +0000

> What are we trying to prove, again?  It seems to me that all we need
> to prove is that for a dictionary attack to be "successful", it
> requires a non-trivial amount of effort.  A point which you seem to
> already concede, and we seem to be slowly showing.

actually, i don't find "triviality" to be a relevant standard for this.
what i want to know (or even prove or disprove) is whether it's already
being commonly done and whether putting more effort into avoiding "zone
walking" is an instance of the general principle called "closing the barn
door after the animals have already escaped."

for "triviality" to be a relevant standard, we would have to agree that
committed dataminers are less of a privacy threat than uncommitted ones
(and i won't agree that this is true) and also agree that committed data-
miners aren't going to make a market in domain names by offering them to
less committed dataminers (and i won't agree that this is true, either.)

> worse.

you're not wrong.  but "they" could be looking at this the wrong way.  if
zone enumeration is already possible, then what exactly are we hoping to
"buy" by spending global design and implementation costs "preventing" it?
does the incremental benefit outweigh the incremental cost?  are you sure?

> So, if it takes a significant amount of effort to enumerate a zone
> without DNSSEC, and a similarly significant amount of effort to do so
> with DNSSEC, I think they would all be satisfied.

perhaps.  but i would not be satisfied.  knowing that it's going to
happen either way, and knowing that the entities most affected by it
will be a small number of registries and registrars, not domainholders,
and knowing that the incremental costs are dramatically huge, makes me
want a better cost:benefit analysis than has yet been presented here.

> This argument that because a sufficiently creative and determined data
> miner might be able to enumerate a zone today, we should have no
> problem making it trivially easy with NSEC chain walking seems either
> obtuse or disingenuous to me.

see above.

---

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

>amount of effort.  A point which you seem to already concede, and we seem to

Not to argue, but to demonstrate the confusion over this, it's not 
clear to me that:

    'for a dictionary attack to be "successful", it requires a non-trivial
    amount of effort.'

I stress that I don't know...but I've heard that in these days of 
rooted machines on cable modem networks, "trivial" isn't the issue.

(I used to think the solution to spam was simple - make it more <cpu> 
expensive to send mail.  But if the sender is just 'stealing' 
machines, such a solution is pointless at best.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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

---

From: Danny Mayer <[email-masked]>
Date: Mon, 16 Aug 2004 17:54:47 -0400

>want a better cost:benefit analysis than has yet been presented here.

All of this is true, but also remember that the cost/benefit picture is 
constantly
changing as costs of equipment go down, CPU, network speeds go up, domain
names increase and the cost and complexity of deploying DNSSEC goes up
as this gets discussed.

More to the point, what benefit do these people have in getting all these
names/addresses? What do they do with it?

Danny

---

From: David Blacka <[email-masked]>
Date: Mon, 16 Aug 2004 18:58:39 -0400

On Monday 16 August 2004 3:54 pm, Paul Vixie wrote:
> > > ...
> > > the hard part of proving this is that to do a proper job, one would
> > > have to have the same kind of monetary incentive that a true data miner
> > > would have.  but that monetary incentive invariably comes with a
> > > disincentive to publish one's results and methods.
> >

How do we move this conversation along?  From your previous comments, it seems 
that it is nearly impossible for this group to prove (show) or disprove that 
successful data mining already occurs.

It seems like you are saying:
  * in order to work on this we must demonstrate A
  * it is impossible to demonstrate A

Am I wrong?  If not, where do we go from here?

> less committed dataminers (and i won't agree that this is true, either.)

Valid points.  In your mind there is no difference between a world were a few 
determined folks can get maybe 90% of a zone with effort, and a world where 
anyone can get 100% of a zone with virtually no effort?

Note that I, personally, do not feel very strongly about this issue either 
way.  I was just feeling that the current discussion wasn't all that 
productive and was hoping (futilely, probably) to redirect it to a more 
productive path.

> does the incremental benefit outweigh the incremental cost?  are you sure?

Trying to find the disconnect here:  clearly folks who are worried about zone 
enumeration do not believe that zone enumeration via data mining is currently 
successful (for some definition of successful), and they clearly think there 
is a substantial difference between getting some fraction of a zone and the 
whole thing.

> want a better cost:benefit analysis than has yet been presented here.

I would think that a cost/benefit analysis would be useful, but I've also seen 
both side fail to agree on either the costs or the benefits.

I also think that there are somewhat compelling arguments that this *isn't* 
just a problem for a small number of registries and registrars.  It is clear 
that you, as a domainholder, don't care, but can you speak for all of the 
other domainholders?

---

From: David Blacka <[email-masked]>
Date: Mon, 16 Aug 2004 19:05:49 -0400

On Monday 16 August 2004 3:55 pm, Edward Lewis wrote:
> >What are we trying to prove, again?  It seems to me that all we need to
> > prove is that for a dictionary attack to be "successful", it requires a
> > non-trivial amount of effort.  A point which you seem to already concede,
> > and we seem to be slowly showing.
>

I guess "trivial" isn't a precise enough term ;)

But the cost of doing something is always relevant, even now when some 
malefactors can marshall an army of zombies.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 16 Aug 2004 23:44:03 +0000

> How do we move this conversation along?  From your previous comments,
> it seems that it is nearly impossible for this group to prove (show)
> or disprove that successful data mining already occurs.
> 

i'm not sure.  i'm one of those to whom "A" (in this example) is trivially
observable and a well known and well documented fact.  but i am afraid that
it's not as trivially observable by others as it is by "the antispam crowd",
and that _objective_ proof might be hard to come by.  i keep hoping that we
will somehow reach agreement, or find a different basis on which to close the
gap.  see my separate post today about a possible "datamining olympiad".

> ...  In your mind there is no difference between a world were a few
> determined folks can get maybe 90% of a zone with effort, and a world
> where anyone can get 100% of a zone with virtually no effort?

there is some difference, but it's smaller than the difference in cost
between "the 10-year dnssec" and "the 15-year dnssec".

> Trying to find the disconnect here: clearly folks who are worried
> about zone enumeration do not believe that zone enumeration via data
> mining is currently successful (for some definition of successful),
> and they clearly think there is a substantial difference between
> getting some fraction of a zone and the whole thing.

yes.  or they think there's a whole subpopulation of chickenboner dataminers
who don't have the fortitude to gather the data using pre-dnssec methods,
who will jump on the bandwagon once the bar is lowered (to "zone walking"),
and they somehow think the number and kind of attacks they're getting now
is more refined and more deliberate than the kind of attacks they'll get
once the chickenboners are allowed to play.  there may be merit in that, but
i don't expect to see arguments about these "shades of gray".  (in public.)

> I also think that there are somewhat compelling arguments that this
> *isn't* just a problem for a small number of registries and
> registrars.  It is clear that you, as a domainholder, don't care, but
> can you speak for all of the other domainholders?

well, let's open up the ol' archives and take a look-see on that topic.

in message <[email-masked]> on 26-may-2004, i wrote:

| in my day job, i'm in touch with a lot of enterprise dns users, and
| they universally tell me that the data and/or names they consider
| sensitive enough to worry about axfr or zonewalking, would also be
| dangerous for queries, and so they run "split dns" so that only
| internal hosts can see the data.  they've turned off external axfr
| because it's unnecessary, not because it would expose data they care
| deeply about keeping private.  the data they care deeply about keeping
| private is only available "internally."

(i also proposed a survey and offered to run it, but received no words of
encouragement or even acknowledgement that these issues mattered, so i've
done nothing more on this thread to date.)

then later on (3-aug-2004) i wrote:

| consider that almost any use made of a domain will subject it to
| public view, where it can be and will be recorded.  consider that many
| uses of this data are benign or even well intended, like measurements
| or search engines.  consider that every bad use (UCE, etc) can be and
| will be made whether obscurity is used or not.
| 
| if you have information you don't want the world to know the name of,
| then don't put it in dns at all, or use "split dns" to limit the
| viewability of this data to small trusted population such as your
| intranet.

so, i'm not sure whether i speak for all domainholders, but certainly "many"
and i'm still willing to help discover "how many" if there's encouragement
and if it begins to seem that this is generally relevant "design data".

---

From: [email-masked]
Date: Mon, 16 Aug 2004 20:11:56 -0700

> | in my day job, i'm in touch with a lot of enterprise dns users, and
                                              ******************** 

Unfortunately, this doesn't tell us anything about "non-enterprise dns
users" -- which I will defins as smaller organizations/businesses that
are big enough to run their own dns, but not big enough to keep heavy
duty dns gurus on their staff. 

[...]

> | viewability of this data to small trusted population such as your

In my experience, "split dns" most frequently accompanies firewalling
of some kind, and thus there are subtantial other considerations in
addition to simply hiding names.  Presuming that there is no
firewalling going on, and that a finer granularity than "insider vs
outsider" is not desired, how is split dns superior to simply denying
axfers?

> and if it begins to seem that this is generally relevant "design data".

How would you survey the registrants described above, the 
"non-enterprise dns users"?

Regards
Kent

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 17 Aug 2004 03:32:42 +0000

> > | in my day job, i'm in touch with a lot of enterprise dns users, and

your definition is entirely local to you, in that case.  since i brought
it up, let me explain what i meant.  "non-isp's who run their own name
servers".  they don't have to be using bind and they don't have to be
large.  they could be home/hobby users.  i never realized how many of
these folks would exist when i first starting fixing bind bugs in ~1989.
but in the time since then, through consulting, rfc writing, private and
public e-mail, usenet, and now isc's paid support programme, i've met a
l-l-lotta these folks.  i hope i've even met a representative sample of
them.

> > so, i'm not sure whether i speak for all domainholders, but
> > certainly "many" and i'm still willing to help discover "how many"
> > if there's encouragement and if it begins to seem that this is
> > generally relevant "design data".
> 

given your somewhat localized definition of "non-enterprise", which is
neither similar to nor compatible with my own, i have no freaking idea.

but assuming that we're just interested in an objective study, we'd have
to agree on what the survey questions should be, find someone to run the
survey who we think is above suspicion of data-tampering, write the
survey, and then publicize it far and wide.  to all the usual internet
mailing lists and usenet newsgroups; through vendors to their customer
lists; through the ITU to their members.  pretty much the only publicity
i'd say is nonnegotiably "off the table" would be spamming it.  we'd want
to get a few thousand responses and we'd want to have some comfort that
we didn't leave anybody out.  such a survey might take three months.

---

From: David Blacka <[email-masked]>
Date: Tue, 17 Aug 2004 02:08:04 -0400

On Monday 16 August 2004 7:44 pm, Paul Vixie wrote:
> it's not as trivially observable by others as it is by "the antispam
> crowd", and that _objective_ proof might be hard to come by.  i keep hoping
> that we will somehow reach agreement, or find a different basis on which to
> close the gap.  see my separate post today about a possible "datamining
> olympiad".

At this point, I am concerned that what you are talking about and what they 
are talking about does not seem to be the same thing.  (or maybe you are and 
I've just read more into some folks postings than I should've.)

What I hear you (and some others) saying is:
   There is obviously datamining and attacks stemming from that datamining 
now.  Partial (or total?) zone enumeration is possible today using such 
techniques, so: zone enumeration via DNSSECbis will not substantially change 
the threat model present on the Internet.  Thus, it is not worth the 
engineering pain to try and stop it.

What I hear the folks concerned about datamining at the registry/rar level 
saying is:
  There may be datamining, but we don't want to be part of the problem.  
DNSSECbis forces us to be part of the problem.

At some level, I see this argument as:
  * group A says: we have this policy against zone enumeration.  We cannot 
deploy DNSSECbis because of it.
  * group B says: your policy is stupid, change it.

Either we need to convince group A that their policy is, in fact, stupid, or 
we need to solve the problem.  Or just leave them behind.

> > getting some fraction of a zone and the whole thing.

Just to press down a bit further: do you see no substantial difference between 
being able to get 100% of a zone vs. getting perhaps 80% via datamining?  
This is, I think, a major disconnect.  

I know that in my own experience I've seen malefactors using readily available 
TLD zone files to find newly registered domain to make their own activities 
more efficient.

> so, i'm not sure whether i speak for all domainholders, but certainly
> "many" and i'm still willing to help discover "how many" if there's
> encouragement and if it begins to seem that this is generally relevant
> "design data".

I don't know how relevant it is.  At this point, it is mostly just part of 
your argument, and this part of the argument would be more compelling if it 
were less anecdotal.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

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

--On 16 August 2004 23:44 +0000 Paul Vixie <[email-masked]> wrote:

> 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",
but despite its triviality, you haven't posted any data to support it? Can
you post the exact methodology and how many names from (say) .de can you
recover using this method?

I am prepared to accept David Blacka's contention (if I understand it) that
it is impossible to either prove that an effective attack either can or
cannot currently occur (or rather that it's difficult so to prove/disprove)
but if your position is that it is possible to prove it by trivial example,
let's see it.

If David is right, then at the most generous, DNSSEC enumerability turns
a risk of effective enumerability into a certainty.

Alex

---

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: [email-masked]
Date: Tue, 17 Aug 2004 11:23:28 +0000

> it is impossible to either prove that an effective attack either can or
                                           _________
	Alex, you/we apparently do not share a common view of what
	is "effective" and I expect that Paul's "blackhat" community
	has the same problem.  Effective is in the eye of the user.
	2% successful enumeration may be effective for some while 95%
	enumeration is not successful for others.  Then there are
	the other, obliquely mentioned factors that must be considered:

	) zone size.  2% of a 70million entry zone might be ok, while 2% of
	              a zone of 10 entries might be less useful.
	) zone "churn".   the persistance of zone entries is a trigger for
	              how effective "slow-scan" enumeration is.  If I can 
	              be assured that data I collected in 1997 is still going
		      to be in the zone, I can focus on enumerating the parts of 
		      the zone that are more dynamic. 

	mitigation of enumeration capability isa slippery slope.  where are the 
	boundaries?   AXFR may be one end - normal queries at the other. before 
	spending excessive time on designing a technical solution, can folks pick
	a defenseable point on the slope?  

	(blocking AXFR has a defensable point, but only for very large zones.  keeping
	TCP sessions open for hours to move a 70m entry zone is likely a bad idea, esp
	when the zone changes every 15 minutes.  This is a reason to block AXFRs)

> Alex

--bill

---

From: David Blacka <[email-masked]>
Date: Tue, 17 Aug 2004 10:57:54 -0400

> TLDs but for policy, not technical, reasons.]

I disagree.  I think the WG has answered this question: No.  This is why we 
advanced the DNSSECbis documents.

The real question here is: Does the NSEC walking issue create a significant 
deployment problem?  Granted, this question is much harder to answer.

> number of admittedly very significant corner cases?

Whose time and effort?  Yours?  No one can force you to work on the problem.

But the way the question is phrased make me wonder if the causality is 
backwards.  The question says that working on the zone enumeration will hold 
up DNSSEC deployment.  Maybe, instead, people want to work on the problem 
because the problem will hold up DNSSEC deployment.

> zones or preventing Bad People from generating a copy of the TLD.

Don't we know this answer, too?  Clearly, they would rather not make that 
choice, but what I hear co.uk saying is that for now they would prefer to 
prevent zone enumeration.  Not solving this problem makes everyone make this 
choice.

---

From: Jim Reid <[email-masked]>
Date: Tue, 17 Aug 2004 17:41:58 +0100

>>>>> "David" == David Blacka <[email-masked]> writes:

    >> [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?

    David> Whose time and effort?  Yours?  No one can force you to
    David> work on the problem.

That's certainly true. Not that I could contribute much anyway. But
this is beside the point. We have a DNS infrastructure that's not
secure. The longer we delay the deployment of DNSSEC (for some
definition of "deployment" and "DNSSEC"), the more likely it is
Something Very Bad will happen. It's only a question of time before
the script kiddies start to attack the DNS.

The current drafts are good enough IMO and it's time the WG took an
engineering decision to stop tinkering with the protocol and got down
to work on the deployment and migration issues.

    David> But the way the question is phrased make me wonder if the
    David> causality is backwards.  The question says that working on
    David> the zone enumeration will hold up DNSSEC deployment.
    David> Maybe, instead, people want to work on the problem because
    David> the problem will hold up DNSSEC deployment.

Hmm: is the glass half-empty or half-full? I suppose it depends where
someone is looking from.

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

    David> Don't we know this answer, too?  Clearly, they would rather
    David> not make that choice, but what I hear co.uk saying is that
    David> for now they would prefer to prevent zone enumeration. 

The co.uk policy committee is saying this. Which is not necessarily
the same thing as the punters who have registered domain names under
co.uk. I wonder how many of them will be content that their zones
remain unsecured because the policy committee believes preventing zone
enumeration by NSEC traversal is more important than getting the co.uk
zone signed? "It's a pity you lost millions and alienated your
customers because somebody spoofed the DNS data for BigBank.co.uk. But
don't worry. Spammers can't get a copy of co.uk by walking the
NSECs. That'll make you feel better."

---

From: Alex Bligh <[email-masked]>
Date: Tue, 17 Aug 2004 19:20:04 +0100

> Whose time and effort?  Yours?  No one can force you to work on the

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.

Alex

---

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 22:59:42 +0000

> Just to press down a bit further: do you see no substantial difference
> between being able to get 100% of a zone vs. getting perhaps 80% via
> datamining?  This is, I think, a major disconnect.

difference to whom?  to a dataminer, 100% is better than 80%.  to a registry,
100% is worse than 80%.  to a domainholder, it matters whether you're in the
20% or in the 80%, but not very much.

> I know that in my own experience I've seen malefactors using readily
> available TLD zone files to find newly registered domain to make their
> own activities more efficient.

yes, i saw some correlation between COM/NET/ORG AXFR's on f-root (back when
AXFR from f-root was the only way to get this data) and bad acts by bad folks.
but as we've all seen, making it harder isn't the same as stopping bad acts,
or even slowing them down.  (sure does cost the good guys more, though.)

---

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

> > ...  i'm one of those to whom "A" (in this example) is trivially observable
> 
> 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: Alex Bligh <[email-masked]>
Date: Wed, 18 Aug 2004 10:20:48 +0100

--On 17 August 2004 23:00 +0100 Jim Reid <[email-masked]> wrote:

> kill that idea.

That was /before/ DNSSEC-bis was sent to the IESG. I thought the point of
sending it to the IESG was that people in general felt it was deployable
now (as do I, in certain circumstances, and indeed DLV widens those
circumstances considerably). I thought the whole point of the debate
as to whether the w/g should reach consensus to send DNSSEC-bis to the
IETF was so as not to delay deployment whilst the w/g worked on the
question of whether to / how to solve some additional issues that had
been raised, primarily enumerability. If you thought enumerability
was going to delay deployment, notwithstanding DNSSEC-bis having been
sent to the IESG without any fix, why send it?

Alex

---

From: Alex Bligh <[email-masked]>
Date: Wed, 18 Aug 2004 10:25:40 +0100

> i'd previously ranted against on a personal level.

Agree & your final sentence is appreciated.

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

I think because every time someone tries to gather requirements to address
the enumerability problem, the question of whether or not it needs to be
addressed at all gets brought up. I think straight answer is "it is a
requirement for a significant community, and not for others". I suspect we
are never going to get consensus on whether or not it should be a
requirement, and we will generate heat but not light from further
discussion. If it is sufficiently significant, IMHO it should be addressed,
and if it is expensive (especially but not exclusively server side) it
should be optional in its implementation.

Alex

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Aug 2004 03:55:43 -0000

Paul Vixie writes:
> what's trivially observable is that the names are not remaining secret,

Here's an interesting picture of a tree:

   53145ddd853407645babda07a9dd2b63.pictures.cr.yp.to

Right now there are 1488 other pictures available from the same server.
You claim that the names aren't secret. Show us the pictures!

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago