On 30 Sep 2010, at 20:04, Joe Abley <jab...@hopcount.ca> wrote: > > I don't follow your logic. > > You seem to be saying that trust-history, which uses keys that should not be > trusted, is better than using the root-anchor repository, where there are > still some open questions.
I am making a distinction between bootstrapping and normal operations. A key that should not be trusted for normal ops may still be useful for bootstrap. The threat we are trying to deal with is a combination of a root KSK compromise and widespread attacks on software that is bootstrapping its DNS trust anchor. (Happily the first is unlikely and the second is a narrow target.) With trust anchor history in the DNS, a validator can start from a stale trust anchor, confirm that it is stale, update it to a provisional trust anchor, start its DNSSEC service, use the working DNS layer to obtain additional signatures that affirm that the provisional trust anchor is in fact OK, then make the service available to other users. Without trust anchor history, you start off with a trust anchor that is broken, and the only option is to downgrade to insecure DNS and use that to get the new trust anchor and its signatures. It seems to me that keeping the trust anchor history in the DNS should make it possible to reduce the attack window a lot. This is particularly true if the history zone has a short delegation chain from the root, to minimise the number of insecure queries a bootstrapping validator must make. > Isn't the right approach to answer those open questions? I think the answer requires a solution to exactly the same problem, except the keys and signatures are at higher levels in the protocol stack. How does a bootstrapping device deal with a rollover of the IANA web server's certificate's CA? Or of the special CA that IANA uses to sign the root KSK? The policies and procedures for managing the root zone keys are well documented and performed in the open. It is all very impressive. If you want bootstrapping to be as convincingly secure, you are going to have to duplicate all this ceremonial for the higher level keys. This seems redundant to me. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
