[ksk-rollover] Policies and procedures for Root KSK operations

[Andres Pavez]

Hi Micha,
Please see my comments inline below.

On Mon, Mar 04, 2024 at 04:41:54PM +0200, Micha Bailey via ksk-rollover wrote:
> Is there any estimate for when updated versions of the [various policies,
> procedures, etc.](https://www.iana.org/dnssec/procedures <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.
> 

Yes, we expect by the end of March 2024 to have updated the DPS, the KSK Key Management Policy, and the KSK Key Management Procedure.

> 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.
> 

Correct. That is basically the worst-case scenario.

> 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.
> 

All TCRs, including RKSHs, will be assigned new sets of credentials based on the principle of least privilege. Crypto Officer credential sets will comprise CO, SO, Audit, and Domain credential types. To perform their role in backup restoration, the RKSHs will be issued CO and Domain credential types as required by the design of the Thales Luna USB HSMs.
 
The CO, SO, and Audit credentials will continue to use the minimum threshold of 3 of 7. The Domain credentials will however be issued using the minimum threshold of 5 of 7, providing equivalent controls to address the risk of collusion within the RKSH role. Note, unlike the Keyper HSMs that support the creation of sets of the same credential with different m-of-n values for quorum authentication, the Thales Luna USB HSMs support one m-of-n value for each credential type.
 
To prevent the RKSH from using their CO credentials in a 3 of 7 configuration, the Thales HSMs will be placed into secure transport mode prior to offline storage in the equipment safe, and will remain in this state at rest. Thales HSMs will only be taken out of this mode for use in future key ceremonies, after which it will be placed back into secure transport mode. Secure transport mode can only be activated or deactivated using SO credentials which are not assigned to RKSHs. Thales Backup HSMs will not be placed in secure transport mode which will allow the RKSHs to perform recovery operations using a combination of their assigned Domain and CO credentials combined with the creation of new SO and Audit credential sets, if required for disaster recovery.
 
A standard key signing ceremony where an HSM is used to generate quarterly signatures will require a combination of 3 of 7 SO and CO credentials from the attending Crypto Officers. The SO credentials will be used to toggle secure transport mode, and the CO credentials will be used to allow cryptographic operations such as signing.
 
When new HSMs or backup HSMs need to be introduced or a new key needs to be generated, a minimum 5 of 7 Crypto Officers will need to attend. This could alternatively be accomplished using at least 3 Crypto Officers, while the remaining two TCRs could be a combination of Crypto Officers or RKSHs. We envisage these types of events to happen approximately once every two to three years per facility, and therefore the operational impact is very low, and from an optics perspective, even preferable.

> 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.
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org <mailto:ksk-rollover at icann.org>
> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover>
> 
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

Best regards,
-- 
Andres Pavez
Cryptographic Key Manager
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4863 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ksk-rollover/attachments/20240304/716452f0/smime.p7s>