meeting summary: 25 May 2005
James M Galvin
galvin at elistx.com
Mon May 30 15:06:44 EDT 2005
DNSSEC Deployment Working Group
25 May 2005
Mike St. Johns
jbr - does anybody know who this is? this person did not respond to
multiple requests for an identity.
- 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
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"
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
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
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
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
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.
More information about the Dnssec-deployment