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

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

Dan, check out http://www.dnssec-deployment.org/

also Sparta has:
http://www.dnssec-tools.org/

and from some other place:
http://www.dnssec.net/ (no idea about quality on this, but it does
mention RIPE including an 'howto dnssec' :slight_smile: )

Perhaps one or more of these will de-mystify the dns-sec issue? :slight_smile:

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&gt;\.

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.

> 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