[ksk-rollover] thoughts to the list as requested

[Matthew Pounsett]

On Tue, 2 Apr 2019 at 07:59, Joe Abley <jabley at hopcount.ca> wrote:

>
> 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.
>

On the subject of "nobody should bake a particular key into software...",
John Dickinson and I were entertaining the notion last week of writing up
advice to the effect that implementers should deprecate the notion of
non-5011 trust anchors; all configured trust anchors should be treated as
potentially doing 5011 rolls, always.  The reasoning being that if the
authoritative operator isn't doing 5011 there's no harm (it's a no-op), and
if they are then you don't want anyone accidentally hard-coding the trust
anchor statically.

I'm persuaded by the use case Paul Ebersman brought up, that some networks
may prefer to control when and how trust anchor updates happen on their
network, and so maybe this advice should be a statement about defaults,
rather than advice to never have static keys.

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.
>

DNS-OARC would be happy to continue coordinating data collection events
around the major steps in KSK rolls.


> 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.
>

Pre-publishing keys for the purposes of emergency roll in the event of
compromise sounds hard, and definitely expensive, given how they key
material is handled today.  I think a third signing party location would be
required, with each key stored in only two locations.  This is probably
achievable, but I suspect it'll take a while for people to agree on costs
and location, and then more time to get it set up.

We will likely want to come up with an interim plan for emergency rolls
until something like the above can be arranged.


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

Hear hear!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190402/ff8272c4/attachment.html>