[ksk-change] planned vs. emergency (was Re: [ksk-rollover] root zone KSK ...)
Michael StJohns
msj at nthpermutation.com
Sun Sep 21 17:13:17 UTC 2014
This got stuck in my outbound queue for a few days.
On Saturday, September 20, 2014, David Conrad <david.conrad at icann.org
<mailto:david.conrad at icann.org>> wrote:
Tomofumi,
On Sep 19, 2014, at 11:46 AM, Tomofumi Okubo
<tomofumi.okubo at gmail.com <javascript:;>> wrote:
> The former is emergency roll and the latter is planned roll.
>
> The rollover we are discussing now falls under the latter.
Actually, I don’t think we’ve started the discussion on changing the
key as yet :).
Is there a need to have a different set of policies/processes for an
emergency roll vs. a planned roll?
Is a planned roll a proper subset of an emergency roll?
Yes and no. If you're using 5011 as the model, and you have two keys as
trust anchors, and one associated private key is compromised, then there
really isn't a lot of difference in proceedures. You revoke the
compromised key, and start the process of getting a new key accepted as
a trust anchor.
The emergency thing shows up when all of your existing trust anchor keys
are compromised. And there really isn't a way to deal with that
contingency, planned or not. Basically, if A[public] is your only
root trust anchor and A[private] is compromised, you're dead in the
water. You can attempt to add new B[public] keys to the trust anchor
set using 5011, but there's a good chance that your attacker is
attempting to dothe same thing. If the attacker revokes A[public] by
setting the bit and signing the root DNSKEY RRSet with that key, what
probably happens is that ALL data without subordinate trust anchors is
considered invalid by resolvers and rejected.
5011 gave very specific guidance on what needed to go into the root
DNSKEY RRSet to avoid this case - but the current RRSet and Trust Anchor
set are missing the second KSK.
Mike
Regards,
-drc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20140921/82c91345/attachment.html>
More information about the ksk-rollover
mailing list