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

Tue Mar 5 16:56:30 UTC 2024

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 at 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 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 --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ksk-rollover/attachments/20240305/de7620d7/attachment.html>