North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: wrt joao damas' DLV talk on wednesday

  • From: Paul Vixie
  • Date: Mon Jun 12 17:42:12 2006

> I'd like to hear about DLV. For example, Randy Bush asked (twice) the
> following:
> > my question was a bit simpler.  what is the security policy that isc
> > plans to use over the content of the isc dlv registry?  and how will
> > the dvl trust key roll-over and revocation be handled?
> I would also like to understand the security policy, and to hear how DLV
> at ISC will handle key roll-over and revocation.

since joao is probably still sleeping-off the time shift from san jose to
madrid, i'll chime in here.  the last plan i saw was the same as the last
draft i heard about for what any other "important" zone would do with a
key that has to be hard coded in a lot of places: allocate more than one
KSK and an infinite lifetime.  use this KSK offline (only), to generate
ZSK's with short lifetimes that are in turn used online to sign the zone.

many are those argue that DNSSEC-bis, having failed to address key-rollover,
is unimplementable.  DNSSEC-ter may or may not come about (depending on the
contining faith and patience of those who funded DNSSEC and DNSSEC-bis) in
order to (a) prevent zone-walking, (b) allow for unsecured subdelegations,
and (c) automate key-rollover.  (that's NSEC3 and TAKREM in a nutshell.)

on the other hand i believe that DNSSEC-bis is good enough to solve some
real world problems, and that the thing that makes it unimplementable is
merely its dependence on cooperation between US-DoC, ICANN, and VeriSign
around the myriad issues touched on by the "sign the root zone" work item.
that's why ISC is helping (under contract to VeriSign and Nominet) with
NSEC3 and stands ready to help with automated trust anchor work as well--
these are important problems.

if hand-edited trust anchors backed by infinite-lifetime offline KSK's are
unacceptable to you, then you are already not a candidate for DNSSEC-bis
and you're going to be waiting for DNSSEC-ter.  so, no complaints about
the fact that DLV uses the only thing DNSSEC-bis specifies in that area,
unless you have a proposal for automated rollover that's as easy to
implement as DLV was, and IPR-unencumbered, in which case, send it over!

> > as providing a tld key registry is tantamount to emulating the root key
> > responsibilities of the iana, potential users should be rather concerned.

"tantamount" is an unruly word, it accuses without specification.  in any
case anyone who is concerned about DLV should seek alternatives, such as:

|   1. figure out why the root zone isn't signed and fix whatever it is.
|   2. design your own version of DLV (as sam weiler has done, long before
|      ISC's although i didn't learn this until later), publish it, and
|      urge adoption (find someone to run a DLV registry, implement the
|      validator side, and so on.)
|   3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code
|      for the validator side, start your own DLV registry.
|   4. go to IETF and say "i think something DLV should be a standard but
|      i don't like ISC's, so let's make an RFC together."

and i forgot to mention:

   5. forget about DNSSEC until all these problems are solved by others.

whichever (or whatever else related) you want to do, you can count on ISC's
support.  just don't count on ISC's inaction; ISC isn't adept at inaction.

that URL again is <>.
Paul Vixie