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/>