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

From: "John Dickinson" <[email-masked]>
Date: Tue, 30 Jan 2007 15:48:48 +0000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Olaf M. Kolkman wrote:

> 
> Dear Colleagues,
> 
> 
> You may well have seen the release of draft-ietf-dnsext-nsec3-09.
> 
> With the release of this draft, so have the chairs been informed, the
> issue list is cleaned up and the work is seen as sufficient quality
> to be forwarded to the IESG. Hence, this message opens up a last call
> for "DNSSEC Hashed Authenticated Denial of Existence". The last call
> will terminate Sunday February 11 around 23:00 HST.
> 
> Please review the draft and put that fact on record through a post to
> the mailing-list. If there are any new issues please bring them
> forward. If old issues have been closed unsatisfactory feel fee to
> make note of those but do not expect old discussions to be rehashed.

I have reviewed the nsec3 draft and support it going forward. 

I minor typo in addition to those raised by Wouter
Page 47 B 6
The query returned an NSEC3 RR that show that the requested was
The query returned an NSEC3 RR showing that the request was

John

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 5 Feb 2007 12:13:15 +0100

> You may well have seen the release of draft-ietf-dnsext-nsec3-09.

I have implemented the RRs in perl's Net::DNS::SEC library (not  
released yet) and note that the specification is clear enough to  
provide wire compatibility. Besides, the hashing algorithm, with its  
salt and iterations are clearly described.

I have not implemented validation algorithms or special processing  
for nameservers but in my opinion the document being clear enough to  
reach interoperability.

In the past I have repeatedly said that I am not happy with the way  
that OPT-OUT (then called OPT-IN) changes the security model away  
from the concept that a "zone" is secure. I continue to not be happy  
but consent with the argument that such feature is needed in specific  
operational environments.

namedropper, no hats,

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 5 Feb 2007 12:10:25 +0100

> will terminate Sunday February 11 around 23:00 HST.

Folk, please review and go on record for doing so.

In particular those that implemented and participated in workshops  
are invited to do so.

--Olaf

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 07 Feb 2007 09:48:41 +0100

Scott Rose wrote:
> I have read the draft, and I support it.
> 
> I sent the earlier comment to the authors/DNSEXT co-chairs:
> 
> ***
> Re: the NSEC3PARAM RDATA field section:
> 
> Would it be better to say that the values should be the same values as
> the corresponding values in the complete NSEC3 chain?  Just to press the
> notion that the NSEC3PARAM RR signals a complete chain.
> 
> And the flags field for the NSEC3PARAM RR is going to be different than
> the flags for the NSEC3 RR?  That's what it sounds like (in that the
> OPT-Out flag should never be set, and validators MUST ignore all
> non-zero flags in the NSEC3PARAM.
> ***
> 
> It is not a concern for me to warrant holding up the draft.  I just
> thought it sounded odd in the text.  Not sure what the solution is, or
> even if it requires a solution.
> 

Since the opt-out flag may differ between separate NSEC3 RRs, the same
flag in the NSEC3PARAM could only signify that 'some' NSEC3 RRs have the
opt-out bit set. This would be redundant and possibly even confusing.

Whether or not future flags in this field must match the complete chain
they refer to will depend on the meaning of those flags and their
specification. I guess one could possibly even think of a flag that will
only have meaning in the param record and not in the individual NSEC3 RRs...

Jelte

---

From: Roy Arends <[email-masked]>
Date: Wed, 7 Feb 2007 11:58:41 +0100

> even if it requires a solution.

Thanks for the review Scott, I'll take a look and try to figure out better 
wording.

Roy

---

From: Roy Arends <[email-masked]>
Date: Wed, 7 Feb 2007 12:00:21 +0100

> I have reviewed the nsec3 draft and support it going forward. 

Thanks for the review John.
 
> The query returned an NSEC3 RR showing that the request was

Thanks, I fixed those.

Roy

---

From: Roy Arends <[email-masked]>
Date: Wed, 7 Feb 2007 12:02:14 +0100

> operational environments.

Thanks for the review Olaf.

Roy

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Thu, 8 Feb 2007 19:00:41 -0500

I've read this document and I support it going forward.

I've implemented a validating library following the specifications  
from an earlier version of this draft (-07) and I found that to be  
generally straightforward to follow. I've tried to recollect which  
aspects I found somewhat confusing during the implementation, and  
whether I still see these to be issues. Other document-specific  
comments are at the end of this mail.

General
=======

- The term "ancestor of a name" is defined in many places. Is there a  
reference document that defines this term?

- It would have reduced the work for the validator had the server  
already presented the next hashed ownername as base32 encoded (it  
should be doing this encoding already for the owner name). Don't see  
this as a major issue though.

