Subject: RE: dictionary attack on nameservers

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 2 Aug 2004 12:32:33 -0700

At blackhat there was a presentation on the ongoing .il vs .ps cyberwar.
This began with an attack on various pro-Palestinian groups and was shortly
followed by a retaliation on pro-Israeli sites and the entire .il domain.

It is pretty clear that whoever is running the .il domain is not going to
implement any scheme that makes it easier to walk the domain.

With respect to the claim made by Olaf that it is possible to zone walk
today, the possibility of a dictionary attack is very different from an
enumeration.

No dictionary attack is ever going to recover all the addresses in the
domain. You may get some proportion of the domains, but you will not get all
of them and will probably not even get most of them.

Security schemes ultimately come down to complexity arguments. The
complexity of an exhaustive dictionary attack is 28^l where l is the length
of the domain name. The complexity of an enumeration is n, where n is the
number of domains registered. Thus the number of steps required to recover a
domain on average is (28^l)/n vs 1. That is quite a big difference in
complexity terms. 3E11 harder for an 8 character domain name, which is not
all that long.

Sure you can cut down the complexity of a dictionary attack somewhat by
using phonemes, but you still have a lot of work. 12 character domain names
are commonplace. Even with phonemes you still have an exponential.

I think that it is pretty clear that what is being asked for here is a
mechanism that ensures that the cost of walking a domain remains an
exponential function of the length of the domain name.

		Phill

--
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:49:20 +0000

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

i just grepped rfc1034 and rfc1035, and rfc2181, and found no indication
that the internet standards community has ever considered the possibility
that obscurity was a feature of dns.

knowing what i know about the iab, i don't think they'd support this as
a feature-goal.  but it's worth asking them.

arguments of the form "the nonstandard bind hack whereby a certain protocol 
feature was protected by an ACL no longer has any effect if DNSSEC is
deployed" are at worst bizarre and at best nonsequitur.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Aug 2004 14:33:37 -0700

Why not persuade people to 'get with the program' by meeting their perfectly
reasonable security goals?

Seems a better plan to me than trying to persuade them that you understand
their security requirements batter than they do.

 -----Original Message-----
From: 	Paul Vixie [mailto:[email-masked]]
Sent:	Tue Aug 03 12:59:38 2004
To:	namedroppers
Subject:	Re: dictionary attack on nameservers 

> 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: Ben Laurie <[email-masked]>
Date: Thu, 05 Aug 2004 18:22:41 +0100

Peter Koch wrote:
> Miek Gieben <[email-masked]> wrote:
> 
> 
>>The main point of my post is that I can enumerate (for +/- 90%) a zone
>>in 24 hours, even if AXFR is blocked. 
> 
> 
> thanks for this effort, hard data is a Good Thing.

It is, but this is not hard data.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 6 Aug 2004 12:35:52 -0700

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ben Laurie
> Peter Koch wrote:

Actually Ben, it would appear that it is hard data, a dictionary of 
the 220,000 most common words in the English and Dutch languages 
only has 5% effectiveness. I would have expected a much higher
success rate. This data is hard evidence that a dictionary attack is
not a serious risk. 

That is much worse than password dictionary attacks where a much 
smaller dictionary tends to be effective unless there are symbol
restrictions in place.

The effectiveness against second level domains is in any case not
relevant to the issue of third level domains which is where I 
believe the problem is very significant. Split DNS is completely
ineffective when you are dealling with Web Services security issues
since the whole point is to establish interactions across 
enterprise perimeters.

The issue that concerns ME is not signing .com as signing 
verisign.com. There are many external resources I don't want to 
reveal the existence of. Until the launch at the beginning of
the month I would not want the existence of the servers for the
anti-phishing and anti-spam servers to be found and published
and reported on in the Yahoo stock bulletin boards.

The problem with NXT is that it breaks the expectations of the
administrator - expectations that it is sheer arrogance to 
call ignorance.

If I create a node ab12ye.example.com it is not currently visible
to the external world through the DNS. NXT changes that situation
for reasons that are neither obvious nor necessary.

