North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: DNSSEC in public
- From: bmanning
- Date: Mon Sep 12 16:05:43 2005
> > 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).