On 2010-09-13, at 10:36, W.C.A. Wijngaards wrote: > On 09/10/2010 01:24 PM, Stephen Morris wrote: >> > >> 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.
For the root trust anchor, I think a better solution is to retrieve a fresh copy from the IANA. The format and location have been well-specified, albeit not in an RFC (yet), and I don't see why this could not be automated. There are several methods provided for the integrity of the retrieved key to be checked. Perhaps I'm being overly optimistic about DNSSEC deployment in TLDs, but I think a realistic long-term solution for other trust anchors is not to use them (i.e. to use a single root trust anchor, and use DS records to publish trust anchors for other zones). >> 2. If the answer to (1) is yes, is the idea of using DNS the best way >> to do it? As I've mentioned before, the problem I have with trust-history is that it involves using old keys to make trust decisions about new keys. It is difficult to believe in the general case that old keys are entirely trustworthy. Presumably keys are rolled for a reason. Doesn't trust-history impose a requirement high standards of operational security for key materials which have long since fallen out of production, and hence extend the possible window for a key compromise long after the key has stopped being used? From an operational perspective this worries me. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