- since empty non-terminal can now have an NSEC3 record, should we  
say that we are updating RFC 4592? Or is this fuzzy enough because  
NSEC3 is not present in the bitmap and we don't respond to queries  
for NSEC3? Either way, a note may help.

- Usage of the term "Next Closer Name" is not always consistent. This  
term, as I understand it, always applies to a given name. So "NCN of  
XYZ ..." makes sense to me. But I've also seen instances of "NCN to  
XYZ ... ", "NCN for XYZ", and, in some cases, just "NCN" without  
referring to any subject. My suggestion is to change all instances of  
"Next Closer Name to XYZ" to  "XYZ's Next Closer Name" and making the  
subject explicit where it is not so.

Issues
======

8.3. Para after third numbered bullet:

    Once the closest encloser has been discovered, the validator MUST
    check that the NSEC3 that has the closest encloser as an  
ownername is
    from the proper zone.  The DNAME type bit must not be set and the NS
    type bit may only be set if the SOA type bit is set.

The NSEC3 that proves that a DS record for a delegation is absent can  
map to the same owner name. The NS bit will be set but the SOA will  
not. So there's some confusion here (at least for me).

Nits and Clarifications
=======================

1.1 Rationale, 2nd para
     ... or indirectly as a key for
     multiple WHOIS queries to reveal registrant data which many
     registries may have legal obligations to protect

This gives the impression that registrant information is otherwise  
hidden. Suggest changing this to say  that the problem is in the  
enumeration of the entire database, and that individual data is still  
public.

1.3 Terminology
Change:
Zone Enumeration: the practice of discovering the contents of a zone
       via successive queries.  Zone enumeration was non-trivial  
prior to
       the introduction of DNSSEC.
To:
Zone Enumeration: the practice of discovering the full contents of a  
zone
       via successive queries.  Although individual records in the  
DNS are
       themselves public, the ability to discover the complete  
contents of
       a zone was non-trivial prior to the introduction of DNSSEC.

1.3 Terminology
Change:
Original ownername:  the ownername corresponding to a hashed
       ownername.
To:
Don't really have a suggestion for better text. Maybe, "The ownername  
that is the subject of the hash transformation"?

1.3 Terminology
Opt-Out Zone:  a zone with at least one Opt-Out NSEC3 record.

Comment: To be clear, this is the zone that contains an opt-out  
record, and not the zone that has been opted out?

1.3 Terminology
Next Closer Name:  the name one label longer than a name's Closest
       Provable Encloser.

Comment: say that this is the name that _exists_ in the zonefile  
(should not be confused with next name according to Predecessor- 
Successor rules)

1.3 Terminology
    To cover:  An NSEC3 record is said to "cover" a name if the hash of
       the name, or Next Closer Name, falls between the NSEC3's  
ownername
       and the next hashed ownername.

Comment: I would remove the ","s enclosing "or Next Closer Name". The  
hash of the name is not the Next Closer Name.

Section 3

    An NSEC3 record whose span covers the hash of an unsigned
    delegation's Next Closer Name is referred to as an Opt-Out NSEC3
    record and is indicated by the presence of a flag.

Trying to dereference pointers between owner name, its ancestor, its  
Closest Encounter, its Closest Provable Encounter, and its Next  
Closer Name :) Should the "Next Closer Name" above instead be "owner  
name or its next closer name"?

Section 6

    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 have trouble parsing this even now :) Can't we say this without  
mentioning "closest provable encounter"? :

    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 record's ownername and next hashed ownername.

7.2.1, last para

Suggest changing:
    It is possible, when using Opt-Out (Section 6), to not be able to
    prove the actual closest encloser because it is only part of the
    names of insecure delegations covered by Opt-Out spans.
To:
    It is possible, when using Opt-Out (Section 6), to not be able to
    prove the actual closest encloser because it is one of the
    names that is covered by an Opt-Out span.

7.2.6 third para

Suggest changing:
    To this end, the NSEC3 that covers the Next Closer Name to the
    immediate ancestor of the wildcard MUST be returned.

To:
    To this end, the NSEC3 that covers the Next Closer Name of
    the wildcard's immediate ancestor MUST be returned.

Section 8.3

Change:
     In order to verify a closest encloser proof, the validator MUST  
find
     the longest name, X, such that
To:
    In order to verify a closest encloser proof, the validator MUST find
    the longest name, X, such that one of the following two  
conditions is satisfied:

Section 8.4

For:
    A validator MUST verify that there is a closest encloser proof for
    QNAME present in the response and that there is an NSEC3 that covers
    the wildcard at the closest encloser (i.e., the name formed by
    prepending the asterisk label to the closest encloser.)

