Subject: Protocol Action: 'DNSSEC Hashed Authenticated Denial of Existence' to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 17 Dec 2007 09:49:01 -0500

The IESG has approved the following document:

- 'DNSSEC Hashed Authenticated Denial of Existence '
   <draft-ietf-dnsext-nsec3-13.txt> as a Proposed Standard

This document is the product of the DNS Extensions Working Group. 

The IESG contact persons are Mark Townsley and Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-13.txt

 Technical Summary

The Domain Name System Security Extensions (DNSSEC) introduced the
NSEC resource record (RR) for authenticated denial of existence.
Though the NSEC RR meets the requirements for authenticated denial of
existence, it introduces a side-effect in that the contents of a zone
can be enumerated.  This property introduces undesired policy issues.

A second problem is that the cost to cryptographically secure
delegations to unsigned zones is high for large delegation-centric
zones and zones where insecure delegations will be updated rapidly.
(Typically these are top level domains). For these zones, the costs of
maintaining the NSEC record chain may be extremely high relative to
the gain of cryptographically authenticating existence of unsecured
zones.

This document presents the NSEC3 Resource Record which can be used as
an alternative to NSEC to mitigate these issues.

This document introduces an alternative resource record, NSEC3, which
similarly provides authenticated denial of existence.  However, it
also provides measures against zone enumeration and permits gradual
expansion of delegation-centric zones.

Working Group Summary

The OPT out feature of NSEC3 used to be a point of contention in the
DNSEXT working group. The working group did not bring OPT-OUT up as an
issue during the development of the draft or during last call. The
chairs are convinced that the feature was not introduced under the
radar and that the working group consents with the feature being
introduced.

The iterations count has been subject to discussion because it may be
used to  trigger DOS attacks on resolvers. The WG consensus is to
recommend a limitation  on the number of iterations that a resolver is
supposed to carry out.

Document Quality

During the development of the specification there were two workshops
organized in which, among others, 3 operators (Nominet, Verisign and
DENIC) and two Developers (ISC and NLnet) participated. During the
workshops serious signaling issues were discovered which lead to the
NSEC3PARAM RR.

The specification has been implemented, albeit not in production code,
in: BIND (authoritative server, validating resolver, caching name  
server), NSD (authoritative only), LDNS (library and troubleshooting
tools),
UNBOUND Java (validating resolver), Sparta's library (validating  
resolver), Net::DNS (Library, only parsing functions and helper methods)
and about
4 different zone signers.

Operators have indicated this specification to be imperative for
DNSSEC deployment.

Note to RFC Editor
 
Please see RFC Editor Instructions in the IANA Considerations section.
After type code assignments, some work will have to be done by the authors
of the document to regenerate text for the examples in the Appendix.

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