US government mandates? use of DNSSEC by federal agencies

Wed Aug 27 17:51:30 UTC 2008

Kevin Oberman wrote:
[..]
>>> Right.  The real questions are the clients and the trust anchor -- what
>>> root key do you support?
>> A distributed one. I personally don't really see an issue with
>> downloading a public key for every TLD out there. These keys could come
>> in a pack even by an OS distribution, nicely PGP signed et all...
>> Nobody in his right mind manages this per box anymore anyway, and
>> packages for distributions and auto-updates are well-present anyway.
>>
>> The presence of a key file can also mean to the resolver that one
>> can/has_to check dnssec results.
> 
> How do you propose to establish the initial trust for these keys?

One already trusts the distribution, taking Debian as an example, all
packages are signed by their key. I am already trusting them that they
don't install backdoors on my boxes (or make weak keys :) by installing
packages I install from their servers. Thus having them provide me with
those keys is simple for them, just package them up (which mean they
sign it), and let bind/resolver depend on that package. This would even
upgrade boxes which don't have the package yet, eg similar to the
ssh-vulnkey package which is now on all updated Debian and Ubuntu boxes
worldwide.

This takes care of all the distribution work, all the infrastructure is
there already. Same for Fedora/SUSE/Windows etc etc. You will need to
get the vendor to support this thing though, but if the vendor doesn't
do it, you won't either have a resolver which supports it, unless you
start doing custom installs.

Note that one can already easily make a package and put it in a local
repository which does exactly this. Which could allow one to have local
packages with keys for other domains, thus avoiding problems when a
higher key breaks, avoiding any disaster down the line.

> How will they be updated? NIST recommends rolling the zone keys
> every month and the key signing key annually. Files in distributions are
> way too static for these intervals. (I think NIST's recommendations are
> extremely excessive, but I am required to comply with them or explain to
> OMB why not.)

Never heard of apt-get update? :) People who don't upgrade their boxes
(even only the security updates, which this would fall under) don't
deserve to be on the Internet IMHO anyway.

I am pretty sure that for these kind of 'force-upgrades' which, if not
upgraded, would definitely break things, that there can be a mechanism
(which can be turned of) that auto-updates the package without intervention.

As for the interval, a month is not too bad for this, one should do
security upgrades the day they come out. There is one problem though,
and that is that keys should be 'overlapping', thus that there is no
hole where no single key is valid, give it at least a week or two for
everybody to upgrade.

> This is the reason for the DLV concept and it will be needed (in some
> form) at least until the root is signed and most likely until .com and
> .net are signed.

Having per-TLD keys distributed in this way would not even require that.
DLV's are a good thing though if they are not there yet, but you still
need to install a config snippet, having distributions do that would
save a lot of overhead/reinvention.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080827/3078b639/attachment.sig>