Dan, check out http://www.dnssec-deployment.org/ Marc Marcus H. Sachs, P.E. SRI International 1100 Wilson Blvd Suite 2800 Arlington VA 22209 www.hsarpacyber.com -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Dan Mahoney, System Admin Sent: Monday, September 12, 2005 6:15 AM To: nanog@nanog.org Subject: DNSSEC in public In response to a recent question I saw regarding DNSSEC on RIPE domains, I'd like to ask if there's any sort of draft or standard that anyone knows about for doing DNSSEC in the public, using either a "root" key and/or possibly having master keys pulished in WHOIS? I see a very experimental thing Verisign is doing for the .net zone, and also for some other opt-in zone, but I'm sure that's highly experimental at this point. I guess my question is: is there even something up for discussion at this point? I know it's early in the game. Thanks Dan -- "I can feel it, comin' back again...Like a rolling thunder chasin' the wind..." -Dan Mahoney, JS, JB & SL, May 10th, 1997, Approx 1AM --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------

danm@prime.gushi.org ("Dan Mahoney, System Admin") writes:

In response to a recent question I saw regarding DNSSEC on RIPE domains, I'd like to ask if there's any sort of draft or standard that anyone knows 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.) there are plenty of web sites that talk about the general field of deployment, most of which are all reachable via jacco's excellent www.dnssec.net web site. however, your question falls outside of the things most deployment experts are willing to talk about in public. since i've had quite enough coffee and maybe a little extra, i'll see what i can offer.

I see a very experimental thing Verisign is doing for the .net zone, and also for some other opt-in zone, but I'm sure that's highly experimental at this point.

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. 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. 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. 2. figuring out who would be trusted to hold the root zone's keysigning key some people distrust ICANN. others distrust US-DoC. still others distrust ITU, UN, and/or WSIS -- and some people distrust VeriSign. and of course, most of those entities don't trust most of the others. yet, those entities are largely responsible for the root zone today, and they have to learn to increase their mutual trust as well as their collective perceived trustworthiness, or there will be no DNSSEC deployment at the root zone level. one candidate-conclusion that leaps to mind is "this can't ever work". more charitibly, one might say that "it's not anywhere close to being deployable." 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. now for the disclaimers. i work at ISC, and we've been funded to work on DNSSEC for most of the last ten years. our BIND9 (9.3.x and soon 9.4.x) is as far as we know a complete implementation of the current (DNSSEC-bis) spec. it's free software, free as in BSD-style license. we don't make money from your use of our software, and when we do collect money (usually from support or software development), we're a non-profit corp with no shareholders so we can only spend our money on public benefit activities. oh, and one more thing: i'm the primary pusher behind DLV. DLV is the thing you're alluding to when you talk about the .NET experiment at VeriSign. DLV isn't experimental, ISC is going to run it as a full production service as a way to get dnssec deployment to begin even though there are a lot of things not quite ready yet. you can learn more about DLV at: <http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00807.html>. i hope this helps. and do remember to look at jacco's www.dnssec.net pages; he (wisely) does not delve into the root zone's political problems or the DLV controversy, but otherwise his site is a very complete and useful reference. -- Paul Vixie