<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">*sigh* Sorry for top posting but...<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">It is a <u><b>monumentally bad idea</b></u>
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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">This is not a case where holding on to
the past preserves the future.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Later, Mike<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 4/2/2019 8:09 AM, Joe Abley wrote:<br>
</div>
<blockquote type="cite"
cite="mid:D983BC74-B4A1-450A-AA6E-A0EB0639C969@hopcount.ca">
<pre class="moz-quote-pre" wrap="">On 28 Mar 2019, at 09:45, Geoff Huston <a class="moz-txt-link-rfc2396E" href="mailto:gih@apnic.net"><gih@apnic.net></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 28 Mar 2019, at 12:08 pm, Kim Davies <a class="moz-txt-link-rfc2396E" href="mailto:kim.davies@iana.org"><kim.davies@iana.org></a> wrote:
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ksk-rollover mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ksk-rollover@icann.org">ksk-rollover@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/ksk-rollover">https://mm.icann.org/mailman/listinfo/ksk-rollover</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>