Since there is no wildcard at this name, suggest changing above text to:
    A validator MUST verify that there is a closest encloser proof for
    QNAME present in the response and that there is an NSEC3 that covers
    the name formed by prepending the asterisk label to the closest  
encloser.

On Jan 10, 2007, at 12:15 PM, Olaf M. Kolkman wrote:

> The bar is at 5 folk going on record for having done thorough review.
>
> For those that wrote implementations please report your experiences
> while implementing. This is very helpful in the report for the AD, it
> indicates protocol quality.
>
> Editorial nits can be send directly to the editors but please CC
> dnsext-chairs at tools dot ietf dot org.
>
>
> The document history can be found at:
>
> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-nsec3
>
>
> Happy reading!
>
>
> --Olaf & Olafur
>

---

From: Roy Arends <[email-masked]>
Date: Fri, 9 Feb 2007 16:12:12 +0100

> reference document that defines this term?

It is used in rfc 1034/5. We haven't found any definition of this 
terminology.

> this as a major issue though.

The wireformat of the next hashed ownername is binary, which is chosen for 
optimized rdata use. We'd save a few bytes per record this way.

I don't see the upside of the server doing the base32 encoding: the 
resolver/validator needs to decode the base32 encoded part of the 
ownername. We explicitly asked for a new definition of the base32 alfabet 
in rfc4648 for this purpose, so that the sort order of the binary values 
would match the sort order of its base32 encoded equivalent.
 
> for NSEC3? Either way, a note may help.

empty non-terminals remain empty non-terminals. There is an NSEC3 record 
associated with the empty non-terminal (i.e. there would be an NSEC3 at 
Base32_enc(Hash(ENT)).ENT ), but not at the empty non-terminal.

> subject explicit where it is not so.

I'll look for better wording, thanks.

> not. So there's some confusion here (at least for me).

If the ownername and the next hashed ownername are equal (i.e. have the 
same original ownername), the SOA bit is always set. I don't see the 
confusion. Can you elaborate a little bit on this ? 
 
> hidden.
> Suggest changing this to say  that the problem is in the 

I guess it is very clear that the data is still public.

>        a zone was non-trivial prior to the introduction of DNSSEC.

I guess it is very clear that the data is still public.

> that is the subject of the hash transformation"?

Okay, will leave as is.
 
> record, and not the zone that has been opted out?

yes.
 
> (should not be confused with next name according to Predecessor- 

The next closer name does _not_ exist in the zone. 

> hash of the name is not the Next Closer Name.

Fixed.
 
> name or its next closer name"?

Yes it should, good catch ! Fixed.
 
>     between the NSEC3 record's ownername and next hashed ownername.

Copied verbatim, thanks. Fixed.

>     names that is covered by an Opt-Out span.

It may be the name, it may be part of the name. I've fixed it as follows:

      It is possible, when using Opt-Out (Section 6), to not be able to 
      prove the actual closest encloser because it is, or is part of an
      insecure delegation covered by an Opt-Out span.

Thanks.

>     the wildcard's immediate ancestor MUST be returned.

Fixed.
 
>     the longest name, X, such that one of the following two 

No. Both conditions have to be satisfied !

X must exist (first condition), and one label longer then X must NOT exist 
(second condition).

>     the name formed by prepending the asterisk label to the closest 

We'd like to keep the term 'wildcard' in this section (since we're proving 
the absence of a wildcard). Hence, we would like to leave it as-is. And 
since there is no wildcard at this name, we're using the term 'covers' 
instead of 'matches'.

Thanks for the review, Suresh !!!!

Roy

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 07 Feb 2007 09:42:23 +0100

> make note of those but do not expect old discussions to be rehashed.

I have reviewed the draft, and implemented it in both a signer and a
validator. I think the text is clear enough to achieve interoperability,
and support the draft going forward.

Minor textual issues:
- - 4.1.2: i think the word reserved is missing here
- - 4.2: the description of the salt is missing. It kind of redundant but
the other fields were described...
- - 7.1 point 5: 'replacing' -> 'replacing them'
- - (not sure about this one: 7.2.2, should 'proven' be 'provable'?)
- - 7.5 'the value of the Opt-Out flag is set the' misses the word 'to'

Also i'm not too happy about the choice of words for the unlikeliness of
hash collisions, 'astronomically' and 'fantastically'...

Jelte

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 9 Feb 2007 11:07:07 -0500

> Base32_enc(Hash(ENT)).ENT ), but not at the empty non-terminal.

