[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