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

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 10 Jan 2007 18:15:19 +0100

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.

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

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

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 19 Jan 2007 15:47:32 +0100

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

Hi,

I have reviewed the NSEC3 document, and implemented an authoritative
server. I think the draft is fine and NSEC3 can be implemented from it.
My implementation does not share code with other implementations. So, I
support this draft going forward.

The NSEC3 workshops were very helpful. Bugs were squashed and the
protocol improved.

One surprising find, for me, was that writing signers is hard. Many
deficiencies in signers only become apparent once served and resolved.

Another note is that the final NSEC3 in the NSEC3 chain (much like the
final NSEC in an NSEC chain) has its ownername bigger (in sortorder)
than the next-owner-name field. This causes it to follow a different
code path in many implementations. A corner case for implementors to
look at.

Issues
* One issue is replies to queries with qtype=NSEC3. I prefer to give
answers (as from a previous version of the draft). Because the NSEC3 and
its RRSIG exist, they are data types not meta types, and it should be
possible to query for them. However, I can understand it makes the
protocol more complicated, and will not be used in practice. So I can
live with the current resolution, to not answer them.
* Iterations and flags. Iterations field may be considered short if
computers become 2**10 faster. That is not a problem that needs to be
solved now.
* Hash collisions. Currently SERVFAIL is returned. The failure is not
with the server, but with the protocol. Maybe rcode ''PROTOFAIL'' :-).
Using a different rcode will not make a practical difference here, so
the issue is moot.

Discussion of the document.
Page 20, section 7.2.7 change
  If the zone in Opt-Out, then there may not be an NSEC3 record
  If the zone is Opt-Out, then there may not be an NSEC3 record
Page 28, section 10.4 change
  treat the zone as insecure.  At this point, the authoritative
  treat the zone as insecure.  At this point, the authoritative server
Page 31, section 12.3 change
  zone (plus empty non-terminals), and also what types they are.  This
  zone (plus empty non-terminals), and also what types there are.  This
Appendix.
Thanks for the examples. I tested my implementation against it and it
works. Note that if the IANA actions are taken, the signatures in the
examples may change.

Best regards,
   Wouter

--
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: Wouter Wijngaards <[email-masked]>
Date: Mon, 22 Jan 2007 10:47:49 +0100

Hi,

NSEC3 section 7.4: Zones using unknown hash algorithms. It says that the
server SHOULD give SERVFAIL to all queries for such zones. I would like
to understand the tradeoff.

My question is what does the resolver expect when a server is serving an
unknown hash algorithm? And does not do the SHOULD?

One thing I can think of (not completely theoretically) is that the
DNSSEC information is not in the answer (the zone is unsecure for that
query). This gives unsecure service. But is BOGUS for the resolver.

Best regards,
   Wouter

---

From: Roy Arends <[email-masked]>
Date: Mon, 22 Jan 2007 11:20:45 +0100

> live with the current resolution, to not answer them.

Okay.

> computers become 2**10 faster. That is not a problem that needs to be

Okay. 

> Using a different rcode will not make a practical difference here, so

Okay.
 
>   If the zone is Opt-Out, then there may not be an NSEC3 record

Fixed.

>   treat the zone as insecure.  At this point, the authoritative server

Fixed.

>   zone (plus empty non-terminals), and also what types there are.  This

Fixed.

> works. Note that if the IANA actions are taken, the signatures in the

Indeed. Thanks for the heads up !

Thanks for the review wouter !

Roy Arends
Nominet

---

From: Roy Arends <[email-masked]>
Date: Mon, 22 Jan 2007 11:40:01 +0100

> unknown hash algorithm? And does not do the SHOULD?

Section 7 (including 7.4) is about authoritative server considerations and 
considers the case where the primary server serves a zone with a hash 
function that is not known to the secondary server. Since a server needs 
to use the hashfunction to find the appropriate NSEC3 record, it needs to 
known the hashfunction. Hence the SERVFAIL. We made that a SHOULD instead 
of a MUST since there are responses without NSEC3 records that obviously 
do not suffer from unknown hash functions. Also, there might be some 
out-of-band metadata that maps names to hashes without the need to know 
the actual hash-function. 

The validator considerations (section 8) handles the case where a received 
response has a hash-function that is unknown to the validator. That record 
is than simply ignored (as if it wasn't included in the response). The 
result is that the validator can't validate the response (because of 
missing NSEC3 records) and will generally consider the response to be 
bogus, unless overruled by some local policy.

> query). This gives unsecure service. But is BOGUS for the resolver.

Yes. I think you came to same conclusion as we did when writing section 
8.1 :-)

Regards,

(and thanks again)

Roy Arends
Nominet

---

From: Scott Rose <[email-masked]>
Date: Tue, 30 Jan 2007 10:40:29 -0500

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.

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnssec-deployment.org/
-----------------------------------------