Subject: Advance: DNSSECbis document set

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 20 Jul 2004 09:50:00 +0200

Dear Thomas and Margaret,

This is a request to advance 

  draft-ietf-dnsext-dnssec-intro-11,
  draft-ietf-dnsext-dnssec-proto-07,
  and
  draft-ietf-dnsext-dnssec-records-09

to proposed standard.

Below follows the filled in questionair from
http://www.mip4.org/2004/draft-writeup-items.html (version 0.3)

   1. Have the chairs personally reviewed this version of the ID and
      do they believe this ID is sufficiently baked to forward to the
      IESG for publication?

Yes.

   2. Has the document had adequate review from both key WG members
      and key non-WG members? Do you have any concerns about the depth
      or breadth of the reviews that have been performed?

The document set has seen a few review cycles, there where also a
number of workshops in which implementations of the specs where
tested. We had comments from people that were present at those
workshops but also comments by people that reviewed the document
during last call and not earlier. In other words, various eyes had
various looks under different circumstances.

   3. Do you have concerns that the document needs more review from a
      particular (broader) perspective (e.g., security, operational
      complexity, someone familiar with AAA, etc.)?

No.

The document-set is founded on RFC2535 and a number of modifications
introduced by later RFCs those modifications have all been approved and
published as standard track documents. The document set intends to be
a compilation and a clarification on earlier work. 

   4.  Do you have any specific concerns/issues with this document
       that you believe the ADs and/or IESG should be aware of? For
       example, perhaps you are uncomfortable with certain parts of
       the document, or whether there really is a need for it, etc.,
       but at the same time these issues have been discussed in the WG
       and the WG has indicated it wishes to advance the document
       anyway. 

During the development of the DNSSECbis specs (as this document set is
refered to) several modifications to the RFC2535 specs were
proposed. Some of them made it to RFC (e.g. 3755 and 3757) and some of
them where rejected by the working group. The rejection of the so
called "opt-in" modification caused heated debate. This debate
concluded more than a year ago. Given that the pro- and opponents of
"opt-in" have constructivly participated in the further development
and conclussion of the DNSSECbis specs we conclude that the WG has
moved on.

During the last call it was made explicit that the possibility that
zone enumeration is possible through a so called "NSEC" walk would be
prohibitive for deployment of DNSSEC in some CC-TLD zones. 

The zone-enumeration has been a well known feature, documented in the
security section since the first versions of the document set. While
this problem was sometimes brought up, providing privacy was an
explicit non-goal.

The WG decided not to fix this problem but assessed that further
development of DNSSEC to cope with the issue is possible within the
current specification.

The WG is in the process of formulating requirements for this future
work, it is on the IETF 60 agenda.

There is broad consensus that this is the appropriate way forward.

    5. How solid is the WG consensus behind this document? Does it
   represent the strong concurrence of a few individuals, with others
   being silent, or does the WG as a whole understand and agree with
   it?

We believe that there is broad consensus for for forwarding the
document set.

   6.  Has anyone threatened an appeal or otherwise indicated extreme
       discontent? If so, please summarize what are they upset about.

No.

See 4 above, which started with a demonstration of discontent with the
NSEC-walk issue. We feel the issue brought to closer with the WG
members content.

   7.  Have the chairs verified that the document adheres to _all_ of
        the ID nits? (see http://www.ietf.org/ID-nits.html).

Yes (We checked against http://www.ietf.org/ID-Checklist.html, that is
what we are being redirected to).

   8.   Does the document a) split references into
   normative/informative, and b) are there normative references to
   IDs, where the IDs are not also ready for advancement or are
   otherwise in an unclear state? (Note: the RFC editor will not
   publish an RFC with normative references to IDs, it will delay
   publication until all such IDs are also ready for publication as
   RFCs.)

All reference sections are split.

For each document in the DNSSECbis document set the only IDs in the
normative references are other documents in the DNSSECbis document
set. e.g.

