[ksk-rollover] Future rollover planning opportunities

[Geoff Huston]

> On 20 Feb 2019, at 4:29 am, Tony Finch <dot at dotat.at> wrote:
> 
> Fred Baker <fred at isc.org> wrote:
>> 
>> The key consideration is that key rollovers are a "usual" event, and as
>> such the key(s) should be something learned from the root and the root
>> servers, not something configured or compiled into the resolver
>> software.
> 
> However there has to be a bootstrap mechanism, and the only one available
> is for the validator vendor to provide an initial key set.
> 
> I agree that rollovers need to be routine (I think annual makes sense) but
> they have to be planned with software releases in mind. This might require
> keys to be generated and promulgated out of band a long time before they
> are published in the zone or used for signing. Then a vendor package can
> include root keys covering the next couple of years, say.
> 

There is something in your note Tony that I feel I should comment on. It gets 
to the heart of why the key gets rolled at all, in my view.

I could offer the view that there is a prevalent feeling (perhaps irrationally 
- who knows) that a very long-held key will get compromised at some time. Either
the tools to break the key will improve, or access to the key will no longer
work, or some other mishap. It seems foolhardy not to have some exercised
plan to roll the key to respond to such potential eventualities when or if the
unplanned disaster happens and we need to roll the key.

But then we enter into the next phase of the thinking - if we plan to roll the key
at some time in response to some operational incident then we probably
need to rehearse this plan.

And so we have this extended exercise of using RFC5011 to transition the key.
The plan has two parts - an extended ‘introduction’ of the new key and a
key switch. The procedure we use at present is a planned introduction and a planned
switch. 

If I were to guess at the thinking here, the plan is to allow us to decouple
this slightly - i.e. to introduce a backup key in a planned fashion and
to be able to switch keys either as planned process or in response to some
situation that compromises the current working key in some manner.

Your note seems to head down the path of planned switches, whereas I would offer
the view that the overall object here is to carefully rehearse the introduction
of backup keys, with the aim to be able to perform a key switch to a live backup 
with less notice than years or even months, if the need arises. While planning
key switches well in advance sounds like a decent approach, we should not fall
into the trap of thinking that the only way to perform a switch to a live backup 
is with such advance notice every time. 

my 2c anyway

 Geoff