What is the point of keeping old keys around? So we can sign “something” in case an old DNS server gets turned back on? What is the downside? Leaving old key material around that could be stolen. (Is someone going to count the HSM’s every time a safe is opened, for example?) We’re trading ease of resurrecting old machines against the security of the DNSSEC world. Like Mike said: DO NOT KEEP OLD KEYS. If you think you’ll need something signed, then sign the new key and then destroy the HSM.
The DNSSEC Practice Statement for the Root Zone KSK Operator [1] section 6.5 says: After a RZ KSK has been removed from the key set, it will be retained after its operational period until the next scheduled key ceremony, when the private component will be destroyed in accordance with section 5.2.10. And section 5.2.10 says: When required, the RZ KSK Operator destroys RZ KSK private keys in a manner that reasonably ensures that there are no residual remains of the keys that could lead to the reconstruction of the keys. The RZ KSK Operator utilizes the zeroization function of its hardware security modules and other appropriate means to ensure the complete destruction of RZ KSK private keys. When performed, private key destruction activities are logged as part of a key ceremony. As I understand this, PTI is bound by the DPS to destroy the previous KSK at "the next scheduled key ceremony" or update the DPS to state otherwise. jakob [1] https://www.iana.org/dnssec/icann-dps.txt
On 4 Apr 2019, at 6:56 am, Jakob Schlyter <jakob@kirei.se> wrote: As I understand this, PTI is bound by the DPS to destroy the previous KSK at "the next scheduled key ceremony" or update the DPS to state otherwise.
I am aware of this, but I am also aware that not every thought I had back in 2008 or so is true today. With hindsight I am sure that many thoughts I had back then were not true then or now! I’m not in favour of retaining KSK-2010 forever - but I think destroying it in the next regularly scheduled key ceremony abruptly curtals the deployment of any possible tools that may allow reactivation of a dormant resolver to boot itself into a trust relationship with the current key based on its obe trust in a prior key. It would be preferable imho to have some time to think about this issue some more. It may turn out to be be silly or impractical, in which case the delay in the key's destruction has not had any particular downside. but there is the possibility that such a tool may be feasible, which would remove one more impediment to a regular and frequent KSK roll. Previously I suggested to pause the destruction process 24 months. Still seems like a small time penalty to pay to allow us a bit more think time here. So, as is evident from my response, I don't believe that the DPS is chiseled in an immutable granite slab. I think it can and should be changed as required to reflect an evolving understanding of our currently known requirements for KSK management in the root zone. Geoff
On 4/3/2019 4:24 PM, Geoff Huston wrote:
I’m not in favour of retaining KSK-2010 forever - but I think destroying it in the next regularly scheduled key ceremony abruptly curtals the deployment of any possible tools that may allow reactivation of a dormant resolver to boot itself into a trust relationship with the current key based on its obe trust in a prior key
I have yet to hear any credible approach that would allow a dormant resolver - WITHOUT SOFTWARE UPDATES - to boot itself into a trust relationship based on the prior key. Seriously - if you're updating the software.... update the keys. No dormant resolver knows how to get from the 2010 key to the 2017 key without replaying already signed RRSets over a period of 60 some odd days. The software does not support it. And even then, you don't need the 2010 key - you just need the signatures its already produced. Seriously, delete the damn key already. Or come up with a credible approach that doesn't begin with "maybe" or "i think" or "may allow" and that holds together through at least 4 email exchanges. Hoarding is a sickness that we need not inflict on the DNS root of trust. Later, Mike
(resent using the subscribed from address!)
On 4 Apr 2019, at 6:56 am, Jakob Schlyter <jakob@kirei.se> wrote: As I understand this, PTI is bound by the DPS to destroy the previous KSK at "the next scheduled key ceremony" or update the DPS to state otherwise.
I am aware of this, but I am also aware that not every thought I had back in 2008 or so is true today. With hindsight I am sure that many thoughts I had back then were not true then or now! I’m not in favour of retaining KSK-2010 forever - but I think destroying it in the next regularly scheduled key ceremony abruptly curtals the deployment of any possible tools that may allow reactivation of a dormant resolver to boot itself into a trust relationship with the current key based on its obe trust in a prior key. It would be preferable imho to have some time to think about this issue some more. It may turn out to be be silly or impractical, in which case the delay in the key's destruction has not had any particular downside. but there is the possibility that such a tool may be feasible, which would remove one more impediment to a regular and frequent KSK roll. Previously I suggested to pause the destruction process 24 months. Still seems like a small time penalty to pay to allow us a bit more think time here. So, as is evident from my response, I don't believe that the DPS is chiseled in an immutable granite slab. I think it can and should be changed as required to reflect an evolving understanding of our currently known requirements for KSK management in the root zone. Geoff
On 4 Apr 2019, at 1:59 am, Salz, Rich via ksk-rollover <ksk-rollover@icann.org> wrote: If you think you’ll need something signed, then sign the new key and then destroy the HSM.
It may be that this is all we might need to do. But the days of PTI making pre-emptory decisions on such matters are probably long gone, if they ever existed. Even if all we would like from the KSK-2010 is to sign over KSK-2017 then its my understanding that the PTI requires some form of community consensus that this is an appropriate final use of KSK-2010 before its destruction. (I am not sure if this use of KSK-2010 would be within scope of the existing DPS or not, btw). Geoff
participants (5)
-
Geoff Huston -
Geoff Huston -
Jakob Schlyter -
Michael StJohns -
Salz, Rich