[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