[ksk-change] Keeping two KSK keys long term
Tomofumi Okubo
tomofumi.okubo at gmail.com
Thu Oct 2 16:54:23 UTC 2014
Yes, I agree that building another KMF is not the only way of introducing the standby key.
Cheers!
Tomofumi
> On Oct 2, 2014, at 9:02, Richard Lamb <richard.lamb at icann.org> wrote:
>
> Yep. That's what Tomofumi and I had been considering doing with the current
> setup as well. -Rick
>
> -----Original Message-----
> From: ksk-rollover-bounces at icann.org [mailto:ksk-rollover-bounces at icann.org]
> On Behalf Of Joe Abley
> Sent: Thursday, October 02, 2014 8:42 AM
> To: Jakob Schlyter
> Cc: ksk-rollover at icann.org
> Subject: Re: [ksk-change] Keeping two KSK keys long term
>
>
>> On 1 Oct 2014, at 17:15, Jakob Schlyter <jakob at kirei.se> wrote:
>>
>>> On 1 okt 2014, at 23:00, Michael StJohns <msj at nthpermutation.com> wrote:
>>>
>>> Having two keys - in the trust anchor set - should be the minimum steady
> state. It means that you can compromise one of them and still recover
> without needing to do a full trust reboot.
>>
>> That only makes sense if you maintain and protect the keys separately,
> something that comes with a considerable cost. We did considering this when
> the current Root DNSSEC was engineered, and IIRC the cost/benefit analysis
> did not justify such a scheme.
>
> I think it's still worth considering, though. It seems possible that we
> discounted the possibility of secure storage of multiple sets of keys with
> different threat models too early because we assumed it would require double
> the facility cost.
>
> For example, a standby key could be stored in key shares across the existing
> two facilities such that the threat model is usefully different to the
> production key (e.g. such that you'd need to attack both facilities to
> recover the standby key, whereas you only need to attack a single facility
> to compromise the production key).
>
>
> Joe
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover
More information about the ksk-rollover
mailing list