[ksk-change] planned vs. emergency (was Re: [ksk-rollover] root zone KSK ...)

[Michael StJohns]

On 9/22/2014 10:29 AM, David Conrad wrote:
>
>   simple terms, be when a private key is lost or compromised.  A planned roll-over reduces the likelihood of that happening.
> If the risk is physical access, then the implication of a planned rollover is that that physical access occurs (much) more frequently than if the physical access is limited to the times when emergency rollover is needed.  As such, it actually increases the likelihood of it happening. What a planned rollover does do is provide more experience in the hopes that we can recover more easily.
>
> Of course, if the private key is lost or compromised, you can’t use 5011 for a rollover.
>

I'm going to use "the private key is permanently unavailable to the 
operator (and generally anyone else) for cryptographic operations and 
can't be recovered" for "lost"; and "the private key is available to a 
second party for cryptographic operations" for "compromised".  "Lost" 
and "Compromised" means it can't be used by the operator, but that an 
attacker can use it.  Feel free to indicate if those differ from what 
you meant.


Scenario:

  - Single trust anchor key, and the associated private key is lost. 
Impact:  No further signing of the root is possible, a complete trust 
reboot is necessary.  Chaos ensues.

  - Multiple trust anchor keys, and the associated private key for the 
active key is lost.  Impact:  The active key can't be revoked, but 
another existing trust anchor key may be activated to sign the DNSKEY 
RRSet.  Using 5011, a replacement for the lost previously active key can 
be added to the trust anchor key set.  The lost key is removed from the 
DNSKEY RRSet and transitions to the "missing" state permanently.  
Removing it from the resolver configuration requires a manual action on 
the part of the resolvers, but there is no security implication for 
leaving it there as the private key is not available.

- Single trust anchor key, and the associated private key is 
compromised.  Impact:  The root operator revokes the trust anchor key, 
and then initiates a complete trust reboot.  Chaos ensues.

- Multiple trust anchor keys, and the associated private key for the 
active key is compromised.  Impact:  The root operator revokes the trust 
anchor key to resolve the compromise.  It places one of the standby keys 
in active mode and re-signs the root DNSKEY RRSet.  It uses 5011 to add 
a stand by replacement for the revoked active key. After 30 days, the 
revoked key is removed from the DNSKEY RRSet and transitions from the 
revoked stage to the removed stage after the hold down period expires.   
The root zone is back to where it was prior to the compromise.

- Single trust anchor key and the associated key is both lost and 
compromised.  No further signing of the root is possible by the root 
operator, but an attacker can sign the root DNSKEY RRSets and possibly 
force the acceptance of a new trust anchor in some portion of the 
resolvers.  The root operator needs to initiate a complete trust reboot, 
similar to the first scenario, but unlike that scenario can't force the 
DNS into an appropriate error state to prevent the attacker from 
presenting data as valid.  Chaos ensues.

- Multiple trust anchor key, and the active key is both lost and 
compromised.  The root operator can't revoke the active key, but can add 
other trust anchors using 5011 and controls the publication of the root 
zone.  Some resolvers will be populated with rogue trust anchors by the 
attacker.  This will require a partial trust reboot. There won't be a 
total outage period, but resolver operators will need to manually remove 
the lost key.  Chaos ensues.

In general, the probability of losing the key material at the same time 
its compromised is far past astronomical given the current controls.  
There are multiple backups in multiple locations and the chances of all 
of those being unavailable to reconstitute the private key are near 0.  
You *might* be able to do it by placing large explosive devices, but 
even then its hit and miss.


So my scenarios where 5011 is useful are multiple keys, N-1 keys max 
either lost OR compromised, but not both.

You need to use a trust reboot on any single key scenario.  The only 
time you need to use it on a multikey scenario is if you both lose and 
compromise the key.


None of these scenarios are equally likely.