A first: ICANN will generate new DNSSec key

Rotating cryptographic keys is a security best practice, so it’s good news that ICANN has begun the process to change the root key pair underpinning the security of the DNS. While the chances of a misstep is small, the fact remains that changing the root key pair has never been done before. A mistake can potentially — temporarily — break the Internet.

No pressure, ICANN.

As the phone book of the Internet, DNS translates easy-to-remember domain names into IP addresses so that users don’t have to remember strings of numbers in order to access web applications and services. However, attackers can hijack legitimate DNS requests to divert users to fraudulent sites through DNS cache poisoning or DNS spoofing.

DNSSec solves the problem by using cryptographic key pairs to verify and authenticate the results of a DNS lookup to prevent these man-in-the-middle attacks. If the DNS response has been tampered with and the keys don’t match, the browser returns an error instead of directing the user to the incorrect destination.

“ICANN is planning to roll, or change, the ‘top’ pair of cryptographic keys used in the DNSSEC protocol, commonly known as the Root Zone KSK. This will be the first time the KSK has been changed since it was initially generated in 2010,” ICANN said earlier this year.

DNSSEC currently relies on the original 1,024-bit RSA key generated in 2010 for its root zone key. Six years is a long time to keep using the same signing key, regardless of how carefully it has been stored and protected. The landscape has also changed in the years since, as the 1,024-bit RSA keys are no longer considered secure enough for the modern web. With increased computing power, the chances of someone cracking the 1,024-bit key increases. It’s about time the root zone key signing key got updated to the stronger 2,048-bit key.

[ ALSO ON CSO: Attackers launch multi-vector DDoS attacks that use DNSSEC amplification ]

“If a key is old, it can be cracked. You don’t want to wait for that to happen before resetting the key,” says internet security pioneer Paul Vixie, currently the CEO and founder of Farsight Security. The rollover is “good cryptographic hygiene,” he says.

Changing the signing key doesn’t mean there has been a compromise. It’s a proactive measure to ensure that if the keys ever fall in wrong hands, the system remains secure because everyone has moved to a newer, stronger, key.

“We are exercising the software in a way that’s never been done before,” Vixie says, noting it’s better to have the rollover when there isn’t a crisis, rather than rushing because of a compromise and the security of the entire DNS is at stake.

Top to bottom

DNSSec works as a hierarchy, with different bodies responsible for each layer and signing the key of the entities in the layer below. Individual domain owners get their keys signed from the operator of the top-level domain. For example, owners with .com domains obtain the public key from VeriSign, which administers the .com top-level domain. Every hierarchy has a topmost layer, and for DNS, that’s the DNS root zone, and someone has to manage the ultimate key. The Root Zone Key Signing Key is managed by ICANN in conjunction with 12 other partners.

Ultimately, this rollover is a very sensitive process because the key signing key is the master key.

“DNSSec works by forming a chain of trust between the root (i.e., the aforementioned trust anchor) and a leaf node. If every node between the root and the leaf is properly signed, the leaf data is validated. However, as is generally the case with digital (and even physical) security, the chain is only as strong as its weakest link,” VeriSign said in a recent blog post outlining its plans to update its zone signing keys.

ICANN and volunteers from the global technical community have spent the last five years developing a multistep plan for the rollover. The first step, scheduled for this month, is to generate the new key signing key, then to distribute it so that ISPs, enterprise network operators, hardware manufacturers, and others performing DNSSec validation can update their systems with the public part of the key pair. The key pair will be generated in a hypersecure key management facility in the United States, and ICANN will securely store the private half of the key.

The public half of the key pair will be widely distributed to all the servers and devices relying on the DNSSec. The new key signing key will be available on the Internet Assigned Numbers Authority website in February 2017, and it will appear in the DNS for the first time on July 11, 2017. If the systems aren’t updated with the new public key, DNS will eventually break, and users will be unable to access portions of the internet. To make sure the operators have ample time to update their systems, the new keys won’t be used to sign domains until October 2017.

DNSSec will support both the old key signing key and the newly generated one until January 2018, when the old one is scheduled to be revoked. The secure destruction of the old key is set for March 2018.

“Having both keys together lets ICANN work out any issues,” Vixie says, noting that he doesn’t expect there to be any problems. “The teams involved have thought carefully about this.”

Spread the word

The hardest part of the rollover is getting the word out to the developers, administrators, and operators involved with DNSSec to be prepared to handle the update manually. Most of the organizations have been monitoring the upcoming change, and most systems are configured to obtain the new key once it’s available. However, there is always the risk of older hardware that’s not being actively maintained and won’t receive the new public key on time, which can impact users relying on that equipment.

ICANN manages one of the 13 DNS root server clusters, so it will be able to detect if there are any problems with the new keys or configuration problems with DNSSec.

Though introduced in 2010, DNSSec adoption has been slow, and there is disagreement among experts over its effectiveness. Even so, Vixie notes there has been steady growth, especially with the increase in DNS-based attacks in recent years.

It’s worth noting that ICANN wasn’t being negligent for not changing the key signing key earlier. When DNSSec was first introduced, the agreement was that the rollover should occur around every five years. The stakeholders involved in the decision picked that time span because they felt that a rollover should not be rushed, Vixie says. The next rollover after this one is expected in 2022.

DNSSec’s job isn’t to encrypt data on the site or in transit, but to ensure users end up on the sites they’re expecting to visit. ICANN and its partner root zone administrators are making sure that internet users will continue to be able to rely on DNS for the foreseeable future.