Then we may need to change the text in Section 7.1, second bullet:
From:
    o  Each empty non-terminal MUST have an NSEC3 record, unless the
       empty non-terminal is only derived from an insecure delegation
       covered by an Opt-Out NSEC3 RR
To:
    o  Each empty non-terminal MUST have a corresponding NSEC3 record,
       unless the empty non-terminal is only derived from an insecure  
delegation
       covered by an Opt-Out NSEC3 RR

> confusion. Can you elaborate a little bit on this ?

The text did not give me the impression that the condition being  
discussed was that about the NSEC3 ownername and next hashed  
ownername being equal. The text simply says that once we find the  
closest encounter, the NSEC3 corresponding to that name must have the  
NS bit set only if the SOA bit is set. Or am I not reading this  
properly?

> I guess it is very clear that the data is still public.

We both understand this :) However this text, on first reading, did  
not give me that feeling:

    "An enumerated zone can be used [....] indirectly as a key for
    multiple WHOIS queries to reveal registrant data which many
    registries may have legal obligations to protect."

> The next closer name does _not_ exist in the zone.

This still does not tell me which name we are referring to. The text  
now leaves me with the impression that any name created on the fly,  
as long is it is one label more than the original name, is fine.  
Perhaps:

	Next Closer Name: an ancestor of the name, one label longer than the  
name's Closest encounter.

> X must exist (first condition), and one label longer then X must  

Then we need to mention "... such that the following two conditions  
are satisfied". Make the requirement explicit.

---

From: Roy Arends <[email-masked]>
Date: Fri, 9 Feb 2007 19:26:43 +0100

>        covered by an Opt-Out NSEC3 RR

Absolutely. Thanks. fixed.

> NS bit set only if the SOA bit is set. Or am I not reading this 

My bad, misread your initial writing. You are reading this properly. 

Basically, the validator must check if the NSEC3 comes from the 
authoritative zone, not an ancestor zone. The text here tries to say that 
for the NSEC3 record that showes the closest encloser, the following must 
be true:

1) DNAME bit == 0
2) (NS bit == 1) implies (SOA bit == 1)

>     registries may have legal obligations to protect."

I understand, but lets leave it as is. I do not really feel obliged to 
write that individual registrant data is public.

> name's Closest encounter.

I don't get it. Isn't that what we wrote ?

> are satisfied". Make the requirement explicit.

Yes. good point ! Fixed.

Thanks. 

Roy

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 9 Feb 2007 14:48:20 -0500

Just to re-iterate: I don't have any major issues with the draft  
itself. But these were things that, I felt, had the potential of  
causing some confusion.

> 2) (NS bit == 1) implies (SOA bit == 1)

The disconnect, I think, may be in our interpretations of the term  
"closest enclosure". From RFC 4592:

    The closest encloser is the node in the zone's tree of existing
    domain names that has the most labels matching the query name
    (consecutively, counting from the root label downward)

I've interpreted this to mean that the closest enclosure for a name  
that exists in the zone is that name itself. Therefore, the NSEC3  
that I receive in response to a query for foo.example.com/DS (where  
the DS is provably non-existent) would also be the NSEC3 record that  
shows the closest enclosure, but it would have the NS bit == 1 and  
SOA bit == 0 (in violation of rule 2).

I think the NSEC3 draft modifies the definition of closest enclosure  
and states that the closest enclosure has to be an ancestor of the  
name. In which case the above rules do not apply. Is that a correct  
assessment?

[Side note: Definition of closest enclosure in the nsec3-09 points to  
RFC 4692 instead of 4592.]

>    Next Closer Name:  the name one label longer than a name's Closest

The current definition does not say that this name is an ancestor of  
(or related in any manner to) the original name. It only says that it  
is "one label longer", which is not precise IMHO.
(s/encounter/provable enclosure from my earlier text)

---

From: Matt Larson <[email-masked]>
Date: Fri, 9 Feb 2007 15:09:07 -0500

On Wed, 10 Jan 2007, Olaf Kolkman wrote:
> 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.

Matt

> 6.  Opt-Out
> [...]
>    the delegation's Next Closer Name to its closest provable encloser is

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.

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.

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.

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

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

s/in/is

> 7.5.  Dynamic Update
> 
>    A zone signed using NSEC3 may accept dynamic updates.  [...]

Should there be an informative reference to RFC 2136 here?

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

> 8.3.  Closest Encloser Proof
> 
> [...]
>    3.  Truncate SNAME by one label, go to step 2.
> 
>    check that the NSEC3 that has the closest encloser as an ownername is
                                                             ^ original
>    from the proper zone.

I think adding "original" increases clarity.

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

> 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

---

