Subject: hopefully was RE: dictionary attack on nameservers

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.

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