Subject: Re: NSEC3 chain walking

From: Ben Laurie <[email-masked]>
Date: Tue, 01 Nov 2005 16:35:44 +0000

Peter Koch wrote:
> Ben Laurie wrote:
> 
>> We decided in
>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signed-nonexistence-req
>> uirements-02.txt
>> that it was "nice to have" and not an actual requirement.
> 
> not to question your assessment in this case, but the message should
> probably be that "we" (be that the editors or the WG) should be careful
> about other people's requirements, especially if they are crucial for a
> deployment success.

This was on the basis that no-one said it was their requirement.

> It might be quite easy to get feedback from TLD registries, but there are
> other DNS operators who may not have made their mind and, if they do, might
> disagree with the above categorization (as "nice to have").

True. However, given that we have established the impossibility of
satisfying all plausible requirements we are obliged to choose amongst
them, are we not?

I'd also note that it is not generally required of WGs that they should
attempt to achieve consensus with non-participants!

> When it comes to "zone size" and "zone enumeration", it's also important
> to view the first order differential, i.e. dies NSEC++ make it easier (than
> pre-DNSSEC DNS) to find the [number of] changes applied to zone?
> (This is not to introduce new hurdles, just completeness of the requirements
> list).

Surely the appropriate differential is against NSEC in this case, since
NSEC3 is not designed to solve this particular problem, so the
requirement is surely to not make it worse than NSEC, if possible, and
if anyone cares at all.

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: Alex Bligh <[email-masked]>
Date: Tue, 01 Nov 2005 18:20:30 +0000

--On 01 November 2005 16:45 +0100 Peter Koch <[email-masked]> wrote:

> to view the first order differential, i.e. dies NSEC++ make it easier
> (than pre-DNSSEC DNS) to find the [number of] changes applied to zone?

I'm pretty sure that a bit of relatively trivial maths based on NSEC
results from a relatively small number of random queries
(O(log(zonesize))will give you a relatively accurate zone size estimate,
and from there to a first differential is merely a case of repeating the
process several times.

That said, I think /any/ NSEC variant with a finite number of possible
denials (or at least a finite number of denials that is in some manner
linked to the number of zone entries) will suffer the same 'problem'
to a greater or lesser extent. Including double hashes, etc.

The only way of completely solving this that I'm aware of would be the
white-lies method plus epsilons which in essence means online signing.

An advantage to supporting multiple hash types is that it would be
possible to introduce a certain amount of bogosity into the hash
space (deliberately giving non-rectangularly distributed hash functions
which are still unique, e.g. by truncating the hash then duplicating
a random number of bits). This would make evaluation of zone size
mildly less trivial, though not (I fear) much less trivial if you
are looking for broad estimates over time. I think it would be waste
of time & effort to do this (interesting mathematically as it might be)

With my ccTLD hat on, I can't see many TLD operators caring too much given
most of them publish this information anyhow. The ones that don't tend to
have very small zones where artificially increasing the number of zone
entries by inserting random NULL records is going to be a trivial thing to
do in resource terms. Those that want to pretend claim zones are smaller
can always claim they HAVE stuffed the zone with NULL records when they
haven't. Given the zones can't be walked, this would seem not to be
disprovable :-)

Alex

---

From: Paul Vixie <[email-masked]>
Date: Tue, 01 Nov 2005 19:25:54 +0000

# not to question your assessment in this case, but the message should
# probably be that "we" (be that the editors or the WG) should be careful
# about other people's requirements, especially if they are crucial for a
# deployment success.

indeed, everyone who came forward when DNSSEC and DNSSEC-bis were planned
said that enumeration was an evil they could live with.  then things changed.
apparently, the people who would later on care very much, were not asked.
(that's the loop i'm hoping we find a way to break out of.)