Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

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

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).
--bill




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.