From: Roy Arends <[email-masked]>
Date: Fri, 9 Feb 2007 21:34:47 +0100

> itself. But these were things that, I felt, had the potential of 

I understand, and I'm very happy with the feedback.

> SOA bit == 0 (in violation of rule 2).

Yes.

> name. In which case the above rules do not apply. Is that a correct 

We only use the closest encloser terminology in a context where we have to 
prove that the qname does not exist. So in all fairness, we can safely use 
the exact definition of rfc 4592. Will try to make that work.
 
> RFC 4692 instead of 4592.]

Thanks !

> (s/encounter/provable enclosure from my earlier text)

Ah, okay.

As said, will try to make the text consistent with 4592.

Thanks !

Roy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Sun, 11 Feb 2007 09:38:51 +0100

> Please review the draft and put that fact on record through a post to

I have reviewed the draft and think that it is ready to pass last call.
Editorial comments have been sent to the authors.

Regards,
Marcos

---

From: Roy Arends <[email-masked]>
Date: Mon, 12 Feb 2007 00:11:05 +0100

> >    An Opt-Out NSEC3 record is said to cover a delegation if the hash 
of
>      delegation is between the NSEC3 ownername and next hashed

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.

> >    assert the existence of the delegation.

fixed.

> all are and trying to figure things out from the RFC as a starting

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.

> I think adding "(nonexistent)" increases clarity.

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

Fixed.

> Should there be an informative reference to RFC 2136 here?

I've added a reference to 2136. 

> "only" above helps make that more clear.

Absolutely ! Fixed !
 
> I think adding "original" increases clarity.

I agree. Fixed.

> always have an empty Type Bit Maps field?

Ack. I removed the word 'usually', but did not add 'always'.

Fixed.

Thanks for the review Matt !

Roy

---

From: Roy Arends <[email-masked]>
Date: Mon, 12 Feb 2007 02:37:38 +0100

> Editorial comments have been sent to the authors.

Thanks for the review, Marcos !

Editorial comments have been received.

Roy

---

From: Peter Koch <[email-masked]>
Date: Wed, 21 Feb 2007 11:55:43 +0100

> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-nsec3

I have read the draft and support NSEC3 going on Standards Track. The document
is well written. Availability of implementations as tested in the NSEC3
workshops gives me confidence that NSEC3 will be a good step forward in
DNSSEC deployment, solving a huge deployment obstacle.

Since there will at least be a -10, here are some comments, including
questions, remarks and nits. I know I'm late, so I'll try to avoid duplication.
Apologies for any that remain.

-Peter

-----------------------------------------------------------------------------
1) Issues

> 7.  Authoritative Server Considerations
> 
> 7.1.  Zone Signing

>        *  The ownername of the NSEC3 RR is the hashed equivalent of the
>           original owner name, prepended to the zone name.

s/prepended to the zone name/as a single label directly below the zone apex/
(Zones don't start with ".", so "prepending" isn't really correct.)

>    If a hash collision is detected, then a new salt MUST be chosen and

Step 1 declares collision detection optional, but here's a MUST, which appears
inconsistent to me. By the way, I applaud the replacement of 'astronomically
unlikely'.

> 7.2.8.  Responding to NSEC3 Queries
> 
>    Since NSEC3 ownernames are not represented in the NSEC3 chain like
>    other zone ownernames, direct queries for NSEC3 ownernames present a
>    special case: NSEC3 ownernames cannot be proven to exist, in general.

Isn't that "_can_ be proven _not_ to exist"?

>    If the following conditions are all true:
> 
>    o  The QNAME equals an existing NSEC3 ownername, and
> 
>    o  No record types other than RRSIG or NSEC3 exist at QNAME.
> 
>    Then the response MUST be constructed as a Name Error response
>    (Section 7.2.2).  Or, in other words, the authoritative nameserver
>    will act, for direct query purposes, as if the NSEC3 ownername did
>    not exist.

I know we've discussed this before and I still think, this is wrong and
a better approach would be to state that "NSEC3 RRs and their covering RRSIG
RRs do not bring the ownername into existence".
With the text as stated, ANY queries would still (have to) reveal NSEC3
and corner cases are possible where a name might actually exist below
a hashed owner name (maybe just because it can), which would force the
server to lie about the ancestor's existence.

> 10.2.  DNAME at the zone apex
> 
>    The DNAME specification RFC 2672 [13] section 3 has a 'no-
>    descendants' limitation.  If a DNAME RR is present at node N, there
>    MUST be no data at any descendant of N.
> 
>    If N is the apex of the zone, there will be NSEC3 and RRSIG types
>    present at descendants of N. This specification updates the DNAME
>    specification to allow NSEC3 and RRSIG types at descendants of the
>    apex regardless of the existence of DNAME at the apex.

