Denial Of Existence: Way Forward

["Olaf M. Kolkman" <olaf@ripe.net>]

== Denial of Existence and zone enumeration and a way forward.


 Now the discussion is less heated and we are nearing a face to face
 meeting we want to try to summarize where we are and how to proceed
 as a working group.


== Is the problem real?

 We have seen long e-mail threads on the reality of the problem of
 zone enumeration. The summary of those discussion is that there are
 two views on this issue:

  1) DNS is a public database, if one has something to hide one should
     not put it into the DNS.

  2) NSEC walk makes the zone content fully enumerable, policy
     forbids us to deploy such mechanism.


 There is definitely no consensus on either of these two views being
 "the Truth (TM)".

 Supporters of '1' have tried to convince supporters of '2' that their
 policies are "broken". It is clear that they have not, and will not
 succeed. One has to agree on disagreement.

 Therefore we are faced with the fact that that major players (a hand
 full of large TLDs) will not deploy DNSSEC while NSEC walk is
 possible. For them the NSEC walk is a real problem and they have
 asked the IETF to engineer a way around the problem. We do not know
 if there are more "players" that have enumeration policies that would
 prevent them from rolling out DNSSEC.


== Should the DNSEXT WG do this work

 This is a problem that needs engineering, it is within scope of the
 DNSEXT charter so the short answer is "yes".

 The somewhat longer answer is that there are costs associated with
 this. It will cost time and money to develop specs, develop the
 software and do tests. It is not realistic to think that we can
 develop a good solution within a few months. Given our experience
 with the rewrite of the DNSSEC specifications a 2 year cycle seems
 like a realistic estimate. In that time (members of) the working
 group will need to come up with specs and running code.

 In order to do the work we will need a "critical mass" of interested
 individuals that can commit their resources in writing specs and code
 and a superset of individuals that can commit to review.

 In order to pursue this work as a working group item we will _not_
 ask the question 

 "Does the group want to see this as a working group item" 

 but will ask:

 1) Who will commit to producing specifications for a denial of existence
    method that does not allow for zone enumeration;

    We would like to see at least 3 people, which will be assigned an
    editors function, to commit.

 2) Who will commit on writing an implementation

    We would like to see at least 1 individual or group committing to
    develop (or fund development) of an implementation.


 3) Who will commit on reviewing the material

    We would like to see a set of people, different from the set of
    editors, to commit to review throughout the development of the
    specification.

  The intend of this exercise is to see if there is sufficient
  critical mass for this work to go forward. Please let us know if you
  can commit to 1,2 and/or 3.


== Way forward

  There are two (known) ways to approach denial of existence proofs.

    a. Dynamically generated NSEC RRs
    b. Pre computed "NSEC++" RRs that use some hash scheme to 
       obscure the namespace

  The requirements document that we have is implicitly based on 'b'
  type solutions and can be used for further development. We have
  heard about 'a' type solutions but have not seen them
  documented. These type of solutions, that require on-line keys, may
  provide fine interim solutions but unless they are documented in an
  I-D we cannot consider them.

  Therefore we propose that the working group, iff there is critical
  mass, continues by merging the two NSEC++ proposals and produces one
  document. This will be a task on the editors team.

  However to be able to progress we really need to have to understand
  the (conflicting) requirements and set some priority in order to get
  to a set of requirements that the group can consent with and on which
  editors can base their work..

  We feel that the requirement matrix has not yet received sufficient
  review and would like this group to look at the requirement document
  and the requirement matrix [1]. Please ask questions. (e.g. how come
  (11,17) is green?) and make your comments.

  If possible people should argue their preference for requirements
  that cannot be reconciled (e.g. the opt-in type 11 is preferred over
  complete non-existence from 17). With any luck we can compose a list
  of "reconcilable requirements".


We hope that this summary provides sufficient ground for a constructive
and cooperative way forward.

Olaf and Olafur
 DNSEXT Co-Chairs.


[1] requirement matrix is at:
http://www.links.org/dnssec/requirements-matrix.htm


For fun, amusement and astonishment, slightly related to this topic:
http://lists.gnu.org/archive/html/savannah-hackers/2004-10/msg00770.html

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>