|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: DNSSEC in public
> > 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
|