The only IDs in the normative reference set for intro are:
I-D.ietf-dnsext-dnssec-protocol and I-D.ietf-dnsext-dnssec-records

  9.  For Standards Track and BCP documents, the IESG approval
      announcement includes a writeup section with the following
      sections:

          * Technical Summary
          * Working Group Summary
          * Protocol Quality

      Please provide such a writeup. (We will hopefully use it as is,
      but may make some changes.) For recent examples, have a look at
      the "protocol action" announcements for approved documents.

      Note:

          * When doing the technical summary, one would expect that
            the relevant information is in the abstract and/or
            introduction of the document. It turns out that the step
            of producing the writeup sometimes points out deficiencies
            in the introduction/abstract that are also worthy of
            rectifying.  

	  * For the Working Group Summary, was there anything in WG
            process that is worth noting? (E.g., controversy about
            particular points, decisions where concensus was
            particularly rough, etc.)

          * For the protocol quality, useful information could include:
                    o is the protocol already being implemented?

                    o have a significant number of vendors indicated
                    they plan to implement the spec?

                    o are there any reviewers (during the end stages)
                    that merit explicit mention as having done a
                    thorough review that resulted in important changes
                    or a conclusion that the document was fine (except
                    for maybe some nits?)

[ Below is a technical summary that can be used with all 3
documents. Please let me know if you want to have this split.]

Technical Summary

   This document is part of a family of documents that describes the DNS
   Security Extensions (DNSSEC).  The DNS Security Extensions are a
   collection of resource records and protocol modifications that
   provide source authentication for the DNS.  
   
   The document series consists out of 3 documents:
    +  DNS Security Introduction and Requirements ([dnssec-intro])
    +  Protocol Modifications for the DNS Security Extensions ([dnssec-proto])
    +  Resource Records for the DNS Security Extensions ([dnssec-records])

   [dnssec-intro] introduces the DNS security extensions, and describes their
   capabilities and limitations. [dnssec-intro] also discusses the services
   that the DNS security extensions do and do not provide.  [dnssec-intro]
   describes the interrelationships between the group of documents
   that collectively describe DNSSEC.

   [dnssec-proto] describes the DNSSEC protocol modifications.
   [dnssec-proto] defines the concept of a signed zone, along with the
   requirements for serving and resolving using DNSSEC.  These
   techniques allow a security-aware resolver to authenticate both DNS
   resource records and authoritative DNS error indications.

   [dnssec-records] defines the public key (DNSKEY), delegation signer
   (DS), resource record digital signature (RRSIG), and authenticated
   denial of existence (NSEC) resource records.  The purpose and
   format of each resource record is described in detail, and an
   example of each resource record is given.

Working Group Summary

   There was consensus within the working group to publish the
   document as Proposed Standard.

Protocol Quality

   The following quote from  draft-ietf-dnsext-dnssec-intro-11.txt
   is relevant:

   "The specification in the DNSSEC document set defines the behavior
   for zone signers and security-aware name servers and resolvers in
   such a way that the validating entities can unambiguously determine
   the state of the data.
   
   (...) 

   A method for signaling advanced error codes and policy between a
   security aware stub resolver and security aware recursive nameservers
   is a topic for future work, as is the interface between a security
   aware resolver and the applications that use it.  Note, however, that
   the lack of the specification of such communication does not prohibit
   deployment of signed zones or the deployment of security aware
   recursive name servers that prohibit propagation of bogus data to the
   applications."

   (end quote)
   
   Various parts of the specification have been implemented.

   There are (at least) 2 signer implementations
   There are (at least) 2 authoritative server implementations
   There is (at least) 1 verifying recursive nameserver (hence a verifying
   resolver) implementation.
   There are various troubleshooting tools that have partial or full
   verification capabilities.

   These implementations have been used in several workshops and have
   been found to inter-operate.

-- Olaf Kolkman
   Olafur Gudmundsson
   DNSEXT Chairs

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