Subject: Request to advance "white lies documents"

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 6 Oct 2005 16:26:50 +0200

Namedroppers CC-ed so they know that these documents have been
processed.

Dear Margaret,

This is a request to publish two documents that describe a technique
that also known by the name of "white lies"

    draft-ietf-dnsext-dnssec-online-signing-00
    draft-ietf-dnsext-dns-name-p-s-01

Below is the evaluation sheet. I'll be the document shepherd for
these documents.
                                          ---------------------

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 both chairs reviewed these documents.

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?

     This idea had several iterations as a personal submission draft
     and has been discussed and refined a number of times. An early
     version of the p-s draft was implemented as a proof of concept and
     experiences with that led to a refinement.

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

    I do not have such concerns.

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.

    'White lies' is a technique to prevent the possibility of zone
     enumerations through NSEC walks. The basic principle (described in
     the online-signing draft) is that NSEC records that span the query
     name are automated on the fly.

     There has been some debate on the dynamics of the mechanism and
     the violation of some text in 4034 and 4035. There is consensus
     that this the online-singing document is to update the RFCbis
     specification.

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?

     As far as I can see all that care consent, the others are silent
     [I find it very hard to answer this question]

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

     No.

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

    Yes

     - the documents contain some version history information which can
       obviously be stripped by the RFC editor, when the time comes)

     - It could be argued that the abstracts are 'versed in technology',
       that is a matter of taste.

     - There is an informative reference to in the p-s draft (
       [I-D.ietf-dnsext-dnssec-trans]) that may or not be revived. We
       don't know currently.
8) 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.

     Technical summary

     Deployment of DNSSEC would allow trivial zone enumeration by a
     process that is called NSEC walking (The NSECs link the names in a
     zone in canonical order).

     The online-signing draft describes the principle of what is
     popularly called "white lies": Whenever a negative answer of
     is to be supplied one can generate an NSEC on the fly that
     appropriately covers the requested record.  The on-line signing
     document further describes the general requirements for algorithms
     that generate these records.

     The p-s draft describes one of these algorithms in detail; how can
     one find the neares possible predecessor and successor for a given
     query name.

     Although an update to 4034/4035 is needed, resolvers/validators
     will be able to parse and validate 'white lies' responses without
     any modification.

     Working Group Summary

     The working group consents that the online-signing draft is  
forwarded
     with the intention to be published on the standards track and  
that the
     p-s draft is to be published as experimental.

     Protocol Quality

     There has been a proof of concept implementation and there are
     some DNS registries that have expressed explicit interest in this
     technique.

--Olaf Kolkman

    DNSEXT Co chair.