---

From: Jim Reid <[email-masked]>
Date: Fri, 06 Aug 2004 23:10:55 +0100

>>>>> "phb" == Hallam-Baker, Phillip <[email-masked]> writes:

    phb> The issue that concerns ME is not signing .com as signing
    phb> verisign.com. There are many external resources I don't want
    phb> to reveal the existence of.

Fine. So don't put them in a public database in the expectation nobody
will ever find them there. Or go looking for them. You wouldn't hide a
spare front door key under the mat and hope a burglar would never
think of looking for it there, would you?

    phb> If I create a node ab12ye.example.com it is not currently
    phb> visible to the external world through the DNS.

Rubbish! As soon as that node is in the public DNS tree, it is public.
The very fact that you created the node in a public tree indicates
your acceptance that the name is public. You've published it. Sure,
the name may not be readily visible -- though someone could figure
that out easily enough from mail and web server logs or whatever. And
in the context of new services/ventures from your employer, enough
information about that will have leaked for someone to guess what the
likely domain names for them may be. If ab12ye.example.com isn't meant
to be visible, don't put it in the public DNS.

Your kidding yourself if you think that names in the public DNS can be
hidden from the Bad People you don't want to see those names.

---

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

---

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:

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

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 15:18:50 +0200 (CEST)

On Fri, 13 Aug 2004, Marcos Sanz/Denic wrote:

> > Marcos, could you share with us the percentage of the .de zone which
> have
> > labels < 8 characters ?
>
> 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: Peter Koch <[email-masked]>
Date: Fri, 13 Aug 2004 18:50:42 +0200

> 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

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: Paul Vixie <[email-masked]>
Date: Mon, 16 Aug 2004 18:34:24 +0000

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

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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Aug 2004 11:58:14 -0700

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

That is precisely the point. In the real world raising the cost of 
an attack to the point where it is greater than the expected rewards
is a very effective way of discouraging organized crime.

The fact that such information is not available today without cost
is a demonstration that the existing controls do have an effect.

You can design a secure protocol here or you can insist on sticking
to a misunderstanding of a 20 year old dogma. The point about the
security through obscurity argument was that it applied to discussions
of *architecture* not specific configurations. At the time there
were people who did not want any discussion of computer security at 
all at any level. Today we discuss architecture, but nobody openly
discusses configuration data and applying the security through
obscurity argument at that level is invalid.

		Phill

---

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

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

We know that it is not currently happening at the level of the 
delegated domains. 

Deploying DNSSEC in the TLDs is kinda pointless unless the 
security concious delegated domains want to join in.

I don't intend to waste my time as an advocate for a system
that provides an intangible long term benefit at the cost
of an obvious and solvable near term benefit. And I don't
think that many other security specialists will either.

One of the reasons I am arguing about the topic here is that
it is obvious to me as a security specialist that this issue
is going to be solved sooner or later. Ergo it is obvious that
the spec will not be finished until this happens.

As Karl Marx put it:

The philosophers have only interpreted the world in various ways; 
the point, however, is to change it.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Aug 2004 18:02:39 -0700

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

In the case of a business operating split DNS as example.com they discover
the names and addresses of all the machines that are externally accessible.

If the gang is a DDoS extortion racket they can then DDoS the systems that
perform the business processes of example.com until such time as the company
pays over $50,000 by making money transfers to a bank in Eastern Europe
where the cash is then picked up by co-conspirators.

If I am doing Web Services and a machine is DDoS attacked my first recourse
is likely to be to change the IP address and DNS name of the service and
update the Web Service description in the UDDI directory which is an access
controlled resource.

If the DDoS returns I am then going to look at the UDDI directory logs to
see which parties retreived the new location. At that point I respond to
attacks by introducing multiple names on different IP addresses and keep
changing arround until the sources of the attack have been isolated.

I can defend against this attack in the real world, but not if the DNS zone
example.com is trivially enumerable.

---

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

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".
> 
> How would you survey the registrants described above, the 
> "non-enterprise dns users"?

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: [email-masked] (Ted Lindgreen)
Date: Tue, 17 Aug 2004 10:13:20 +0200

