Re: WGLC: draft-ietf-dnsext-nsec3-09

[Roy Arends <[e-mail]>]

Matt Larson wrote on 02/09/2007 09:09:07 PM:

> On Wed, 10 Jan 2007, Olaf Kolkman wrote:
> > Please review the draft and put that fact on record through a post to
> > the mailing-list.
> 
> I have (re-)read the draft and after a thorough review, I support its
> going foward.
> 
> I have only minor comments relating to wording clarity, which are
> below.
>
> > 6.  Opt-Out
> > 
> > [...]
> >    An Opt-Out NSEC3 record is said to cover a delegation if the hash 
of
> >    the delegation's Next Closer Name to its closest provable encloser 
is
> >    between the NSEC3 ownername and next hashed ownername.
> 
> I had some difficulty parsing this sentence.  Once I figured out its
> meaning, I determined the cause of my trouble was the use of the word
> "hash" followed by the word "to" in a sense that did not refer to the
> output of the hash algorithm: "to" here does not refer to what
> something "hashes to".  I believe a minor reordering of the sentence
> might help comprehension:
> 
>      An Opt-Out NSEC3 record is said to cover a delegation if the hash
>      of the Next Closer Name of its closest provable encloser of the
>      delegation is between the NSEC3 ownername and next hashed
>      ownername.

Suresh had similar remarks about this part of the text. I've chanced it 
to:

   An Opt-Out NSEC3 record is said to cover a delegation if the hash of
   the delegation's Owner Name or Next Closer Name is between the NSEC3 
ownername and 
   next hashed ownername.

Since Next Closer Name already implies "Closest Provable Encloser" (by 
definition, see the terminology section), I've left it out.

> But maybe I'm the only one with a problem here, which is entirely
> possible.
> 
> >    An Opt-Out NSEC3 record MAY have the same original owner name as an
> >    insecure delegation.  In this case, the delegation is proven 
insecure
> >    by the lack of a DS bit in type map and the signed NSEC3 record 
does
>                                ^ the
> >    assert the existence of the delegation.

fixed.

> 
> I know the word MAY appears in big letters here, but would it be worth
> a clarification sentence explaining that NSEC3 records at insecure
> delegations are not necessary in Opt-Out zones and that if one's
> purpose for using Opt-Out is to reduce zone size, this case is
> expected to be unusual?  I'm just thinking of a signer implementor
> coming along in a few years who's not steeped in the material as we
> all are and trying to figure things out from the RFC as a starting
> point.

In an Opt-Out zone, when the security status of a delegation goes from 
signed to unsigned, it is trivial for the administrator to revoke the DS 
record, and ammend the appropriate NSEC3 record. It might be less trivial 
to remove the specific hashed name from the NSEC3-chain of hashed names. 
So it might not be that unusual.

> > 7.2.2.  Name Error Responses
> > 
> >    To prove the nonexistence of QNAME a closest encloser proof and an
> >    NSEC3 RRset covering the wildcard record at the closest encloser 
MUST
>                              ^ (nonexistent)
> >    be included in the response.
> 
> I think adding "(nonexistent)" increases clarity.

I agree. I've added '(nonexistent)'.

> 
> > 7.2.7.  Referrals to Unsigned Subzones
> > 
> > [...]
> >    If the zone in Opt-Out, then there may not be an NSEC3 record
> 
> s/in/is

Fixed.

> 
> > 7.5.  Dynamic Update
> > 
> >    A zone signed using NSEC3 may accept dynamic updates.  [...]
> 
> Should there be an informative reference to RFC 2136 here?

I've added a reference to 2136. 

> 
> > 8.1.  Responses with Unknown Hash Types
> > 
> >    A validator MUST ignore NSEC3 records with unknown hash types.  The
> >    practical result of this is that responses containing such NSEC3
>                                                           ^ only
> >    records will generally be considered bogus.
> 
> If a response contains a combination of NSEC3 records with known and
> unknown hash types, the validator ignores the ones with unknown types
> and can proceed using the ones with known types, right?  If so, adding
> "only" above helps make that more clear.

Absolutely ! Fixed !
 
> > 8.3.  Closest Encloser Proof
> > 
> > [...]
> >    3.  Truncate SNAME by one label, go to step 2.
> > 
> >    Once the closest encloser has been discovered, the validator MUST
> >    check that the NSEC3 that has the closest encloser as an ownername 
is
>                                                              ^ original
> >    from the proper zone.
> 
> I think adding "original" increases clarity.

I agree. Fixed.

> 
> > 8.5.  Validating No Data Responses, QTYPE is not DS
> > 
> >    The validator MUST verify that an NSEC3 RR that matches QNAME is
> >    present and that both the QTYPE and the CNAME type are not set in 
its
> >    Type Bit Maps field.
> > 
> >    Note that this test also covers the case where the NSEC3 record
> >    exists because it corresponds to an empty non-terminal, in which 
case
> >    the NSEC3 will usually have an empty Type Bit Maps field.
> 
> Why "usually" and not "always"?  Won't an empty non-terminal's NSEC3
> always have an empty Type Bit Maps field?

Ack. I removed the word 'usually', but did not add 'always'.
 
> > 10.1.  Domain Name Length Restrictions
> > 
> >    Zones signed using this specification have additional domain name
> >    length restrictions imposed upon them.  In particular, zone with
>                                                                 ^ s
> >    names that, when converted into hashed ownernames, exceed the 255
> >    octet length limit imposed by RFC 1035 [3].
> 
> i.e., s/zone/zones

Fixed.

Thanks for the review Matt !

Roy

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