[ksk-rollover] Retention of the 2010 KSK CONSIDERED HARMFUL

[Michael StJohns]

*sigh*  Sorry for top posting but...

It is a _*monumentally bad idea*_ to retain revoked key material - 
especially when you don't actually have any way to use it.   There's a 
term for holding on to something when you think it *might* be useful in 
the future but have no idea whether it will be - it's called "hoarding" 
and can be a form of mental illness depending on how extreme it gets. 
Then there's the problem that as a "revoked" key, we really don't have a 
model for how the key material should be protected - e.g. it's not live, 
and it's not going to be live ever again but what happens if the worst 
case happens and the private key is compromised a year or so later?  
Especially since as a "revoked" key it should be harmless and maybe we 
don't take enough care to protect it.

As a general model, information can be created but not destroyed.  HSMs 
(and some uses of cryptography) allow us to finesse that a slight bit 
through a few different methods - e.g. never allowing the key material 
to leave the HSM, or if it does leave the HSM by never allowing the keys 
used to encrypt the backup to never leave the HSM (or the HSM smart 
cards).  The destruction of the key within the HSM used to encrypt the 
live signing key or its backup turns that information into nothing more 
than random bits.  The HSM substitutes programmed policy (i.e. we can 
use the key, but we can't see that key value) for information theory and 
allows for a semblance of destruction of information.

At this point, two things should have happened:  The 2010 key should 
have been removed from the HSM(s), and the HSM(s) should have changed 
its backup keys to invalidate all the externally held backup material 
for the 2010 key.  If both of these haven't happened, then we're not 
quite done yet.

Deciding on the fly that it might be a good idea to hold on to a key who 
for all of the 5011 resolvers is so many random bits, but for the 
non-5011 resolvers who may have not gotten a manual update of the 
revocation could still be used to sign the root DNSKEY RRSet doesn't 
seem to be to be either prudent or in keeping with the agreed upon key 
management plan. In fact it could be dangerous to keep that key around 
in any form.

So to recap:  1) No current resolver should have any way to use this key 
except to validate its revocation, 2) any resolver that is still able to 
use this key is mis-configured and vulnerable to getting bad 
information, 3) it's way in the future where you might have a resolver 
which could use this key safely (e.g. in a way that doesn't end up with 
the installation of bad trust anchors), and 4) given that we don't need 
to start from the 2010 state of the root trust anchor set for things 
programmed in 2019 and later, then 5) ITS A REALLY BAD IDEA TO KEEP THIS 
KEY AROUND

This is not a case where holding on to the past preserves the future.

Later, Mike

On 4/2/2019 8:09 AM, Joe Abley wrote:
> On 28 Mar 2019, at 09:45, Geoff Huston <gih at apnic.net> wrote:
>
>> On 28 Mar 2019, at 12:08 pm, Kim Davies <kim.davies at iana.org> wrote:
>>> Just confirming my mic comments:
>>>
>>> Our current schedule has us remove the 2010 KSK from our HSMs in one of our two key management facilities in May, and from the HSMs in the other key management facility in August. While perhaps not a complete specification, we’d need a strong indicator we need to retain the KSK longer ideally by May, and certainly no later than August, in order to defer the deletion and retain the capability to use it (i.e. to create a signature via a new mechanism that would endorse the subsequent KSK).
>> I am happy to provide my strong indicator to retain the KSK until further notice. We have not given up yet on the dream of dusting off some dormant resolver that has a trusted key state of KSK 2010 and using some signed chain mechanism that would automate the installation of trust in the current key. If the old key is destroyed then the dream gets destroyed too.
> I agree.
>
> It would be a low-cost exercise to at least retain the backup of KSK-2010 that already exists as key shares on smartcards in both facility and keep them there with the same chain of custody and physical security.
>
> There is no active plan to use KSK-2010 for anything, and so having it available on an HSM (and having it transferred to future HSMs when they are replaced) seems unnecessary, but the ability to restore it from backup to an HSM for use in the future seems sensible. We are some distance away from KSK rolls being routine; while they continue to be science projects we should keep our options open.
>
>
> Joe
>
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover


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