[Quoting David Blacka, on Aug 17,  8:14, in "Re: dictionary attac ..."]

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

I think your analysis is correct.

A small addition: when left behind, the group A-TLDs will later get
questions from their domainholders like "why can't we have secure
domainnames?".
I am interested whether their domainholders will understand and be
happy with an answer like "we can not deploy domainname security,
because the zonefile then gets enumerable".

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

My personal opinion (based on having been ISP from 1983 to 1999,
one of the founders of the current .nl registry, and still being
involved in DNS) is that there will be no substantial difference.
What we see is:

1. Spammers
   They are interested in e-mail addresses. Both the quality and quantity
   of acquired e-mail addresses from domainname-mining (i.e. hostmasters
   via whois, etc.) is low compared to other means of acquiring e-mail
   addresses in bulk.
2. Domainname traders
   They are not interested in a complete list, they are only interested in
   when an "interesting" domainname is released.. To know this as soon as
   possible (i.e. before their competition), they probe their list of
   names at short intervals (clearly visible in the nameserver traces).
   And we indeed see them register those released names immediately
   after being (negatively) probed. Fully automated...
3. Attackers, being script kiddy's and others. These gals and guys usually
   probe ranges of IP-adresses, not domainnames.

For the three threats above, enumerability or non-enumerability makes
no difference.

I am still quite interested in the threatmodel of group A above,
and the exact requirements to defeat those threats (including
their estimated effectiveness), because I am perhaps missing
something.

Regards,
-- ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Aug 2004 07:03:35 -0700

> 3. Attackers, being script kiddy's and others. These gals and 
> guys usually probe ranges of IP-adresses, not domainnames.

Please, you are five years out of date here. The Juvenile delinquents
of the 1990s have grown up and some of them are supporting their
family through crime.

The problem today is NOT script kiddies. The problem is comming from
organized crime gangs in Eastern Europe, Russia, West Africa and
Boca Raton Florida.

These people have long criminal histories and they have brought age
old frauds to the net. DDoS extortion is simply an updated form of
protection racket. Advance fee fraud dates back to the crusades.

	Phill

---

From: [email-masked] (Ted Lindgreen)
Date: Tue, 17 Aug 2004 16:45:35 +0200

[Quoting "Hallam-Baker, Phillip", on Aug 17, 16:15, in "RE: dictionary attac ..."]
> protection racket. Advance fee fraud dates back to the crusades.

Phillip,

I'm affraid that I don't understand what link you see between
"organized crime gangs in Eastern Europe, Russia, West Africa and
Boca Raton Florida" and the difference between 20, 50, 80, 90, 99,
or 100% enumerability of zonefiles (which is what the discussion
is or was about, I thought).

If new requirements for DNS and/or DNSSEC are needed to cope with
these new forms of criminality, please specify those requirements.
Only if those requirements are expected to be effective and
cost-worthy, we should start planning on further definition,
implementation and deployment. Sofar, it looks like very costly
ghost-hunting.

-- ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Aug 2004 08:11:00 -0700

> is or was about, I thought).

You asserted that the issue was script kiddies. This is an
out of date assesment of Internet crime, the problem today
is from organized crime.

I don't think that any of the people claiming that enumeration
is not an issue have an understanding of todays internet use
and todays internet threats. Pauls blithe assertions that because
he has people to run a web server for enterprises he knows
everything about everything does not impress me. When a Fortune
50 company is going to discuss its security concerns they do not
call in a dns specialist, they call in a security specialist.

There is an easy way we could settle this argument, lets call
up some F50 security specialists and ask them for their opinion.

> implementation and deployment. Sofar, it looks like very costly

The attacks that are common from organized crime target specific 
infrastructures with the objective of making money for the attackers.

With guaranteed 100% enumerability an attacker can easily map
out the entire configuration of the target site DMZ in a matter of
minutes.

The DMZ machines have to maintain externally visible DNS links,
it is essential for their function. Split DNS is not an option
here.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Aug 2004 10:23:24 -0700

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

