March 2024 - ksk-rollover - lists.icann.org

Policies and procedures for Root KSK operations
by Micha Bailey March 5, 2024

March 5, 2024

Is there any estimate for when updated versions of the [various policies, procedures, etc.](https://www.iana.org/dnssec/procedures) are expected to be published, addressing the changes that are necessary to accommodate the HSM migration? It seems to me that significant parts of the concept need to be reworked. If I understand correctly, today the RKSHs hold a copy of the SMK, which otherwise exists only on (and is exportable from) the HSMs, and is used to allow for the use of the key backup that only exists in the KMFs alongside the HSMs, such that the only scenario in which RKSHs are in play would be some catastrophic event that destroys/tampers all HSMs while not physically destroying the KMFs to the extent that the application backup cards are inaccessible. With the new HSMs seemingly allowing backups exclusively to other HSMs, which presumably would not be any more hardened/less volatile than the main operational ones when it comes to environmental factors, is the RKSH role still relevant? As far as I can tell, the new HSMs don’t have any type of credential that would be required in a backup recovery situation that wouldn’t be similarly required in more mundane scenarios such as normal replacement of HSMs over the lifespan of the keys. Hypothetically there could be dedicated backup HSMs, with CO credentials held exclusively by the RKSHs, but that would seem to not align with the general concepts that seem to underlie the processes in place, which prioritize availability and tamper-*evidence *over strict security (e.g. with the CO credentials themselves all being stored onsite, in order to explicitly allow for forced entry, drilling, etc. when there’s no better option). The only scenario that comes to mind is would be if backup HSMs were introduced that would be stored offsite, outside the KMFs, whereby the RKSHs would provide an additional level of security, but that doesn’t sound particularly likely.

2 3

Thales Luna Credentials questions
by Will Tubby March 4, 2024

March 4, 2024

Hi, I have a few questions about the key cards. >From looking at the document linked in response to mike I believe that the CO and SO cards act the same as they did on the Keyper. It also appears that the AAK and APP cards are combined to form the domain cards. Is this correct? I can not seem to find an alternative to the OP cards, is there a reason for this. Additionally I can not seem to find a replacement for SMK cards. I attempted to investigate myself and found that when the SMK cards were used to set up a new HSM only 3 cards were used and they were already in the KMF. I thought that SMK cards are held by RKSHs and that 5 are required, not 3. Also a backup HSM is mentioned in the document. Is this in place of an APP card? What credentials will be required to transfer a KSK to a new HSM? What credentials will be required to apply existing cards to a new HSM? What credentials will be required to decrypt the KSK backup? Kind Regards Will

4 6

ICANN to generate new KSK
by James Mitchell March 4, 2024

March 4, 2024

ICANN has announced the schedule to generate the next KSK. Generating a new KSK restarts the process announced last year, which was suspended after it was identified that a supplier of key equipment used to store the KSK (known as a Hardware Security Module, or HSM) would be exiting the business during the expected lifespan of the new KSK. The next KSK will be generated on new Thales Luna USB G7 HSMs. The announcement and information regarding the new HSMs is published at https://www.icann.org/en/announcements/details/icann-to-generate-new-dns-cr…. James Mitchell IANA

5 6