Subject: Re: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag)

From: Ben Laurie <[email-masked]>
Date: Tue, 01 Jun 2004 11:14:49 +0100

Edward Lewis wrote:

> At 12:41 -0700 5/28/04, Hallam-Baker, Phillip wrote:
> 
>> Could we maybe as a compromise agree now that the only difference
>> between v1 and v2 will be that in v2 a new versioned NSEC
>> record would be used?
> 
> 
> I don't think there's been an agreement that there ought to be an answer 
> to zone enumeration.  I've been analyzing the possibility of 1) allowing 
> there to be a way forward and 2) adoption of the NSEC2 proposal in case 
> we decided this is to be pursued.
> 
> I'm not convinced that we need to defend against zone enumeration. I'm 
> all for providing this if it were easy to accomplish.
> 
> I have yet to see a way to provide a seamless way to convert from NSEC 
> to another approach to authenticated denial (for any purpose). (Hmmm, 
> perhaps detailing what happens if the NSEC claims that it itself doesn't 
> exist - but that's been tried before and failed.)
> 
> I think that the NSEC2 is capable of obfuscating the zone's contents, 
> but can do so only at a greater cost.  This cost can be gamed by the 
> client and has the potential to be rather high.
> 
> I'd put my opinions this way - if providing a way forward were easy 
> and/or if providing obfuscation was cheap to do, I'd be for it.  But 
> from the work I've done, the costs to do either seem to be rather high, 
> meaning that there has to be a lot of need to provide them.

The cost you refer to is extra data in negative DNS responses, correct? 
But these are only incurred in zones which include labels of the form 
a.b. In the kind of zone we're talking about (.co.uk) there are no such 
labels, so the overhead comes down to the extra data size rather than 
many extra records, as seen in your examples.

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

--
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, 1 Jun 2004 11:53:58 -0400

At 13:02 +0100 5/31/04, Roy Badami wrote:
>>>>>>  "Edward" == Edward Lewis <[email-masked]> writes:
>
>     Edward> (Hmmm, perhaps detailing what happens if the NSEC claims
>     Edward> that it itself doesn't exist - but that's been tried
>     Edward> before and failed.)
>
>As far as I can see the current document set _does_ detail what
>happens in this case.
>
>-protocol 5.4:
>
>    Since a validated NSEC RR proves the existence of both itself and
>    its corresponding RRSIG RR, a validator MUST ignore the settings of
>    the NSEC and RRSIG bits in an NSEC RR.
>
>    -roy

Okay.

That eliminates the use of insane NSEC RR's as a migration strategy. 
Not that it was all that promising.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 Jun 2004 12:05:54 -0400

At 11:14 +0100 6/1/04, Ben Laurie wrote:
>The cost you refer to is extra data in negative DNS responses, correct? But
>these are only incurred in zones which include labels of the form a.b. In the
>kind of zone we're talking about (.co.uk) there are no such labels, so the
>overhead comes down to the extra data size rather than many extra records, as
>seen in your examples.

The cost, as far as the server is concerned, is the computation of 
hashes and the larger response.  (Ditto for the client too.)

But the cost isn't limited to any kind of zones.  No matter what the 
"shape" of the zone is, a mischievous client can construct a query 
that force the server into computing hashes of N names.  E.g., let's 
say 9.net doesn't exist.  I can ask for 1.2.3.4.5.6.7.8.9.9.net and 
the net. servers would need to calculate 11 hashes to answer.  If the 
client asks for 1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.7.8.9.9.net the server 
now needs to do 20 hashes.

My concern is that the client determines the load.

Even if the zone is like ip6.arpa, no matter what the existing 
delegations look like, I can always game the queries to induce the 
server into a lot of computing cycles.

And then there's the answer size issue.

In the example above, if I compute 20 hashes, I may need to send 20 
NSEC2's and 20 RRSIGs.  But I could do better - if hashes fall into 
shared ranges.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer