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.