DNSSEC Key Management and Rollover - Five Strategies
DNS Security Extensions, the Internet standard for adding cryptographic authentication and integrity to domain name system look-ups, is now entering into the mainstream of security technologists worldwide. Recently, the Internet Corporation for Assigned Names and Numbers (ICANN) held a weeklong policy meeting in Brussels, Belgium discussing various aspects of the domain name and addressing business. If there was one major takeaway from the meeting, it was that 2010 is the year when DNSSEC, security extensions for the DNS protocol, will finally go into production on a global scale, and will require technologists to begin deploying it for their enterprises.
DNSSEC is on its way to becoming ubiquitous, and there are significant advantages for first-mover enterprises, which could be first to offer new products or services that take advantage of a more secure DNS system. Domain registrars such as Go Daddy, NamesBeyond and Dyn, registries such as the Public Interest Registry, Afilias and VeriSign, and ISPs like Comcast are all now beginning to put their DNSSEC plans into practice. DNSSEC will ultimately become as important as the SSL certificate, working together as the primary means of ensuring web transactional security.
Enterprises that place a high value on customer trust and in the security of their domain names are well advised to now develop strategies for signing their domain names. Unfortunately, DNSSEC is not a fire-and-forget technology. It relies on the ongoing integrity of the keys, meaning strong keys and periodic rollovers are a necessary addition to operational procedures. Managing DNSSEC in your enterprise means that you need to create specific strategies to manage the keys that underpin the security of your zone. Key management, therefore, needs to become a strategic skill to be acquired by technical staff.
Decide whether to manage DNSSEC yourself or outsource
First and foremost, you must decide whether to manage your DNSSEC functions in-house or outsource the function to a key management service provider. Your organization may decide that while it values the additional security offered by DNSSEC, it is more economical or simply less of a headache to turn to a trusted third party rather than burden existing technical and security staff with new and complicated tasks. Alternatively, some companies may decide that their existing internal risk management policies mandate that important security functions be managed in-house.
Create a plan for DNSSEC key generation and rollover
Enterprises that decide to manage DNSSEC internally need to generate and manage two sets of cryptographic keys – the Key Signing Key (KSK), critical in establishing the chain of trust, and the Zone Signing Key (ZSK), used to sign the domain name’s zone.
Both types of keys need to be changed periodically in order to maintain their integrity. The more frequently a key is changed, the less material an attacker has to help him perform the cryptanalysis that would be required to reverse-engineer the private key. Over the years, recommendations about key length and longevity have changed slightly. The general guideline today is that when RSA is the cryptographic algorithm in use the ZSK should be 1024 bits and rolled quarterly, while the KSK should be 2048 bits and rolled every two years.
While these time periods are good rules of thumb, it is inadvisable to roll keys on a precise, easily predictable schedule. An attacker could decide to launch a Denial of Service (DoS) attack at the time of key rollover. That is why I recommend the introduction of some "jitter" into your rollover plans by introducing a small random element to the schedule. Instead of rolling the ZSK every 90 days like clockwork, you could pick a time within a 10-day window either side of the otherwise predictable quarterly rollover date.
Document and exercise your key management procedures
It's extremely unlikely that attackers using cryptanalysis will ever compromise your private keys, but that does not mean that they will always stay secure. Key rollovers may be needed to respond to, say, a change of staff, especially when an employee with access to keys quits on less than amicable terms. In this respect, access to DNSSEC keys is no different than root administrator and super-user passwords in the hands of a disgruntled former employee.
Because scheduled rollovers will take place only a handful of times each year, and KSK rollovers even less frequently, it is important that the procedures for doing so are documented and kept fresh in the mind of the personnel responsible. Periodic tabletop or lab-based exercises can help administrators stay familiar with the process of key generation and rollover, making rollovers more efficient and less prone to costly error.
Store your private keys securely
The private components of both the ZSK and KSK need to stay private, so both need to be carefully controlled to prevent compromise by attackers. Generally, the KSK can be stored entirely offline, under layers of physical security and access control, with an air gap separating it from the network. With the ZSK, you may need to grant real-time access over the network if you anticipate making frequent changes to your zone. In that case, it is crucial to tightly control physical and network access to the server on which the ZSK is stored, limiting access to only authorized personnel and applications within your organization. Make it a matter of policy to not rely on a single individual.
Always keep two sets of DNSSEC keys
Resolvers at ISPs and other organizations already cache DNS records for performance reasons and this practice will not change with the introduction of DNSSEC. You need to ensure that cached, signed data about your zone remains validatable even during and immediately after a key rollover. If a resolver has cached data signed with an expired key, attempts to validate signatures with the new key will fail, making it appear as if the records have been compromised.
For this reason, it's advisable to have two sets of keys in the system, one live and one "on deck" and ready to go. To begin the rollover you switch to making the “on deck” key live and using it to you’re your domain name’s zone. You need to keep the first key, the previously live key, in the zone for a period of no less than two times the maximum Time-To-Live of the data or until the last signature record created with the first key expires, whichever is greater. This will ensure that all caching resolvers will have expunged any data associated with the expiring key. After that, the first key can be safely removed and replaced with the second, and a newly generated third key can be placed "on deck", ready for the next rollover.
Like any new technology, there will be a learning curve with DNSSEC, particularly if administrators are not already familiar with public key cryptography. This is why your practices and policies need to be well-documented, exercised and adhered to. And as more and more applications become available that support this technology, the benefits of a strong key management and rollover policy will begin to show returns.