Re: [dnsext] historal root keys for upgrade path?

[Joe Abley <[e-mail]>]

On 2011-01-31, at 05:41, Tony Finch wrote:

> Question: Is it in fact practical to keep the standby key in a manner that
> makes it unlikely to be lost or compromised when the live key is? (How do
> you know you haven't lost the standby key if you never use it?!) Perhaps
> it is possible to come up with a better replacement for RFC 5011, because
> no longer need to worry about managing thousands of trust anchors, so we
> could tolerate a more elaborate scheme for establishing trust in the one
> root key.

The DNSSEC Policy and Practice Statements for the root zone have been published for a long time -- there should be no mystery here.

There is no pre-generated standby KSK for the root zone.

If there *was* one, then it would presumably be generated using separate ceremonies and stored in deliberately different places from the current one (otherwise pretty much any compromise scenario for the production KSK might also invalidate the standby key). Even then there would still be elements in common, since the same organisation would be responsible for managing both keys. As you note, there are also operational challenges in maintaining a key that is not regularly exercised.

The root zone KSK management procedures and facilities are designed to minimise the threat of compromise: there are two separate, autonomous, well-guarded and well-monitored facilities; procedures are audited; ceremonies are scrutinised; etc. The approach is intended to minimise the probability of compromise.

RFC 5011 is a mechanism for scheduled key rollovers. There is always the possibility that emergency key rollovers will happen, and that 5011 semantics (in particular the 30-day dual-publish window) might not be followed.

I think the open question is not whether we need a better mechanism to accommodate scheduled key rollovers -- the open question is how best to bootstrap a validator that (for whatever reason) has no working trust anchor installed.


Joe