The recent discussion about standby keys has made us to think about this topic. We have come to a conclusion and would like to share the idea with you. Please share your thoughts.
Our idea: The support of standby keys in OpenDNSSEC can be deprecated, because it can be handled outside the system. - What are standby keys? Keys that we can rollover to in case of an emergency. - What is an emergency? The key has leaked; it has been broken using crypto analysis; system failure with no way of recovering; etc. - What is the difference between an emergency rollover and a regular rollover? They are equal, but you probably want to do the emergency rollover faster than the regular rollover. In DNSSEC, you need to follow the key timings in order to not break the chain of trust. To make the emergency rollover faster you need pre-generated and pre-published keys to circumvent the waiting time otherwise needed during regular rollover. - How do OpenDNSSEC currently handle standby keys? The user can choose in kasp.xml how many standby keys there should be (makes no sense to have more than one). The Enforcer creates the keys and follow the state of the key, so that there can be a safe rollover in the future. Standby ZSK is pre-published in the zone. Standby KSK are published as DS RR in the parent. - What is the improbable scenario? It is not so probable that someone have broken the key using crypto analysis. If someone has done it, how would you know? - What is the probable scenario? Either the key store has leaked to the outside world or that you have had a system failure that you cannot recover from. - What is the downside with the current solution? The standby keys are stored in the same key store as the other keys. This means that they get leaked or are inaccessible at the same time as the other keys. The code gets more complicated. The users gets confused by all the different types of keys and states. - What does the current solution actually give us? The possibility to roll the key faster in an event of crypto analysis. - Are there other events where you want to roll faster? Yes, might be. But have a look on the real world. Does it take long time to distribute the zone, let the DNSKEY RRset expire in the caches, and update the DS at the parent? You can probably do it within some hours. It might take longer time for TLD:s, but IANA is probably going to have a fast track for that. - What do we actually want to protect ourselves against? We want to protect ourselves against system failure (key leakage, inaccessible keys, malfunctioning system). That is why standby keys should be handled outside OpenDNSSEC. - How can you handle standby keys outside OpenDNSSEC? Generate your own KSK and publish the DS at the parent. Generate your own ZSK and pre-publish it in the unsigned zone. OpenDNSSEC will sign this DNSKEY and send it to the signed zone. - How do you activate the standby keys? Set up a new system. Import the standby keys to OpenDNSSEC. Add the DNSKEY of the previous ZSK and KSK to the unsigned zone, because they are needed for signatures that are still cached. Start signing the zone and publish it. After a safe period of time, you can remove the old DS and the post-published ZSK and KSK. - What is the drawback of handling this outside OpenDNSSEC? You have to make sure that standby keys have been pre-published long enough and that the old ZSK and KSK has been post-published long enough before you remove it from the unsigned zone, etc. This should not be a problem. Just take a long period of time. Just say e.g. 14 days. But it can be calculated. - Why should you use standby keys? If you want to be completely sure that you get 100 % uptime on your DNS. Compare the risk with the cost of maintaining standby keys. Do you agree that standby keys is out of scope for OpenDNSSEC and is something that can be handled by the system administrator and the security officer? // Rickard_______________________________________________ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
