Subject: Re: NSEC+-epsilon (whitelies server) proof of concept.

From: Ben Laurie <[email-masked]>
Date: Mon, 06 Dec 2004 13:52:35 +0000

Olaf M. Kolkman wrote:
> By refusing queries for the
> names that contain the "maximum and minimum sort values" that have
> been inserted in the +-epsilon process, we "weasel" our way out of the
> question if these names are or are not in the zone, the client will
> just never be able to know because of our policy.

I don't understand this - which names do you think might not be in the zone?

-- 
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: Olaf Kolkman <[email-masked]>
Date: Mon, 06 Dec 2004 15:08:07 +0100

Ben Laurie <[email-masked]> writes:
 * Olaf M. Kolkman wrote:
 * > By refusing queries for the
 * > names that contain the "maximum and minimum sort values" that have
 * > been inserted in the +-epsilon process, we "weasel" our way out of the
 * > question if these names are or are not in the zone, the client will
 * > just never be able to know because of our policy.
 * 
 * I don't understand this - which names do you think might not be in the zone?
 * 

At the risk of being to short I refer to
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg02066.html
as the background of this.

Essentially Simon said that those dynamically generated nsec+-epsilon
names are not part of the zone and one is violating the spec by
generating them (and he is correct).

On the other hand I think that this particular sentence in the
specification does not hinder deployment of NSEC+-epsilon. Clients
that try to enforce this part of the specs will never be able to proof
that the spec is violated.

And if they try to you can use the refuse hack that I put in as a
workaround. It is a silly optimization that is I think not needed.

--Olaf
 no hats

---

From: Ben Laurie <[email-masked]>
Date: Mon, 06 Dec 2004 17:42:32 +0000

> workaround. It is a silly optimization that is I think not needed.

I don't understand how clients would use the unhacked version to prove 
the spec violation?

Cheers,

Ben.