-----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----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
