60m internet users risked ejection in ICANN security update - ISPs fault
60m internet users risked ejection in ICANN security update - ISPs fault

The update of the Root Zone Domain Name System Security Extensions (DNSSEC) in what is called a ‘key signing key (KSK) rollover', was originally planned for 11 October.


Craig Stewart, VP EMEA, Venafi, said: “The fact that ICANN is thinking about delaying the cryptographic key changes is very disappointing. While it's understandable that it wants to minimise the disruption to users, the fact that KSK had to be delayed points to a major problem – companies simply don't have the control over their cryptographic keys that is required. This lack of control is at the heart of the developing machine identity crisis which is increasingly being taken advantage of by hackers to infiltrate enterprises. ICANN has said that it will continue to work with companies to make sure their keys are correctly configured but that's not ICANN's job and if companies are going to continue to take such a lax attitude towards their cryptographic assets then they will eventually pay a much larger price than a delay to the KSK rollout.”


The update involves generating a new cryptographic key pair and distributing the new public component to the Domain Name System Security Extensions (DNSSEC)-validating resolvers, which in turn direct internet users to the websites they have requested. The KSK establishes a chain of trust from from the root zone through the entire domain name system so that DNS resolvers know they are delivering high-quality results.


However, although the change has been widely publicised, “a significant number of resolvers used by Internet Service Providers (ISPs) and Network Operators are not yet ready for the Key Rollover” according to ICANN. The discovery was made by researchers at Verisign, who used a new DNS protocol feature (RFC 8145) to query which key DNS resolvers are using. The results were that between five and eight percent of the internet's total validators reported only having 2010 version of the KSK key, rather than the 2010 and a newer 2017 version. This is compounded by the fact that only machines running the most recent versions of DNS software have the new protocol feature enabled, so the problem may be even larger than these figures indicate.

 

If the KSK rollover proceeded without both keys being present on the majority of DNS validators, the users that depended on the validators with missing updated keys would be effectively kicked offline, unable to connect to sites or services.


Matt Larson, VP research, ICANN clarified: “We don't know how representative this sample of resolvers is compared to the much larger population of resolvers performing DNSSEC validation. Our next step, therefore, is to gather more data. We want to understand why those resolvers aren't ready: why have they not been updated, or updated automatically, to use the new KSK? We intend to publish the list of resolvers reporting a lack of readiness and enlist the community's support to find them and participate in our investigation. There is no hurry to change the KSK: we remain confident in its security both now and as long as is necessary to be comfortable performing the role.”


A new date for the KSK rollover has not yet been decided by ICANN while it monitors the situation, but the organisation confirmed to SC Media UK that the timing will probably be in Q1 2018.


Larson finished with a call to ISPs and network operators to check and update their configuration if necessary: “Recursive resolvers are typically operated by ISPs and other network operators, so they are the ones who need to take action to verify, and if necessary, update their recursive resolvers' configuration. Awareness is key, so we can use the help of anyone in the Internet community to get the message out that ISPs and other network operators need to examine their recursive resolvers' configuration to confirm their readiness for the roll.”