[ksk-change] Keeping two KSK keys long term

Richard Lamb richard.lamb at icann.org
Thu Oct 2 16:02:42 UTC 2014


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5456 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20141002/8e1c7ada/smime-0001.p7s>


More information about the ksk-rollover mailing list