Re: draft-arends-dnsnr-00
Roy Arends <roy@dnss.ec> Wed, 28 July 2004 07:52 UTC
Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11959 for <dnsext-archive@lists.ietf.org>; Wed, 28 Jul 2004 03:52:04 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bpj8B-0001Ag-O6 for namedroppers-data@psg.com; Wed, 28 Jul 2004 07:45:43 +0000
Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bpj8A-0001AB-1l for namedroppers@ops.ietf.org; Wed, 28 Jul 2004 07:45:42 +0000
Received: by mail.schlyter.se (Postfix, from userid 2038) id 80239AC8D; Wed, 28 Jul 2004 09:45:39 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 7469EAC8B; Wed, 28 Jul 2004 09:45:39 +0200 (CEST)
Date: Wed, 28 Jul 2004 09:45:39 +0200
From: Roy Arends <roy@dnss.ec>
X-X-Sender: roy@trinitario.schlyter.se
To: Samuel Weiler <weiler@tislabs.com>
Cc: namedroppers@ops.ietf.org
Subject: Re: draft-arends-dnsnr-00
In-Reply-To: <Pine.GSO.4.55.0407271447030.16911@filbert>
Message-ID: <Pine.BSO.4.56.0407280912300.11025@trinitario.schlyter.se>
References: <Pine.BSO.4.56.0407121709550.12231@trinitario.schlyter.se> <Pine.GSO.4.55.0407271136500.5963@filbert> <Pine.BSO.4.56.0407271741320.11200@trinitario.schlyter.se> <Pine.GSO.4.55.0407271447030.16911@filbert>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,OPT_IN autolearn=ham version=2.63
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
On Tue, 27 Jul 2004, Samuel Weiler wrote: > Thanks for the clarifications. And thanks for your note on Monday > comparing NSEC2 and NSEC3. I'm looking forward to reading -01. > > Perhaps the reason I was confused starts with this line in Section 2: > > The DNSNR resource record lists RR types present at the DNSNR RR's > ownername. Ah yes, I tried to generalise. I will rewrite that. > If the DNSNR owner name is a hash, this isn't quite true. And this > line in 2.1.4: > > The value of the Next Owner Name field in the > last DNSNR record in the zone is the name of the zone apex (the > ownername of the zone's SOA RR). > > Which implies that you're retaining the old (non-hashed) canonical > ordering. Yes. The paragraph you are referring to starts with "If the Hash Function Field has value 0,", which means that the ownernames of the NSEC3 records are not hashed. > Perhaps this doc needs the same thing I suggested for > NSEC2, a high-level description of what's changing. It needs to be > very, very explicit that you may or may not have NSEC3's at the same > names as other records. Okay. > Like his doc, there needs to be a discussion > of what happens when the salt or hash algorithms change. The revision will be similar to dnssec-bis-proto o Zone signing - Including NSEC3 RRs in a Zone - Example of a Secure Zone o Serving - Including NSEC3 RRs In a Response - Example DNSSEC-ter Responses o Resolving - Response Caching o Authenticating DNS Responses - Authenticated Denial of Existence - Authentication Example > > Per-span, I'll make that clear. > > You need to be explicit, then, that it's per-span in the (possibly) > hashed namespace, which means the names covered by a single NSEC3 will > vary depending on the hash algorithm and salt chosen. If you have > some spans opt-in and some opt-out, this means the names in the > "protected" space will vary depending on the salt and hash algorithm. > This is a very interesting property, though it makes my head spin. My apologies, it is Per-Zone. Per-span does not work. Due to the pre-image resistence of hash-functions it would be hard to augur which span covers what qname, therefor the property needs to be applied to all NSEC3 in a zone, not independantly. Plain ownernames (as opposed to hashed owner names) do not have pre-image resistance, so the requirement could be relaxed here, but then this proposal becomes very complex. I'll make it explicitly "Per-Zone". > Thinking about "perfect hash functions" from the land of data > structures is leading me to wonder if one can create a hash algorithm > and salt such that you can force a set of names (ie. all of the > unsecured delegations in your zone) to be in one span, so you can mark > only that one span as opt-in yet secure the rest of the zone. This is very hard, due to the same issues as I've written above. A workaround can be to query twice, but that is very ugly. It is far more easy to declare it per-zone and be done with. If that would impose irreconcilable constraints to a security policy, then the alternative would be to not use it at all. > > > Also, the presentation format of the hash value is inconsistent > > > between 2.1.2 (third paragraph) and 2.2. > > > > I don't see that, could you give me a pointer ? > > I think I misread this the first time, and then I didn't even > correctly describe the problem I thought I saw. (I thought 2.1.2 > said the salt was presented in base32.) In any case, the third > paragraph of 2.1.2 is still unclear. It reads as: > > ... the hash function .... is presented by a base32 value. > > I think you mean that the owner name and next owner name fields are in > base32, but that's not what the sentence says. (Since the hash > function field is an unsigned integer, per 2.2.) Ah, thanks. Will fix. > Again, I'm looking forward to seeing the next version. I'd also > really like to see a discussion of wildcard handling, as Ben > suggested. The wildcard handling in Bens draft is needed because NSEC2 obscures empty-non-terminals, and therefor introduces EXIST. That makes handling of wildcards different then current NSEC. NSEC3 handles wildcard exactly as NSEC does, since empty non-terminals are not obscured. I will put in a note saying that, but I do not see the purpose of discussing wildcard handling when it is exactly as NSEC. Roy -- 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: draft-arends-dnsnr-00 Roy Arends
- Re: draft-arends-dnsnr-00 Samuel Weiler
- Re: draft-arends-dnsnr-00 Roy Arends
- Re: draft-arends-dnsnr-00 Roy Arends
- Re: draft-arends-dnsnr-00 Samuel Weiler
- Re: draft-arends-dnsnr-00 Edward Lewis
- Re: draft-arends-dnsnr-00 Ben Laurie
- Re: draft-arends-dnsnr-00 Roy Arends
- Re: draft-arends-dnsnr-00 Roy Arends