Re: comments on p-s
Geoffrey Sisson <geoff@nominet.org.uk> Thu, 22 September 2005 08:13 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIMCv-0008GC-7V for dnsext-archive@megatron.ietf.org; Thu, 22 Sep 2005 04:13:30 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14049 for <dnsext-archive@lists.ietf.org>; Thu, 22 Sep 2005 04:13:27 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIM87-000O8h-99 for namedroppers-data@psg.com; Thu, 22 Sep 2005 08:08:31 +0000
Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIM84-000O8A-Pa for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 08:08:29 +0000
Received: from staff.nominet.org.uk ([213.248.199.129]) by mx3.nominet.org.uk with ESMTP; 22 Sep 2005 09:08:27 +0100
X-IronPort-AV: i="3.97,135,1125874800"; d="scan'208"; a="1298119:sNHT23978636"
Received: (from geoff@localhost) by staff.nominet.org.uk (8.12.9/8.12.9) id j8M88Q2K018623 for namedroppers@ops.ietf.org; Thu, 22 Sep 2005 09:08:26 +0100 (BST)
Date: Thu, 22 Sep 2005 09:08:26 +0100
From: Geoffrey Sisson <geoff@nominet.org.uk>
Message-Id: <200509220808.j8M88Q2K018623@staff.nominet.org.uk>
To: namedroppers@ops.ietf.org
Subject: Re: comments on p-s
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Hi Sam Thanks for the thorough review; A revised (pre-submitted) draft is available at: http://www.panix.com/~geoff/draft-ietf-dnsext-dns-name-p-s-01pre1.txt An rfcdiff of -00 to -01pre1 is available at: http://www.panix.com/~geoff/draft-ietf-dnsext-dns-name-p-s-01pre1-from-00.diff.html Comments inline: Samuel Weiler <weiler@tislabs.com> writes: > Four comments of some substance, the rest is editorial. None of these > need block the document. > > -- Add a specific reminder in section 5 that before using the output > of P and P' in an NSEC RR, the server needs to test for that name's > existence and possibly use a non-synthesized NSEC RR. Refer to > online-signing section 2. Thanks, good catch. I've added the following text: ------------------------ Begin included text ------------------------ 4.1. Test for Existence Before using the result of P(N) or P'(N) as the owner name of an NSEC RR in a DNS response, a name server should test to see whether the name exists. If it does, either a standard non-synthesised NSEC RR should be used, or the synthesised NSEC RR should reflect the RRset types that exist at the NSEC RR's owner name in the Type Bit Map field as specified by Section 4.1.2 of [RFC4034]. Implementors will likely find it simpler to use a non-synthesised NSEC RR. For further details see Section 2 of [I-D.ietf-dnsext-dnssec-online-signing]. ------------------------- End included text ------------------------- BTW should `must' be `MUST' in this sentence from online-signing? ------------------------ Begin included text ------------------------ Before answering a query with these records, an authoritative server must test for the existence of names between these endpoints. ------------------------- End included text ------------------------- > This could really be clarified in P'(N) Step 2, which needs to say > "Use the apex NSEC RR" or at least "this is the name of the zone". I've added this text to Step 2 of P'(N): ------------------------ Begin included text ------------------------ (If this condition is met, P'(N) is the owner name of the apex.) ------------------------- End included text ------------------------- . . . and have also added equivalent text to Step 2 of P(N). > -- In Sections 3 & 4, I kept wondering where the maximum label/name > lengths were defined. 5.4.1 mentions total name length only. > Suggestion: To make it easier for the reader, add, in 3 or 5.4.1: > As a reminder, the maximum DNS label length (as defined in > [RFC1034] Section 3.1) is 63 octets and the maximum total name > length is 255 octets. > I first wondered about this in section 3.1, step 1. I've added the following text to the (now unified) introduction to the derivations: ------------------------ Begin included text ------------------------ The derivations make reference to maximum label length and maximum DNS name length; these are defined in Section 3.1 of [RFC1034] to be 63 and 255 octets respectively. ------------------------- End included text ------------------------- > -- Are you certain that P' and S' (section 4) handle arbitrary > queries, noting that an attacker can send any query, independent of > what's in the zone? I think it is, but I haven't convinced myself > yet. I've tested it pretty thourougly, but I think I will subject it to additional testing in view of the pointed nature of this question. :) > -------------- > > 3.2 step four. "do nothing" confuses me. Does this mean "use the > current value as S(N)"? It means make no changes to the value of N. I've changed it to: ------------------------ Begin included text ------------------------ 4. Remove the least significant (left-most) label. Unless N is the same as the owner name of the zone apex (this will occur only if N is the maximum possible name in canonical DNS name order, and thus has wrapped to the owner name of zone apex), repeat starting at step 2. ------------------------- End included text ------------------------- This removes the awkward "do nothing", though at the expense of creating a slightly over-long sentence. Note that in this doc, N has been overloaded to mean: 1. The value of the input. 2. The variable whose value changes (or persists) as successive steps of a derivation are applied. I don't think this is more confusing than any other method of expression, short of using pseudo code. (I was initially tempted to use pseudo-code, but this is broadly discouraged by http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt) > 3.1 step four, add "in the lest significant (left-most) label" Done (with a minor variation); this is the new text: ------------------------ Begin included text ------------------------ 4. Decrement the value of the least significant (right-most) octet of the least significant (left-most) label, skipping any values that correspond to uppercase US-ASCII letters, and then append the least significant label with as many octets as possible of the maximum sort value. Continue to the next step. ------------------------- End included text ------------------------- > 3.2 step two, s/"If N is one or more"/"If N is one"/, since "or more" > should have been taken care of by step one. Done. > Lastly, in section 1, item 2: s/owner name/label/, This is the new text: ------------------------ Begin included text ------------------------ 2. A ``modified method'', which returns a predecessor and successor which are more economical in size and computation. This method is restricted to use with zones consisting exclusively of owner names that contain no more than one label more than the owner name of the apex, where the longest possible owner name (i.e. one with a maximum length left-most label) would not exceed the maximum DNS name length. This is, however, the type of zone for which the technique of online signing is most likely to be used. ------------------------- End included text ------------------------- > and don't hyphenate > "online signing" Done. > OLD: This method > is restricted to use with zones consisting only of single-label > owner names where a maximum-length owner name would not result > in a DNS name exceeding the maximum DNS name length. This is, > however, the type of zone for which the technique of online- > signing is most likely to be used. > > NEW: This method > is restricted to use with zones consisting only of single-label > owner names where a maximum-length label would not result > in a DNS name exceeding the maximum DNS name length. This is, > however, the type of zone for which the technique of online > signing is most likely to be used. Thanks again. Geoff -- 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: comments on p-s Geoffrey Sisson