Re: DNSSEC in public

[bmanning () vacation karoshi com]

> > about for doing DNSSEC in the public, using either a "root" key and/or 
> > possibly having master keys pulished in WHOIS?
>
> there is no plan i know of involving master keys published by whois.  (that's
> sort of a chicken-or-egg approach, since you'd be using dns to figure out what
> whois server to ask.)

        although that has been proposed as a method (one of several)
 
> > I guess my question is: is there even something up for discussion at this 
> > point?  I know it's early in the game.
>
> the official plan is, every zone's zonesigning key is signed by that zone's
> keysigning key, and that zone's keysigning key is signed by its parent zone's
> zonesigning key.  thus, every zone is at the mercy of its parent zone's
> deployment schedule, and nothing is really possible until the root zone is
> signed, since that will allow the TLD's to sign, which will allow SLD's to
> sign, and so on down the tree.

        not exactly true, the use of Secure Entry Points ad/or Trust Anchors
        is a fine way to "boot-strap" the process...  DLV is yet another.

> this stuff works in the lab, but there are several pieces still missing:
> 1. distributing and updating the root zone's keysigning key
>
>         some say, make the key, keep the private part save, publish the
>         public part on IETF T-Shirts, and let everybody hardcode it, and
>         if we ever have to change it, we're completely screwed.

        s/if/when/  -- which begs the question, why do it at all if we 
        KNOW we are going to be screwed.

        
>         some say, delay deployment until we have a secure way to "roll"
>         new root keysigning keys out.  this is a protocol change, and will
>         have to take into account embedded and rarely-connected devices.

        perhaps it is not a protocol change, but that discussion occurs on 
        the DNSEXT wg list.

> 2. figuring out who would be trusted to hold the root zone's keysigning key

        there-in lies the path of madness... which is why SEP/TA and even
        perhaps DLV makes sense.

> my own views are: (1) hardcode the root zone keysigning key, and hope
> there's an in-band key-rollover protocol ready to roll out before the first
> time we have to invalidate/replace/revoke this key; and (2) use DLV to get
> deployment started, and hope that the root zone and the most compelling TLD's
> are all signed before DLV reaches its built in crippleware scaling limit.

        imho, jumping w/o a parachute...  but ymmv.

> Paul Vixie

        other methods, used in the lab for key distribution include finger,
        ixfr, and the usual OOB suspects (in source distribution, publication
        in periodicals, via RSS feeds and a few others).
--bill