See remarks about existence. This update wouldn't be necessary.

> 13.2.  Informative References

I think the author of the NO RR document deserves an acknowledgement.

-----------------------------------------------------------------------------
2) Questions

> 8.2.  Verifying NSEC3 RRsets

>    A validator MAY treat a response as bogus if the response contains
>    NSEC3 RRs that contain different values for hash algorithm,
>    iterations, or salt from each other.

Now, are multiple parallel NSEC3 chains allowed or not? Is NSEC3 a singleton
type?  Would an NSEC3 RRSet ever consist of more than one NSEC3 RR, even
if multiple chains were allowed?

>    o  X is an ancestor of QNAME that matches an NSEC3 RR present in the
>       response.  This is a candidate for the closest encloser.

s/matches/is matched by/

> 
>    o  The name one label longer than X (but still an ancestor of--or
>       equal to--QNAME) is covered by an NSEC3 RR present in the
>       response.
> 
>    One possible algorithm for verifying this proof is as follows:

Here you got me, I couldn't follow the algorithm. In pictures, I'd know
what this is trying to achieve, just the text confuses me (but that might
likely be me). 

Could we introduce the flag's meaning and initial value?

>    1.  Set SNAME=QNAME.
> 
>    2.  Check whether SNAME exists:
> 
>        *  If there is no NSEC3 RR in the response that matches SNAME
>           (i.e., an NSEC3 whose ownername is the same as the hash of
>           SNAME, prepended to the zone name), clear the flag.
> 
>        *  If there is an NSEC3 RR in the response that covers SNAME, set
>           the flag.
> 
>        *  If there is a matching NSEC3 RR in the response and the flag
>           was set, then the proof is complete, and SNAME is the closest
>           encloser.
> 
>        *  If there is a matching NSEC3 RR in the response, but the flag
>           is not set, then the response is bogus.

Does "matching NSEC3 RR" refer to SNAME?

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

3) Remarks and Nits

> 1.1.  Rationale
>    An enumerated zone can be used either directly as a source of
>    probable e-mail addresses for spam, or indirectly as a key for
>    registries may have legal obligations to protect.  Many registries

This (either - or) could be read to imply that spam and access to whois were
the only problems. They are not, just two prominent examples.

> 1.3.  Terminology
> 
>    The reader is assumed to be familiar with the basic DNS and DNSSEC
>    concepts described in RFC 1034 [2], RFC 1035 [3], RFC 4033 [4], RFC

I'd recommend a different citation style ([RFC1034], [RFC1035], ...)
that avoids typos.

>    Hash order:  the order in which hashed ownernames are arranged
>       according to their numerical value, treating the leftmost (lowest
>       numbered) octet as the most significant octet.  Note that this
>       order is the same as the canonical DNS name order specified in RFC
>       4034 [5] when the hashed ownernames are encoded using base32 with
>       the chosen alphabet.

Reference to RFC4648 missing here.

>    Delegation:  an NS RRset with a name different from the current zone
>       apex (non-zone-apex), signifying a delegation to a subzone.

s/to a subzone/of a child zone/

> 
>    Secure delegation:  a name containing a delegation (NS RRset), and a
>       signed DS RRset, signifying a delegation to a signed subzone.
> 
>    Insecure delegation:  a name containing a delegation (NS RRset), but
>       lacking a DS RRset, signifying a delegation to an unsigned
>       subzone.

%s/RRset/RRSet/g (with regards to Roy ;-)
s/a name containing a delegation/a name owning a delegation/

> 2.  Backwards Compatibility
> 
>    This specification describes a protocol change that is not generally
>    backwards compatible with standard DNSSEC.  In particular, security-

AFAIK it's inappropriate to speak of "standard" where that maturity level
has not yet been reached. Suggested alternative: "DNSSECbis" with ref
to the three 403[345] RFCs.

>    aware resolvers that are unaware of this specification (NSEC3-unaware
>    resolvers) may fail to validate the changed responses dictated by
>    this document.

s/changed responses dictated by/new style of responses introduced by/

>    A methodology for transitioning from a DNSSEC standard signed zone to

see above for "standard".

> 3.1.2.  Flags Field
> 
>    The Flags field contain 8 flags that can be used to indicate

contain_s_

> 3.1.3.  Iterations
> 
>    The Iterations field defines the number of additional times the hash
>    has been performed.  More iterations results in greater resiliency of

result, plural?

> 3.2.1.  Type Bit Map Encoding
> 
>    The encoding of the Type Bit Map is the same as used by the NSEC
>    record, described in RFC 4034 [5].  It is repeated here for clarity.

