Subject: RE: dictionary attack on nameservers

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

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

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.

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

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.

--
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: Edward Lewis <[email-masked]>
Date: Tue, 17 Aug 2004 12:03:27 -0400

As a bystander to this thread, my reaction has been largely "so 
what?"  As a protocol analyst, I don't care how motivated or how 
efficient the attacker is.  All I care to do is see if I can remove 
the offending feature.

My question remains:
     Is there a way to prove the non-existence of a name without
         - exposing any of the contents of the zone?
         - muddying up the name space with fake names or data sets?
         - on-line cryptographic operations?
         - being vulnerable to replay attacks of the negative answer?

If there were a way to avoid all four, that'd be the answer.  NSEC 
avoids 3 of 4 of them (that's better than Meatloaf's declaration "2 
out of 3 ain't bad").  Other approaches avoid a different 3 of 4.

Note that "- a change to the protocol" isn't on my list.  That's 
important too, but it's an institutional issue (IETF) not a physics 
(protocol) issue.  If we can't get the physics right, we ain't going 
to get the institution right.

(I suppose I should wait until the requirements come out before 
asking if there's a 4 of 4 solution.  But, once the requirements do - 
that's what I'll be looking for.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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

---

From: Ben Laurie <[email-masked]>
Date: Sun, 22 Aug 2004 12:52:06 +0100

Edward Lewis wrote:

> As a bystander to this thread, my reaction has been largely "so what?"  
> As a protocol analyst, I don't care how motivated or how efficient the 
> attacker is.  All I care to do is see if I can remove the offending 
> feature.
> 
> My question remains:
> avoids 3 of 4 of them (that's better than Meatloaf's declaration "2 out 
> of 3 ain't bad").  Other approaches avoid a different 3 of 4.

I presume you're suggesting that NSEC2 fails on "muddying up the name 
space" - if so, I don't really understand why, and if not, where does it 
fail?

> (protocol) issue.  If we can't get the physics right, we ain't going to 
> get the institution right.
> 
> (I suppose I should wait until the requirements come out before asking 
> if there's a 4 of 4 solution.  But, once the requirements do - that's 
> what I'll be looking for.)

Absolutely.

Cheers,

Ben.

-- 
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: Edward Lewis <[email-masked]>
Date: Mon, 23 Aug 2004 08:43:41 -0400

At 12:52 +0100 8/22/04, Ben Laurie wrote:

>I presume you're suggesting that NSEC2 fails on "muddying up the name space" -
>if so, I don't really understand why, and if not, where does it fail?

Yes, for one NSEC2 removes "empty non-terminals" from the lexicon via 
the EXIST record.

I need to go back to my notes on NSEC2 to check something 
out[0]...but I'm a bit reluctant to go forward until we have 
requirements on the table.  I have yet another approach in mind, but 
it's not worth discussing approaches unless it's clear what we are 
solving.

[0] - Yeah, that's a case of the old "hollow threat."  Does NSEC2 
really hide names given that to answer negatively, I need to reveal 
there's no applicable wild card record?  The issue is that to show 
that if there's no wild card, I have to reveal where it would have 
been - usually at the already obvious apex, but sometimes at another 
name.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Ben Laurie <[email-masked]>
Date: Mon, 23 Aug 2004 16:42:18 +0100

Edward Lewis wrote:

>> space" -
> I need to go back to my notes on NSEC2 to check something out[0]...but 
> I'm a bit reluctant to go forward until we have requirements on the 
> table.  I have yet another approach in mind, but it's not worth 
> discussing approaches unless it's clear what we are solving.
> 
> [0] - Yeah, that's a case of the old "hollow threat."  Does NSEC2 really 
> hide names given that to answer negatively, I need to reveal there's no 
> applicable wild card record?  The issue is that to show that if there's 
> no wild card, I have to reveal where it would have been - usually at the 
> already obvious apex, but sometimes at another name.

Sure, but if I have queried for a.b.c.d, then you have to reveal b.c.d - 
which I could have checked with a single extra query, or in general with 
a small number of extra queries (one per component), so this isn't 
really a massive hole.

Cheers,

Ben.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Aug 2004 17:21:03 -0400

At 16:42 +0100 8/23/04, Ben Laurie wrote:
>Sure, but if I have queried for a.b.c.d, then you have to reveal b.c.d - which
>I could have checked with a single extra query, or in general with a small
>number of extra queries (one per component), so this isn't really a massive
>hole.

This is an example of what needs to be explained in a requirements document.

I know that at one time I wrote that in order to securely deny that 
there is an answer to a query, you must (as in "have to") reveal the 
closest enclosing name of the query's name.  (Rationale - you must 
prove the name desired is absent as well as the *.closest encloser.)

So, apparently leaking the closest encloser is not part of the zone 
enumeration problem.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Aug 2004 17:22:04 -0400

>So, apparently leaking the closest encloser is not part of the zone

Yes, I know I owe the wild card clarify draft, which will define 
"closest encloser." ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer