The update is a serious and critical undertaking that will ensure greater DNS security 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. Related content news Is China waging a cyber war with Taiwan? Nation-state hacking groups based in China have sharply ramped up cyberattacks against Taiwan this year, according to multiple reports. By Gagandeep Kaur Dec 01, 2023 4 mins Cyberattacks Government news Apple patches info-stealing, zero day bugs in iPads and Macs The vulnerabilities that can allow the leaking of sensitive information and enable arbitrary code execution have had exploitations in the wild. By Shweta Sharma Dec 01, 2023 3 mins Zero-day vulnerability feature The CSO guide to top security conferences Tracking postponements, cancellations, and conferences gone virtual — CSO Online’s calendar of upcoming security conferences makes it easy to find the events that matter the most to you. By CSO Staff Dec 01, 2023 6 mins Technology Industry IT Skills Events news Conti-linked ransomware takes in $107 million in ransoms: Report A ransomware campaign linked to the ostensibly defunct Conti malware group has targeted mostly US businesses, in a costly series of attacks. By Jon Gold Nov 30, 2023 4 mins Ransomware Podcasts Videos Resources Events SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe