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 <http://www.isc.org/ops/dlv/>. -- Paul Vixie