Then the sooner we have a DNSSEC specification that is ready for
deployment the better.

That means fixing security issues, not burrying your head in the
sand claiming that they do not exist.

The sooner the enumeration issue is fixed, the sooner we can start
on deployment. Until the enumeration issue is fixed to the satisfaction
of security specialists the spec is not going to be ready for 
deployment.

We have a security need, we have a simple solution, the only thing
that stops deployment is the fact that some people claim that the
problem does not exist according to a failled 20 year old dogma that
they do not understand.

Every argument raised on this list was raised fifteen years ago when
I was arguing the need for shaddow passwords in UNIX. It was several
years before crack came out and made it impossible for folk to hide
their heads in the sand.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Aug 2004 13:19:31 -0700

> > I was arguing the need for shaddow passwords in UNIX.
> 
> Really?  People said passwords are supposed to be public?  People said
> there were other easy ways of figuring out most users' passwords? 
> Fascinating.

People demanded that the encrypted password file be world readable.

The creation of shadow password files was very contentious at the time.
Turning on shaddow passwords was claimed as a security vulnerability.

Proposals that UNIX introduce a means of using ACLs to control acess
to the password file was met by exactly the same response that has
appeared on this list. Namely derision, claims that it is security
through obscurity, claims that the architecture of UNIX is inviolate,
claims that the additional complexity is unwarranted, claims that 
the solution is for users to get a clue, etc. etc.

Of course the shaddow password schemes on many unix clusters are
still useless because they don't have a real distributed auth scheme
and they simply ship arround the one way encrypted password file
so the systems are compromise one, compromise all. But at least it
is now possible to secure a UNIX cluster if you know what you are 
doing without having to rewrite the O/S or patch it.

	Phill

---

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:

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

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

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

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

Agree & your final sentence is appreciated.

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

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: Florian Weimer <[email-masked]>
Date: Wed, 18 Aug 2004 16:39:33 +0200

* Roy Badami:

>>>>>> "Florian" == Florian Weimer <[email-masked]> writes:
>
>     Florian> If the data were privacy-sensitive, it couldn't be shared
>     Florian> at all without explicit consent from the domain name
>     Florian> owner (at least according to most EU law). 
>
> That's an oversimplistic view of data protection legislation.  One of
> the principles in the UK implementation is that personal data can only
> be used for the purposes for which it was collected.

Yes, of course.  This means that if NS RRs (or other TLD zone
contents) were personal data, .COM/.NET registrars would have to
disclose what happens with this data (that is, VeriSign republishes it
in bulk, without any privacy safeguards).  However, hardly any
registrar does this right now.

For TLD owners, there might be other contractual obligations not to
publish the zone contents in bulk.  In this case, these obligations
should be named.  I've got a huch that privacy is not the real issue.
And if it's not privacy but simply the business interest of a few
(certainly not all) TLD operators, it might make sense to refrain from
adding baroque features to DNSSEC just to please them.