Since the following text is an edited copy of section 4.1.2 of RFC 4034,
I'd not say "repeated" but "explained and clarified". The current text also
clarifies 4034 (references to 2929 etc), so is this meant to update 4034?

> 4.  The NSEC3-Parameters Resource Record

>    If an NSEC3PARAM RR is present at the apex of a zone with a Flags
>    Field value of zero, then there MUST be an NSEC3 using the same
>    parameters present at every hashed ownername in the zone.  That is,
>    the zone MUST contain a complete set of NSEC3 RRs with the same,
>    indicated parameters.

It took me some time to read "every hashed ownername" in a way that
does not preclude Opt-Out. I think it's important to emphasize that
NSEC3PARAM may only be present if there's a full loop of NSEC3 RRs.

>    The NSEC3PARAM RR RDATA format is class independent and is described
>    below.

I'd add that NSEC3PARAM is not a singleton type.

Queries for NSEC3PARAM are not covered. I think there is no point in ever
asking (during normal operation) for NSEC3PARAM, but I've convinced myself
that the queries don't need to be prohibited. While generally I fear "apex
overload", NSEC3PARAM just appears in exchange for an NSEC RR that would
otherwise be present at the same owner.

> 4.3.  Presentation Format
> 
>    The presentation format of the RDATA portion is as follows:

Why not just refer to 3.3 here?

> 5.  Calculation of the Hash
> 
>    The hash calculation uses three of the NSEC3 RDATA fields: Hash
>    Algorithm, Salt, and Iterations.

s/NSEC3/NSEC3 and NSEC3PARAM/

>    where the ownername is in the canonical form.
> 
>    The canonical form of the ownername is the wire format of the
>    ownername where:

resolve the forward reference:

>    These delegations are proven insecure with a covering Opt-Out NSEC3
>    record.

I don't think they are "proven insecure", which would imply they are
proven to exist in the first place. The following text correctly states
that in an Opt-Out span not even that is possible.

>    there MUST NOT be any hashed ownernames of insecure delegations (nor
>    any other records) between it and the RRsets indicated by the Next
>    Hashed Ownername in the NSEC3 RDATA.  If it is Opt-Out, it MUST only

between it and the _name_ indicated by the Next Hashed Ownername

[more to follow in private to Editors]

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

---

From: Roy Arends <[email-masked]>
Date: Wed, 21 Feb 2007 15:40:46 +0100

> Apologies for any that remain.

Dear Peter,

Thanks for the review, my comments are inline.

> (Zones don't start with ".", so "prepending" isn't really correct.)

Though the examples might give a hint on this, I'll make this explicit. It 
now reads:
 
           *  The ownername of the NSEC3 RR is the hash of the original 
ownername, 
              prepended as a single label to the zone name.
 
> inconsistent to me. 

I'll turn MUST into 'has to'. Would that suffice ?

> By the way, I applaud the replacement of 'astronomically
> unlikely'.

Yep. Suresh brought it up. I agree.

> Isn't that "_can_ be proven _not_ to exist"?

NSEC3 ownernames cannot be proven to exist. Proof of existence of an NSEC3 
ownername requires another NSEC3 record, which makes this a recursive 
problem.
 
> server to lie about the ancestor's existence.

This section is not about QTYPE==NSEC3. QTYPE==NSEC3 is _NOT_ the problem.

This section deals with QNAME == HASH(example.com).com

Assume xxxxx = HASH(example.com)

If xxxxx.com has children, say child.xxxxx.com, this would cause xxxxx.com 
to _exist_ as an Empty Non Terminal. Therefor, there will also be a 
HASH(xxxxx.com).com NSEC3 record that proves that xxxxx.com exist as an 
empty non terminal.

So, we adhere to the statement that NSEC3 RRs do not bring the ownername 
into existence.
 
> I think the author of the NO RR document deserves an acknowledgement.

Asbolutely ! Kudo's to Simon. Will add 
http://www.josefsson.org/draft-jas-dnsext-no-00.txt in the informative 
references.

> Now, are multiple parallel NSEC3 chains allowed or not? 

Multiple NSEC3 chains are allowed. Not sure what you mean by parallel.

> Is NSEC3 a singleton
> type?

Singleton type is a bind-ism. Assuming that you're asking if an NSEC3 name 
can hold other RR types besides NSEC3, the answer is yes. (i.e. NSEC3 is 
not a singleton type)

> Would an NSEC3 RRSet ever consist of more than one NSEC3 RR, even

No.

find
> >       response.  This is a candidate for the closest encloser.

Ack. Fixed.

