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

["Olaf M. Kolkman" <[e-mail]>]

Alex,

I think we agree, comments in-line

--Olaf


On Mon, 29 Nov 2004 12:43:58 +0000
Alex Bligh <[e-mail]> wrote:

> Olaf,
> 
> Apologies for replying without reading the perl first, but I am
> trying to understand your thinking here
> 
> --On 29 November 2004 12:29 +0100 "Olaf M. Kolkman" <[e-mail]> wrote:
> 
> > When the proxy receives a query it will return a "REFUSE" if the query
> > name contains "\000" or "\255" in one of its labels.
> 
> I am presuming you *do* in fact mean "\000" or "\255" *in* any one
> of its labels, not "\000" or "\255" *as* any one of its labels.
>

Acknowledged.

> If so, then this is a pragmatic rather than a purist approach (that isn't a
> criticism, that's an observation), as it effectively prevents any existing
> labels with "\000" or "\255" in from working (obviously)

I have taken the "REFUSE" approach more to proof that one can never
"proof" that the generated owner names are not in the zone, which is
AFAIK the only objection against this scheme. I honestly think that
the client side does not care about that language in the specs. 



> But if that's the
> case, i.e. if one is prepared to consider certain octet values as reserved
> (and thus unavailable for the raw zone file), then I think it's possible to
> construct far more simple successor and predecessor functions than those in
> draft-sisson-dnsext-dns-name-p-s, (especially if one enforces one octet
> stricter length restrictions) which are much simpler to code,

Well.. eh this code is pretty simple :-) ....

> understand
> and debug. 

Absolutely correct !!!! I am not saying this is the final product. I think
we can do a lot on optimization.

> For instance, in terms of successor functions, if one limits the
> function's domain[*] to labels not containing \000 and \255, less than 63
> (not 64) octets, and with a similar change to the total name length
> restriction, then one could define the successor function as simply
> concatenating "\000" to the label. The result of the successor function is
> not going to need a successor itself, as you'll be returning REFUSE as the
> QNAME had a \000 in a label.

Correct, Geoffry has documented this in his next version.

> All the complexity in draft-sisson-dnsext-dns-name-p-s is because it needs
> to support all possible values in the "original" zonefile (i.e. all legal
> domain[*].
> 
> [* = 'domain' in the mathematical sense, i.e. set of legal input values
> to a function - terminological overload - arrrgghh ]
> 
> > This policy is
> > not strictly needed but it is to address the issue that the the NSEC
> > next name should be part of the zone.  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.
> 
> Yes-ish. I think you can generalize that concept as follows:
> 
> If it is permissible to place further restrictions on valid label names by
> a set of rules (X), then by defining the successor/predecessor functions
> S', P' as ones which for any input value compliant with rules (X) generate
> a near successor/predecessor which are not compliant with rule (X), and
> refusing queries for QNAMEs breaching rule (X), we avoid the wildcard /
> existence problem.
> 
> I am not ENTIRELY sure your approach conforms to the above for all
> cases (I am thinking of maximal DNS length) in that I think the
> successor might under certain circumstances not have a \000 or \255 in
> it. From the draft:
> 
>    DNS name is the maximum DNS name length:
> 
>       y  = fooooooooooooooooooooooooooooooooooooooooooooooooo.ooooooooo\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooooo\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.o\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\
>            oo.example.com.
> 
>       y' = foooooooooooooooooooooooooooooooooooooooooooooooop.ooooooooo\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooooo\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.o\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\
>            oo.example.com.
> 
> which does not have a \000 or a \255 in it. You can solve that trivially
> by putting a one lower limit of maximum DNS name length in the input
> zone.

Ack.. that may be a cornercase.

> 
> I note that for the purists, names with \000 and \255 in labels,
> and (I think) labels between epsilon and delta, are restricted in
> their use (i.e. either must not exist or it cannot be shown securely
> either that they do or don't exist). I do not think that is a practical
> issue for most users.
> 

I think they can exist, they are just not obfuscated (and my
"stripper" script would need a patch too :-) ).


If we were to drop the refuse on the "\255" and the "\000" match I think 
I would still refuse on queries for the "NULL" RRs itself, as these do 
simply not exist, while we have NSEC RRs that can "proof" their existence.

There is still some corner case for direct NSEC queries for owner
names dname+epsilon, but have not been able to word that.

On the other hand I can not think of a query that would result in an
NSEC RR that can be used to deny existing data.

--Olaf


PS. I will remove the "REFUSE" on '\000' and '\255' in a day or two. Please
remind me if you found this "not-done".


---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>