In the meantime, the discussion whether domain names are comparable to
phone numbers and deserve equal protection has resurfaced in Germany.
If something goes wrong, domain names might be considered personal
data rather soonish. 8-(

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 18 Aug 2004 08:00:23 -0700

> Can you be more specific about the kind of attacks?
> 
> Most of the attacks I know do not benefit from the knowledge of domain
> names.

The Israeli-Palestinian cyberwar went roughly thus:

Israeli hacker attacks sites operated by Hammas, Hezbollah
Palestinians retaliate
Israeli retaliate
Palestinians retaliate
Israeli hackers attempt retaliation, discover that there are no
	targets left
Palestinians attack every site that they know of which is 
	in the .il domain.

There is a lot of stuff on this on the net. The Israeli hackers
seem to have been a bunch of teenage hackers who did not know
what they were starting, or maybe they did since they now have
a really big line selling security consultancy to the sites
being attacked in retaliation for the sites they attacked.

The bottom line is that any site that comes up in the .il 
domain is going to be attacked as soon as it becomes known.

There are a bunch of other similar events. The incident 
in 2001 when the US and China got into a standoff over a 
spy plane led to a small scale cyberwar but it never got
very far before the situation was resolved.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 18 Aug 2004 18:10:46 +0200

> domain is going to be attacked as soon as it becomes known.

And .ps and .il have completely segregated backbone infrastructure, so
that you can safely tell an attack of a .ps site from an attack on an
.il site?

In this case, wouldn't it be easier to go for the infrastructure
itself, and not for specific sites?  Or are we talking about attacks
on the application layer?

(I'm a bit surprised because it's hard to imagine for me that the
infrastructure is so clearly separated.  Unfortunately, I haven't got
enough data on .ps and .il to provide some evidence with respect to
shared hosting.)

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 18 Aug 2004 09:50:38 -0700

> that you can safely tell an attack of a .ps site from an attack on an

Actually no, the palestinian ISPs are all controlled by Israel.

But the point is that companies with .il or .ps domains do not have to
use domestic ISPs. Most of the Palestinian sites are in .com and are
hosted outside the country but there are not very many of them.

> on the application layer?

It is application layer attacks. You take a .il site, crack it, then
bring up some propaganda pictures on the hacked site. 

> enough data on .ps and .il to provide some evidence with respect to

It isn't really, but the hackers don't much care about collateral 
damage.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 18 Aug 2004 16:58:07 +0000

> How so?  I need a list of the name servers for .DE, and detailed
> routing information is also desirable (including the router
> vendors/software versions that are involved).

without doing any AXFR's, we (www.isc.org/ops/ds) found 3421455 hosts
whose names ended in .DE, under 131905 different second-level domains.

<http://www.isc.org/ops/ds/reports/2004-01/dist-bynum.php> for details.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 18 Aug 2004 18:23:39 +0100

> whose names ended in .DE, under 131905 different second-level domains.

So somewhere around 3% of the zonefile (as .de's are registered at
the second level).

Alex

---

From: Paul Vixie <[email-masked]>
Date: Wed, 18 Aug 2004 19:11:10 +0000

> ...
> so-10-0.hsa1.Raleigh1.Level3.net
> so-0-3-0.bbr1.LosAngeles1.Level3.net
> ...
> Note that there is real information encoded in those names.
> 
> The ability to completely list of all the domain names under, for
> example, Level3.net, would give a tremendous amount of information
> about the structure of their network.  One could gather the same
> information using thousands of traceroutes, or perhaps by a very
> carefully crafted dictionary attack, but the amount of work involved
> would be orders of magnitude greater.

no, it wouldn't be more work.  those names are all trivially discoverable
using PTR lookups of every possible IPv4 address's "inaddr name" given only
a list of level(3) netblocks.  no NSEC is needed.  NSEC would be harder.

observation: we're just hurling pies, 3-stooges-style, until a survey is made.
can we talk about doing a survey rather than trying to create facts out of air?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 18 Aug 2004 21:02:18 +0000

> ...
> Sensitivity to attack rate and false-positive rate can be adjusted by
> tweaking the window size, the color count and the decay timer..
> 
> Popular names can be locked green permanently -- the walk-detector
> will fire quickly enough once you get into dustier parts of the zone.

i love this plan.  it's simple and elegant.

but it won't help me prevent telemarketers from finding out the name and
address of my voip/sip server (along with every other such server in "+1")
and assigning robots to try to get me to change my vote, buy their product,
answer a survey, change my long distance provider, or etc.

got anything that will help the non-dnssec case, where queries need neither
be sequential nor sole-sourced in order to effectively enumerate zones with
well understood allocation schemes?

---

From: kent crispin <[email-masked]>
Date: Tue, 17 Aug 2004 23:14:32 -0700

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

>    probe ranges of IP-adresses, not domainnames.

Whether script kiddies or organized crime, they probe ranges of IP
addresses *precisely* because ranges of IP addressess are trivially
enumerable.  If domain names become trivially enumerable, then they
will probe domain names, which will be more efficient than probing
ranges of IP addresses, plus giving out information that can't be
gleaned from probing IP addresses. 

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: Thu, 19 Aug 2004 16:13:51 +0000

>     Bruce> Proposed solutions to enumeration problems should be
>     Bruce> limited to domains with 'loose' naming schemes (ie, the
>     Bruce> forward zones).
> 
> If the WG finds a solution to zone enumeration for these sorts of
> zones -- and that's a very big if -- I fear someone else will then pop
> out of the woodwork and insist the WG finds a solution that works for
> e164.arpa or ip6.arpa, etc, etc.

i'm sure the WG's (or the IAB's) answer in that case would be "DNS does
not offer privacy, if there's something you don't want publically
searchable, then don't put it in DNS."

(oops.)

---

From: Roy Arends <[email-masked]>
Date: Fri, 20 Aug 2004 16:07:34 +0200 (CEST)

> searchable, then don't put it in DNS."

DNS is a public lookup, not a public search mechanism. DNSSEC introduces
this search capability into the protocol.

Ofcourse this search capability is already available for adversaries (and
honest uses) by using google, reverse space, or available through ISC's
domain survey, and yet, folks want to make it even more easier by not
fixing NSEC.

So, just for fun and profit:

How about a front end for dnssec enabled zones. The cost for the most
recent dataset if $2500 per TLD. An anual subscription is available for
$7250. ;)

(oops.)

---

From: Ben Laurie <[email-masked]>
Date: Sun, 22 Aug 2004 22:09:41 +0100

Paul Vixie wrote:

>>>It won't be too long before some Registry coddles up a nameserver
>>>that detects nsec/other-based enumuration query trends, and starts
>>>dynamically inserting bogus records to lead the attacker through a
>>>twisted trail of normally-non-existent domains (ala web page scripts
>>>that provide lots of bogus email addresses to fill a scrapper's
>>>database with crap).
>>
>>Dynamic insertion of records would require a signing key to be
>>available to all nameservers.
> 
> i don't think that's true.  the DNS I-N-D model is that updates are
> applied at the master server and then trickle down to the slave servers.
> 
> in the BIND9 case, only the master server for a secure zone needs the
> signing key, and the zone would be incrementally re-signed after each
> UPDATE, and the changes would be NOTIFY'd and IXFR'd out to the slaves.
> 
> and as far as i know, BIND9 follows/respects all the relevant standards.
> 
> so, if dynamic bogus name insertion were used as a defense against an
> "enumeration attack", then only the master server would need an online
> signing key.

This would require secondaries to notify the primary of attacks so it 
could start generating the bogus records, then. Probably this would be 
required to detect them, otherwise the attacker would distribute over 
the secondaries. So, OK, I agree - but it would be horribly slow.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Ben Laurie <[email-masked]>
Date: Mon, 23 Aug 2004 13:17:15 +0100

Paul Vixie wrote:
>>could start generating the bogus records, then.
> 
> 
> no.  you're still not seeing the full model.  the slave server who detected
> the attack would start generating dynamic updates toward the master server,
> who would apply them, incrementally resign the zone, and do NOTIFY/IXFR to
> propagate these changes back out to all of the slave servers for the zone.

Ah, I see.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 30 Aug 2004 10:23:57 -0700

> Roy Arends writes:
> > Quickly scan a class B for resolvers, take the bulk (say 2000), and
> > ask them for stuff under gotcha.example.com.
> 
> Why does the IETF condone promiscuous DNS caching?
> 
> I'm reminded of the situation in 1996, when qmail (version 
> 0.91) became
> one of the first MTAs to prohibit relaying by default. People at the
> time didn't realize that relaying was going to be massively abused.

People seem to get very wound up about security, demanding all or
nothing, then being surprised when they end up with nothing.

How much of the protection against DNS spoofing would be provided
by a simple transport layer challenge-response mechanism?

The client sends an authenticatable nonce en-clair along with
the request.

The server returns both the nonce and an HMAC signature of the 
response.

If you can work out a way to know with certainty whether a 
DNS server supports the protocol you have a very robust 
authentication scheme that can only be defeated by a man
in the middle attack.

		Phill