Subject: RE: dictionary attack on nameservers

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

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.

--
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: 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: Alex Bligh <[email-masked]>
Date: Sat, 07 Aug 2004 10:54:10 +0100

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

> verisign.com.

If there is an enterprise requirement for non-enumerability it would
be useful if this was more widely understood as this has previously
been seen as an issue for (some) TLDs.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Sat, 07 Aug 2004 10:56:58 +0100

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

> your acceptance that the name is public. You've published it.

Seems to me there is a qualitative difference between publishing the node
(with RRs), which is expected behaviour, and publishing an index of all
nodes (which has not historically been expected behaviour for those
disabling AXFR).

I don't claim to be qualified to pontificate as to whether that affects
enterprise security, but the two seem to me to be different things, and
hence I can see why they might have different results.

Alex

---

From: George Michaelson <[email-masked]>
Date: Mon, 9 Aug 2004 12:54:06 +1000

I found the presentation on the dictionary attack very useful to stimulate thinking
about the implications.

If the 'pre DNSSEC' baseline is as high as 10-20% available by simple attack, then
it does bring into question the benefit of limiting the walk. Thats a significant
weakness in the current deployed base. You can take the other side, and say there
is potential for a benefit in deploying DNSSEC of course, but the view right now
is 'at least do no more harm' and I would say, when 20%+ is visible at a low cost
then the protection cost may be higher than the benefit. (I am assuming that
more clever attacks will emerge, so the high end counts get higher)

In reverse of course, we have such a deterministic namespace that there is no
meaningful protection against 'reverse IP dictionary attack' except perhaps in
V6. -And I suspect this also provides significant entrypoints into the forward
namespaces, since names in reverse can act as dictionary-attack pump-priming
values to feed into the forward space.

cheers
	-George

---

From: Ben Laurie <[email-masked]>
Date: Fri, 13 Aug 2004 12:03:47 +0100

> success rate. This data is hard evidence that a dictionary attack is

That is, indeed, hard data - but it is not what I was responding to.

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