[ksk-rollover] thoughts to the list as requested

[Joe Abley]

Hi all,

The question of whether and how often to roll the KSK seems to me to be the least interesting of all the work to be done around KSK management, but since it also seems to block discussion of any of the more entertaining subjects, the following is my opinion. You'll note the justification for the proposed end-state is missing, as are detailed suggestions for how we get there. Both are available on demand :-)

1. We should move briskly towards a steady state where it is obvious and unremarkable to all stakeholders and relying parties that the KSK changes from time to time. Nobody should bake a particular KSK into software; the responsibilities for tracking trust anchors within any particular software ecosystem should be clear; client-side machinery should be exercised regularly.

2. The schedule and processes involved in rolling the KSK on the IANA side will become practiced, unremarkable and routine.

3. A regular schedule of data collection will become possible, instead of ad-hoc coordination for individual rollover events, reducing cost and promoting consistency in what is collected and how it is stored and made available for analysis.

4. An emergency key-roll due to key compromise (of any number of flavours) will be expected, easy to execute and easy to understand from the client side. Contributing oil on the wheels might be long-timebase pre-publication of standby keys and the processes for an emergency roll closely resembling (or being identical to) processes for a scheduled roll.

5. It should be unnecessary for ICANN to ever have to do an outreach programme around a scheduled KSK rollover.

I imagine a future in which regularly-scheduled KSK rolls quickly become non-events. The degree of impact of each rollover can be expected always to be greater than zero because there's a lot of weird crap attached to the Internet, but by the regular and predictable cadence can be expected to help the measurable impact descend quickly into the noise floor. KSK rolls should become as unremarkable as the KSK ceremonies that happen now, almost 9 years after the first one.

The overarching theme though all of this is that ICANN stops taking responsibility for each and every key roll decision, and the responsibility for minimising impact on particular end-user communities, devices, etc is clearly and deliberately shifted to their individual network providers and vendors. This is a necessary and important step, and will result in the system becoming more stable and more resilient, not just in stable operation but also in the event of emergency rollovers.

Sticking a finger in the air, since Paul asked me to at the microphone in Prague, I would say that the schedule should be regular but not stressful, and should be possible with minimal change to the current periodicity of KSK management. To me that means we should roll every year, with the particular elements of the key roll process that happen in ceremonies (e.g. key generation, key import, secure destruction of retired keys) pinned to particular ceremonies within the year. Each ceremony's procedures always involves some element of a key rollover; key rollover is no longer exceptional, but normal.

Having all of this agreed swiftly would accelerate our pace towards the day that work can begin on more interesting topics like algorithm rollover, new approaches to trust anchor distribution, HSM vendor diversity, deployment of key management facilities to new jurisdictions, etc.


Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190402/08480146/signature.asc>