Hi Micha, I think you are correct regarding the specific scenarios where we should activate the disaster recovery plan and call the RKSH. Our goal with this HSM rollover is to keep the operations running smoothly and for the transition be as least disruptive as possible. Like you, we examined different scenarios, and our conclusion was that it's best is to keep the same Domain and CO credentials between signing and backups HSMs. As you can imagine, Backup HSM are around 40% less expensive than the signing HSMs, and as we explained they will have staggered lifecycles. An important part of the security of the KSK is also trust perception. If one can trust the KSK, one can trust DNSSEC, and for that reason we are open and transparent. The TCRs play a very important role in that trust perception. Each TCR, including RKSHs, are ambassadors, and they are dispersed around the globe so they can talk about the KSK and promote DNSSEC in their respective communities. In my personal opinion, I envision the possibility of a 3rd KMF (with similar security controls as the other 2) for backup and recovery purposes only. I don't want to open a can of worms, lol, but we could also find other purposes for such a facility like standby keys, etc. So, the RKSH could have a more active role and with the current credential schema, and we would be operationally prepared for such a scenario and others yet to be envisaged. Again, that is just my personal opinion, and should by no means be interpreted as anything else. Thank you and best regards, -- Andres Pavez Cryptographic Key Manager On 3/5/24, 08:57, "Micha Bailey" <michabailey@gmail.com> wrote: Hi Andres, I’ve been thinking it through and rereading the various materials, and I’m still not sure I understand why it’s necessary for the RKSH role to still exist in this new constellation. If the Backup HSMs were to have their own separate CO credentials held exclusively by RKSHs (and if it weren’t possible to copy keys between signing HSMs), such that restoring a backup required their involvement, or if backup HSMs were stored at a separate location (e.g. on a different continent, although if both coasts of the USA are rendered uninhabitable I suspect there are more pressing concerns than maintaining the integrity of DNSSEC) and not only within each Safe 1 alongside the signing HSMs, that would at least be a distinct role that comes into play in a DR scenario, similar to the current situation. But if the SO and CO credentials are planned to be shared between the signing and backup HSMs, rendering the RKSHs’ credentials a strict subset of the COs’, and given they’re always stored together, then it would seem that the role is rendered obsolete, as there doesn’t seem to be any scenario where any HSMs would be accessible and functioning but the CO credentials (which are stored on-site) are all lost. Even in the unlikely event that somehow all signing HSMs are lost but the backups remain (e.g. a manufacturing defect that manifests in all of them simultaneously since they’re from the same production run, which spares the backups because they’re from a different batch, or if the backups are somehow more durable/hardened or less volatile/sensitive or something, which is the case with the current APP backup smart cards), if I understand correctly the CO credentials are sufficient to initialize a new HSM and restore the key material from the backup HSMs. For that matter, that raises the question of why the backup-specific HSM SKU is necessary, as opposed to simply having an additional full-featured HSM as a backup — are the Backup HSMs significantly cheaper than the ones used for signing? Or is it infeasible to procure HSMs from different manufacturing batches? It seems that the only feature it offers over the USB HSM is the ability to store many partitions rather than just one, which isn’t applicable to this use case, and the inability to perform cryptographic operations, which could be considered a feature if it were to be stored and/or secured differently, but if they’re being stored identically to and together with the signing HSMs and fully sharing identical credentials, which are also stored onsite alongside the HSMs, that seems like it wouldn’t matter. If there’s any mistake I’ve made or angle I’ve missed here, I’d be happy to hear it. P.S. Regarding the domain key being split as M=5, and that being preferable from an optics perspective, that can of course still be done regardless. On Mon, Mar 4, 2024 at 5:53 PM Andres Pavez <andres.pavez@iana.org> wrote: 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@icann.org <mailto:ksk-rollover@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