Re: [DNSOP] draft-ietf-dnsop-dnssec-trust-history - discussion

["W.C.A. Wijngaards" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi dnsop,

On 09/10/2010 01:24 PM, Stephen Morris wrote:
> Colleagues
> 
> Although draft-ietf-dnsop-dnssec-trust-history (the DNSSEC Trust
> Anchor History Service) is a working group item and the editor has
> received a number of private comments on it, there has actually been
> relatively little discussion of the draft on the list, either pre- or
> post-adoption. If the draft is to go forward, it must represent the
> consensus of the working group.  To show that, we need people to
> comment on it and to support it.
> 
> So, to gauge feeling and to trigger discussion, could the chairs
> please have your views on the following issues:
> 
> 1. Is the situation addressed by the draft - that of a validator that
> has been offline or that has missed an (emergency) rollover needing
> to reconfigure itself - a problem that needs to be solved?

Yes, I think that problems needs a solution.  If you miss the
couple-week KSK rollover, RFC5011 cannot catch up your root anchor.
Maybe not a problem in the ISP-space (who are always online), but for
widespread deployment.

> 2. If the answer to (1) is yes, is the idea of using DNS the best way
> to do it?

Well, one way is to have the OS update handle it somehow.  But then the
OS update has to handle it.  Perhaps the OS update requires domain names
to resolve (remember, the world is bogus when the root trust anchor no
longer works; port distributions and mirrors may not work).  Also such
an OS update, if it is secure, would rely on exactly another key that is
that old.

Another solution is a vendor-update solution, i.e. an ISC or an
NLnetLabs or other-vendor key which is used to fetch a new root key.
Such a key would need to be kept as safe as the private key for the root
to be useful.

Another solution is to fetch the root key fresh from the iana website.
And check that it is correct using another key (which is necessarily
just as old): the PGP key or the https certificate.

Trust history, then, does not require additional keys.  It could run
over TCP (i.e. fetch a text file), but recall that domain names are all
bogus.

So, without saying I really want to do one of them, I would like to
promote deployment of DNSSEC, and include a 'foolproof' root trust
anchor (or deployment-method description or handy shell-script to
reinitialise).

Initially, in IETF fashion, I went immediately to solution, and went for
an in-band (since no DNS service), not-rely-on-other-key and
safety-provided-by-root-team solution.  Maybe that was wrong, I would
like, however, to promote DNSSEC deployment towards the (more likely
down or offline) end-hosts, and something needs to be done to make it
possible to have a fluent KSK rollover for the root: I think it is very
important to make this as easy as possible, so that new algorithms or
updated key parameters can easily be introduced.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkyONu0ACgkQkDLqNwOhpPhcUACglbU+GsCIKmZAC69Q994K82w+
PpkAoIHZECi6raEFZ+OtvmJOsDnet8mo
=N0LK
-----END PGP SIGNATURE-----