Subject: comments on p-s

From: Samuel Weiler <[email-masked]>
Date: Wed, 21 Sep 2005 12:56:12 -0400 (EDT)

Sorry for getting these out after the last call closed.  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.

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".

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

-- 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 thought p-s was destined for experimental, per the last call.

--------------

3.2 step four.  "do nothing" confuses me.  Does this mean "use the
current value as S(N)"?

3.1 step four, add "in the lest significant (left-most) label"

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.

Lastly, in section 1, item 2: s/owner name/label/, and don't hyphenate
"online signing"

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.

-----------------

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

---

From: Geoffrey Sisson <[email-masked]>
Date: Thu, 22 Sep 2005 09:08:26 +0100 (BST)

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 <[email-masked]> writes:

> Four comments of some substance, the rest is editorial.  None of these
> need block the document.
> 

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

> "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).

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

> what's in the zone?  I think it is, but I haven't convinced myself

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. :)

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

> 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

Done.

>        signing is most likely to be used.

Thanks again.

Geoff