Re: NSEC+-epsilon (whitelies server) proof of concept.
Alex Bligh <alex@alex.org.uk> Mon, 29 November 2004 12:48 UTC
Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14468 for <dnsext-archive@lists.ietf.org>; Mon, 29 Nov 2004 07:48:04 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CYksv-000MKO-VZ for namedroppers-data@psg.com; Mon, 29 Nov 2004 12:44:05 +0000
Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CYksu-000MK7-Rp for namedroppers@ops.ietf.org; Mon, 29 Nov 2004 12:44:05 +0000
Received: from [192.168.0.4] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 4558BC2DA7; Mon, 29 Nov 2004 12:44:03 +0000 (GMT)
Date: Mon, 29 Nov 2004 12:43:58 +0000
From: Alex Bligh <alex@alex.org.uk>
Reply-To: Alex Bligh <alex@alex.org.uk>
To: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org
Cc: Alex Bligh <alex@alex.org.uk>
Subject: Re: NSEC+-epsilon (whitelies server) proof of concept.
Message-ID: <513CFCA5C6BDE3F95E79B2F5@[192.168.100.25]>
In-Reply-To: <20041129122915.0c621b43.olaf@ripe.net>
References: <20041129122915.0c621b43.olaf@ripe.net>
X-Mailer: Mulberry/3.1.5 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit
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" <olaf@ripe.net> 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. 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). 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, understand and debug. 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. 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. 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. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- Re: NSEC+-epsilon (whitelies server) proof of con… Alex Bligh
- Re: NSEC+-epsilon (whitelies server) proof of con… Olaf M. Kolkman
- Re: NSEC+-epsilon (whitelies server) proof of con… Geoffrey Sisson