[ksk-rollover] Retention of the 2010 KSK

[Joe Abley]

On 3 Apr 2019, at 05:10, Olaf Kolkman <kolkman at isoc.org> wrote:

> It occurs to me that the requirements are probably straight forward.

This seems like a bad sign!

> Key N signs Key N+1 with a time of signature timestamp. Seems to me that writing down how the bits are stored is a short exercise.

Back when Wouter proposed a similar mechanism, years ago (TALINK? something like that) my objection to it was that a compromise of any key along the chain breaks it in ways that are not trivial to signal to a relying party, remembering that the kind of relying party we're apparently trying to accommodate include those that have been sitting on a shelf for five years but still have aspirations about being secure.

I find Mike StJohn's cautionary shouting about key hoarding quite convincing.

The more keys we hoard the harder it is to avoid compromise, remembering that compromise doesn't just mean the results of an attack but could also include accidental non-availability of old keys if we have systems that assume that they are hanging around.

The more I think about this, the more I'm persuading myself that my reaction to Wouter's proposal was reasonable at the time and is also reasonable now. I should also listen to MSJ more, which seems like a good slogan for a t-shirt.

We want the system as a whole to be simple; we want to minimise the failure points. We also want devices that have been sitting on the shelf for five years to be patched, because validation is really the least of their problems and they're probably about three minutes away from being pwned.

Perhaps "revoke the key; destroy the key; move on" is really the simplest and best answer.

We have the problem of how to bootstrap a security-aware resolver in any case, regardless of whether we think the warehoused validator use-case is a signifiant one.

I still think Geoff's suggestion that we hold onto KSK-2010 for a constrained period while we all convince ourselves that the existing plan (destroy the keys after they are revoked) is ok, but it's important to acknowledge as Geoff did that the answer may be that there's no good reason to keep them around longer and we should proceed as originally planned and destroy them.


Joe

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