What to expect when the internet gets a big security upgrade
Ready or not, the upgrade to an important internet security operation may soon be launched. Then again, it might not.
The Internet Corporation for Assigned Names and Numbers (ICANN) will meet the week of Sept. 17 and will likely decide whether or not to give the go ahead on its multi-year project to upgrade the top pair of cryptographic keys used in the Domain Name System Security Extensions (DNSSEC) protocol — commonly known as the root zone key signing key (KSK) — which secures the Internet's foundational servers.
Changing these keys and making them stronger is an essential security step, in much the same way that regularly changing passwords is considered a practical habit by any Internet user, ICANN says. The update will help prevent certain nefarious activities such as attackers taking control of a session and directing users to a site that for example might steal their personal information.
This Root KSK rollover from the 2010 KSK to the 2017 KSK was supposed to take place almost a year ago but was delayed until Oct. 11 of this year because of concerns it might disrupt internet connectivity to significant numbers of web users.
The KSK rollover means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, according to ICANN. Such resolvers run software that converts website names like networkworld.com into numerical IP addresses.
Internet Service Providers provide this service as do enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root's "trust anchor," ICANN states.
ICANN says it expects minimal user impact from the root KSK, but a small percentage of Internet users could face problems resolving domain names into IP addresses — which means problems reaching their online destinations.
The issue isn't widespread, but is still a concern.“There are currently a small number of Domain Name System Security Extensions (DNSSEC) validating recursive resolvers that are misconfigured, and some of the users relying upon these resolvers may experience problems,” ICANN wrote in a recent release. Recursive resolvers receive DNS resolution request and find the DNS server that can fulfill them.
Verisign recently wrote that earlier this year it began contacting operators of recursive servers that, when they reported only the old trust anchor. However, in many cases, a responsible party could not be identified, due in large part to dynamic addressing of ISP subscribers. Also, late last year, ICANN began receiving trust anchor signaling data from more root server operators, as well as data from more recursive name servers as the recursive name servers updated to software versions that provided these signals. As of now, percentages are relatively stable at roughly 7 percent of reporters still signaling the 2010 trust anchor, Verisign wrote.
So, what should enterprises and others expect from the rollover, should it occur? First of all, ICANN says users who rely on a resolver that has the new KSK and users who rely on a resolver that does not perform DNSSEC validation won’t see any impact. Data analysis suggests that more than 99 percent of users whose resolvers are validating will be unaffected by the KSK rollover, ICANN says.
As for enterprises, they should have already updated their software to do automatic key rollovers (sometimes called "RFC 5011" rollovers) or manually installed the new key by now. If they haven't turned on automatic updates, they must do so before Sept. 10, or the update mechanism won't have kicked in correctly in time for the rollover, Paul Hoffman, principal technologist at ICANN said.
“Note that they should do the update regardless of whether we get the go-ahead to do the rollover on October 11,” Hoffman said. “The new key is already part of the set of trusted keys being announced in the root zone, so it should be a trust anchor for everyone.”
A recent ICANN paper What To Expect During the Root KSK Rollover spells out some of the specifici concerns:
- If all of a user's resolvers do not have the new KSK in their trust anchor configuration, the user will start seeing name resolution failures (typically "server failure" or SERVFAIL errors) at some point within 48 hours of the rollover. It is impossible to predict when the operators of affected resolvers will notice that validation is failing for them.
- When this failure happens, if the user has multiple resolvers configured (as most users do), their system software will try the other resolvers that the user has configured. This might slow down DNS resolution as their system keeps trying the resolver that is not prepared before switching to the resolver that is prepared, but the user will still get DNS resolution and might not even notice the slowdown.
- If all of the user’s resolvers are not prepared for the rollover (such as if they are all managed by one organization and that organization has not made any of their resolvers ready), the user will start seeing failure sometime in the 48 hours after the rollover.
- Users will see different symptoms of failure depending on what program they are running and how that program reacts to failed DNS lookups. In browsers, it is likely that a web page will become unavailable (or possibly only images on an already displayed web page might fail to appear). In email programs, the user might not be able to get new mail, or parts of message bodies may show errors. The failures will cascade until no program is able to show new information from the Internet.
- As soon as operators discover that their resolver’s DNSSEC validation is failing, they should change their resolver configuration to temporarily disable DNSSEC validation. This should cause the problems to immediately stop.
- After that, the operator should install, as soon as possible, the KSK-2017 as a trust anchor and turn on DNSSEC validation again. ICANN org provides instructions for updating the trust anchors for common resolver software.
“This key rollover is not new technology; in fact, when the first KSK was added to the root zone in 2010, we knew that it would have to change at some point,” Hoffman said. “Doing the rollover will help make the DNS more robust by paving the way for other rollovers in the future as they are needed.”
MTCHT
ICT
TECHNOLOGICAL INNOVATIONS
POST
ABOUT US
NEWS
INTERESTING
INTERVIEW
ANALYSIS
ONLAIN LESSONS