(My mom told me never to play with matches, but that was a long time ago 
;-) )
 
> Could we introduce the flag's meaning and initial value?

Ack. Fixed. 

Yes.

> the only problems. They are not, just two prominent examples.

I'd love to have more examples, though. :)

I've changed it to:

       An enumerated zone can be used for example as a source of probable 
e-mail 
       addresses for spam, or as a key for multiple WHOIS queries to 
reveal 
       registrant data which many registries may have legal obligations to 
protect.

Fixed.

Fixed.
 
> s/to a subzone/of a child zone/

Fixed 

> %s/RRset/RRSet/g (with regards to Roy ;-)

Dear Peter. I'm not convinced ;)

Fixed.
 
> s/changed responses dictated by/new style of responses introduced by/

I fixed it to "fail to validate the responses introduced by this 
document."

Fixed.

Fixed.

Fixed.
 
> I'd not say "repeated" but "explained and clarified". 

Fixed.

> The current text also

I don't know what you mean.
 
> NSEC3PARAM may only be present if there's a full loop of NSEC3 RRs.

We state 'complete set of NSEC3 RRs with..."
 
> I'd add that NSEC3PARAM is not a singleton type.

No. I can't introduce bindisms.
 
> Queries for NSEC3PARAM are not covered.

There is nothing special about queries for NSEC3PARAM.

> I think there is no point in ever

Dunno. I'm afraid that I'll get an ID Nits:"document too short" error. :)

The RDATA is somewhat different, so if I'd refer to 3.3, I'd have to state 
the differences and exceptions. This seems less clumsy.

> s/NSEC3/NSEC3 and NSEC3PARAM/

No. Why ?

Fixed.

> proven to exist in the first place.

Removed the sentence. 

> The following text correctly states

Fixed.

Thanks Peter.

---

From: Peter Koch <[email-masked]>
Date: Wed, 21 Feb 2007 21:07:13 +0100

Dear Roy,

thanks for your detailed reply.

> I'll turn MUST into 'has to'. Would that suffice ?

fine with me.

> ownername requires another NSEC3 record, which makes this a recursive 

Proof of existence usually is neither necessary nor a goal because it happens
implicitly by having a (signed) RRSet for a name. Seems we have a before-after
problem here: you're saying it can't be proven, "because of the following"?

> This section is not about QTYPE==NSEC3. QTYPE==NSEC3 is _NOT_ the problem.

Sorry, I've payed more attention to the section heading "Responding to NSEC3
Queries" than to the actual text.

> This section deals with QNAME == HASH(example.com).com

... and independent of type, yes.

> So, we adhere to the statement that NSEC3 RRs do not bring the ownername 

Yes, please ;-)

> Multiple NSEC3 chains are allowed. Not sure what you mean by parallel.

Both chains are full loops, independent of each other (hopefully consistent,
though).

> Singleton type is a bind-ism. Assuming that you're asking if an NSEC3 name 

Apologies for having used non implemention-neutral terminology. Still the

> can hold other RR types besides NSEC3, the answer is yes. (i.e. NSEC3 is 

Now we see that the term even was ambiguous. I had SOA's properties in mind,
not CNAME's, i.e., whether multiple NSEC3 RRs may exist at (not for) the
same owner (which would probably imply a collision).

>        registrant data which many registries may have legal obligations to 

thanks.

> I don't know what you mean.

The text is no verbatim copy of what appeared in RFC 4034, but it is more
clear. Should one assume that this clarification now also applies to the
NSEC spec in 4034?

> We state 'complete set of NSEC3 RRs with..."

Yes, but "the same parameters" seemed to preclude flags!=0.

> No. I can't introduce bindisms.

bindism is a bindism.

> the differences and exceptions. This seems less clumsy.

OK

> > s/NSEC3/NSEC3 and NSEC3PARAM/

Well, isn't the info in NSEC3PARAM used by the server to locate the NSEC3?

-Peter

---

From: Roy Arends <[email-masked]>
Date: Wed, 21 Feb 2007 23:01:12 +0100

Peter Koch <[email-masked]> wrote on 02/21/2007 09:07:13 PM:

> implicitly by having a (signed) RRSet for a name.

Yes. Also explicitly by having a signed NSEC or NSEC3 for a name.

> Seems we have a before-after

I don't get it. Sorry.

Yes.

Yes.

> Yes, but "the same parameters" seemed to preclude flags!=0.

Ah. Will fix.
 
> Well, isn't the info in NSEC3PARAM used by the server to locate the 
NSEC3?

This section is general, i.e. this algorithm is also used by the validator 
and the signer (both entitities that need not know about NSEC3PARAM).

Roy