meeting summary: 25 May 2005

[James M Galvin]

DNSSEC Deployment Working Group
25 May 2005


PRESENT:
    Steve Crocker
    Jim Galvin

    Allison Mankin
    Amy Friedlander
    David Blacka
    Ed Lewis
    Geoff Sisson
    Jaap Akkerhuis
    Jakob Schlyter
    Mark Kosters
    Mike St. Johns
    Peter Koch
    Ralph Droms
    Rodney Joffe
    Russ Mundy
    Sam Weiler
    Scott Rose

    jbr - does anybody know who this is?  this person did not respond to
    multiple requests for an identity.


REGRETS:
   Johan Ihren
   Olaf Kolkman
   Steven Cheung


SUMMARY


 - When can we have a technical workshop?

   During our last meeting we deferred most of the discussion of what to
   cover and when to hold a technical or interoperability workshop.  It
   was briefly noted that the RIPE Amsterdam meeting had the advantage
   of giving developers more time to prepare as compared to the IETF
   Paris meeting.  The suggested topic to cover in the workshop is the
   interoperability of epsilon implementations.

There is a question as to whether or not there will be implementations
of epsilon or NSEC3.

Ralph Droms indicated that Cisco will be implementing DNSSEC but he did
not expect to have anything in time for October.

Mark Kosters indicated that Verisign will be doing an NSEC3
implementation with OPT-IN (i.e., NSEC chain skips over unsigned
delegation).  They expect to be showcasing a server implementation in
the fourth quarter but October is likely to be too early.

Geoff Sisson noted that Ben Laurie had done an NSEC2 implementation.

Mike St. Johns indicated that Nominum will have DNSSEC ready by October,
subject to customer demand, but NSEC3 was not even on the table yet.

Allison Mankin summarized that it looks like there will be enough to do
something in October, perhaps even some early work in August at the
IETF.  She proposed a planning meeting at the IETF-Paris for a multi-day
event in October at the RIPE-Amsterdam.


 - Managing secure entry points and transitioning to a signed parent

   In an ideal deployment there would be a very low barrier to entry, an
   enterprise could sign its zone and get immediate external benefit
   from having done so, a parent (e.g., a TLD) would sign its zone
   shortly thereafter, and the transition to inclusion in the larger
   infrastructure would be straightforward if not transparent.

   A concern is the tension between an orderly, top-down deployment:

       sign the root
       sign the TLDs
       sign the second level zones
       etc.

   And a bottoms-up, islands of trust deployment:

       enterprises sign their zones
       enterprises "distribute" their public key
       when the parent is ready the public key is "moved up"
       etc.

   The tension arises from wondering if the trust models will converge
   into a single, trusted infrastructure, i.e., if second-level zones
   can proceed without their TLDs, will there be sufficient motivation
   for the TLDs to sign their zones?

   This concern is related to three of the 11 issues listed in the
   DNSSEC Deployment Roadmap:


     2. Timing of signing the root zone and/or management of islands of
        trust

     A DNSSEC signed zone operating without a signed delegation from
     their parent zone is commonly called an 'island of trust'; this
     issue deals with questions that arise when zones are signed but the
     root is not.

     This issue addresses non-root trust anchors.  At last reporting (16
     February 2005) there was a DNSOP document in last call that spoke
     to this issue.


     3. Root key rollover and distribution

     Procedures for initial distribution of the root public key,
     periodic rollover of the public key, and its distribution

     This issue addresses root trust anchors.  It is largely similar to
     Issue 2 but because it is the root you probably want a separate
     document so you can say more about security.  And, unfortunately,
     there are political issues.  The root is just another trust anchor
     but it is a "special" one.  Changing the root key will have an
     impact just in pure numbers, as compared to any other trust anchor.


     4. Trust anchor key rollover and distribution

     Procedures for initial distribution of the trust anchor public key,
     periodic rollover of the public key, and its distribution; needed
     in Isolated, Sparse or Dense deployment, or for some applications.

     This issue addresses trust anchors in general.  There are some
     issues that go with a secure apex based on a spectrum of how much
     you care.

Steve Crocker quickly summarized the "bidding" by noting

* DLV by Paul Vixie
* Alternative DLV by Sam Weiler
* Implementation of a third option by Andrews

These three may not be in sync.

Sam Weiler pointed out that there have been many lengthy discussions
about different ways to do this.

Steve stated that the concern, irrespective of the mechanism chosen, is
that we need a means to manage trust anchors when the TLDs are not ready
to go.  Russ Mundy generalized that to any parent not being ready as
opposed to just TLDs.

Jim Galvin asked if managing the trust anchors was separate from
incorporating existing public keys in islands of trust into the larger
island of the parent?  Steve agreed that point need to be covered also,
with Russ suggesting the incorporation is easy compared to managing the
trust anchors.

Steve asked for references to discussion, resolution, and testing
documentation.  Although there has been plenty of discussion, no agreed
resolution is apparent.


Mark Kosters expressed concern that any mechanism put in place that
reduces the motivation or dependency on a parent will likely stay in
place forever and delay ubiquitous deployment.

Steve suggested that a significant concern is that we have this great
technology but we fail.  The failure mode Mark is suggesting is somewhat
intermediate between that and full deployment:

    limited deployment, i.e., will not be universal

    provide this mechanism and you prevent broad deployment

Mark was also concerned that DLV introduces a single point of failure,
i.e., you have to reference things in the DLV zone.  Mike St. Johns
asserted that it exacerbates the problem of provable non-existence.
Mark added that it becomes a traffic sink.

The discussion closed noting that we need other folks to be actively
involved in this discussion, including Paul Vixie, Matt Larson, and
Johan Ihren.

Everyone is asked to review the relevant documents and we will pick up
this discussion next week.



 -- Regarding Issue 8 from the DNSSEC Deployment Roadmap:

      8. Computational and communication resources required

      Considers operational requirements for additional storage, CPU
      time and communication bandwidth and evaluates the affect these
      additional requirements may have on adoption and use.

    If available, Olafur and Jaap will present their material.

    * Olafur Gudmundsson

      Olafur Gudmundsson volunteered to create and maintain a list of
      metrics people should collect and use for reporting.  He noted
      that we needed metrics for both resolvers and servers.

    * Jaap Akkerhuis

      Jaap Akkerhuis noted that NL Netlabs had a simulation of CPU and
      storage requirements for DNSSEC.  Jaap agreed to get some material
      on the NL Netlabs activities for review.


Jaap Akkerhuis reported that NL NetLabs is discussing redoing their
previous work.  It is not yet committed or guaranteed.

Russ Mundy noted the paper put forth on the mailing list by Bill
Manning, for which Sam Weiler posted a detailed summary.  The short
summary is that the conclusions are inconclusive because there seem to
be factors that are not addressed.