Latest news of the domain name industry

Recent Posts

ICANN CTO: no reason to delay KSK rollover

Kevin Murphy, August 15, 2018, Domain Tech

ICANN’s board of directors will be advised to go ahead with a key security change at the DNS root — “the so-called KSK rollover” — this October, according to the organization’s CTO.

“We don’t see any reason to postpone again,” David Conrad told DI on Monday.

If it does go ahead as planned, the rollover will see ICANN change the key-signing key that acts as the trust anchor for the whole DNSSEC-using internet, for the first time since DNSSEC came online in 2010.

It’s been delayed since last October after it emerged that misconfigurations elsewhere in the DNS cloud could see potentially millions of internet users see glitches when the key is rolled.

Ever since then, ICANN and others have been trying to figure out how many people could be adversely affected by the change, and to reduce that number to the greatest extent possible.

The impact has been tricky to estimate due to patchy data.

While it’s been possible to determine a number of resolvers — about 8,000 — that definitely are poorly configured, that only represents a subset of the total number. It’s also been hard to map that to endpoints due to “resolvers behind resolvers behind resolvers”, Conrad said.

“The problem here is that it’s sort of a subjective evaluation,” he said. “We can’t rely on the data were seeing. We’re seeing the resolvers but we’re not seeing the users behind the resolvers.”

Some say that the roll is still too risky to carry out without better visibility into the potential impact, but others say that more delays would lead to more networks and devices becoming DNSSEC-compatible, potentially leading to even greater problems after the eventual rollover.

ICANN knows of about 8,000 resolver IP addresses that are likely to stop working properly after the rollover, because they only support the current KSK, but that’s only counting resolvers that automatically report their status to the root using a relatively new internet standard. There’s a blind spot concerning resolvers that do not have that feature turned on.

ICANN has also had difficulty reaching out to the network operators behind these resolvers, with good contact information apparently only available for about a quarter of the affected IP addresses, Conrad said.

Right now, the best data available suggests that 0.05% of the internet’s population could see access issues after the October 11 rollover, according to Conrad.

That’s about two million people, but it’s 10 times fewer people than the 0.5% acceptable collateral damage threshold outlined in ICANN’s rollover plan.

The 0.05% number comes from research by APNIC, which used Google’s advertising system to place “zero-pixel ads” to check whether individual user endpoints were using compatible resolvers or not.

If problems do emerge October 11 the temporary solution is apparently quite quick to implement — network operators can simply turn off DNSSEC, assuming they know that’s what they’re supposed to do.

But still, if a million or two internet users could have their day ruined by the rollover, why do it at all?

It’s not as if the KSK is in any danger of being cracked any time soon. Conrad explained that a successful brute-force attack on the 2048-bit RSA key would take longer than the lifetime of the universe using current technology.

Rather, the practice of rolling the key every five years is to get network operators and developers accustomed to the idea that the KSK is not a permanent fixture that can be hard-coded into their systems, Conrad said.

It’s a problem comparable to new gTLD name collisions or the Y2K problem, instances where developers respectively hard-coded assumptions about valid TLDs or the century into their software.

ICANN has already been reaching out to the managers of open-source projects on repositories such as Github that have been seen to hard-code the current KSK into their software, Conrad said.

Separately, Wes Hardaker at the University of Southern California Information Sciences Institute discovered that a popular VPN client was misconfigured. Outreach to the developer saw the problem fixed, reducing the number of users who will be affected by the roll.

“What we’re trying to avoid is having these keys hardwired into firmware, so that that it would never be changeable,” he said. “The idea is if you exercise the infrastructure frequently enough, people will know the that the key is not permanent configuration, it’s not something embedded in concrete.”

One change that ICANN may want to make in future is to change the algorithm used to generate the KSK.

Right now it’s using RSA, but Conrad said it has downsides such as rather large signature size, which leads to heavier DNSSEC traffic. By switching to elliptical curve cryptography, signatures could be reduced by “orders of magnitude”, leading to a more efficient and slimline DNS infrastructure, Conrad said.

Last week, ICANN’s Root Server Stability Advisory Committee issued an advisory (pdf) that essentially gave ICANN the all-clear to go ahead with the roll.

The influential Security and Stability Advisory Committee has yet to issue its own advisory, however, despite being asked to do so by August 10.

Could SSAC be more cautious in its advice? We’ll have to wait and see, but perhaps not too long; the current plan is for the ICANN board to consider whether to go ahead with the roll during its three-day Brussels retreat, which starts September 14.

Digital archery ruled out for next new gTLD round

Kevin Murphy, July 10, 2018, Domain Tech

The oft-mocked “digital archery” system will not be making a return when ICANN finally starts taking more new gTLD applications.

That’s the current thinking of the ICANN community working group looking at subsequent application procedures.

Readers with long memories may recall digital archery as a hack for Californian gambling laws that ICANN org pressed for in 2012 as a way to form its 1,930 applications into an orderly queue for processing.

The idea was that applicants would fire off a bit of data to an ICANN site at a predetermined time and the applicants whose packets arrived closet to the target time, measured by the millisecond, would receive priority in the queue.

It was a bit like drop-catching, and the concept advanced to the stage where companies skilled in such things were offering digital archery services.

But after ICANN changed CEOs later that year, it turned out gambling wasn’t as illegal in California as former management thought it was. The org got itself a license to run a one-off lottery and sold tickets for $100 per application.

That’s now the preferred method for ordering the queue for the next rounds of applications, whenever those may be, according to last week’s Initial Report on the New gTLD Subsequent Procedures Policy Development Process.

Unlike 2012, the WG is proposing that portfolio applicants should be able to swap around their priority numbers according to their commercial interests.

So, if Donuts gets priority #1 for .crappy and #4,000 for .awesome, it would be able to switch priorities to get the better string evaluated earlier.

The WG is also not convinced that internationalized domain names, which received automatic priority in 2012, should get the same preferential treatment this time around.

That’s one of several questions it poses for the community in its public comment period.

While a better place in the evaluation queue had time-to-market advantages in 2012 — Donuts’ .guru sold a tonne of domains largely due to its first-mover status — that’s probably not going to be as big a deal next time around due to domainer skepticism about new gTLDs.

Could crypto solve the Whois crisis?

Kevin Murphy, July 10, 2018, Domain Tech

Could there be a cryptographic solution to some of the problems caused by GDPR’s impact on public Whois databases? Security experts think so.

The Anti-Phishing Working Group has proposed that hashing personal information and publishing it could help security researchers carry on using Whois to finger abusive domain names.

In a letter to ICANN, APWG recently said that such a system would allow registries and registrars to keep their customers’ data private, but would still enable researchers to identify names registered in bulk by spammers and the like.

“Redacting all registration records which were formerly publicly available has unintended and undesirable consequences to the very citizens and residents that electronic privacy legislation intends to protect,” the letter (pdf) says.

Under the proposed system, each registry or registrar would generate a private key for itself. For each Whois field containing private data, the data would be added to the key and hashed using a standard algorithm such as SHA-512.

For items such as physical addresses, all the address-related fields would be concatenated, with the key, before hashing the combined value.

The resulting hash — a long string of gibberish characters — would then be published in the public Whois instead of the [REDACTED] notice mandated by current ICANN policy.

Security researchers would then be able to identify domains belonging to the same purported registrant by searching for domains containing the same hash values.

It’s not a perfect solution. Because each registry or registrar would have their own key, the same registrant would have different hash values in different TLDs, so it would not be possible to search across TLDs.

But that may not be a huge problem, given that bad guys tend to bulk-register names in TLDs that have special offers on.

The hashing system may also be beneficial to interest groups such as trademark owners and law enforcement, which also look for registration patterns when tracking down abuse registrants.

The proposal would create implementation headaches for registries and registrars — which would actually have to build the crypto into their systems — and compliance challenges for ICANN.

The paper notes that ICANN would have to monitor its contracted parties — not all of which may necessarily be unfriendly to spammers — to make sure they’re hashing the data correctly.

ICANN found a zero-day hole in Adobe Connect

Kevin Murphy, April 23, 2018, Domain Tech

It’s looking like ICANN may have found a zero-day vulnerability in Adobe Connect, until recently its default collaboration tool.

The organization on Friday announced the results of a “forensic investigation” into the bug, and said it has reported its findings to Adobe, which is now “working on a software fix to address the root cause of the issue”.

If Adobe didn’t know about it, it looks rather like ICANN — or at least the unnamed member of the security advisory committee who found it — has bagged itself a zero-day.

ICANN had previously said that the glitch “could possibly lead to the disclosure of the information shared in an ICANN Adobe Connect room”.

The review found that the only person who exploited the bug was the person who discovered and disclosed it.

AC is used not only in ICANN’s public meetings but also, I understand, in closed sessions of ICANN staff, board and committees, where secret information is most likely to be shared.

After the bug was discovered, ICANN shut off the system and started using alternatives such as WebEx, to a mixed reception.

In the absence of an immediate patch from Adobe, ICANN has been testing workarounds and said it hopes to have two working ones deployed by May 3.

This would allow the tool to come back online in time for its board workshop, GDD Summit and ICANN 62, the organization said.

Root crypto rollover now slated for October

Kevin Murphy, February 6, 2018, Domain Tech

ICANN has penciled in October 11 as the new date for rolling the DNS root’s cryptographic keys, a delay of a year from its original plan.

The so-called KSK rollover will see ICANN remove the deprecated 2010 Key Signing Key, leaving only the 2017 KSK active.

The KSK acts as the “trust anchor” for DNSSEC across the whole internet.

After the rollover, any network not configured to use the latest KSK would see a service interruption.

This could mean many millions of internet users being affected, but ICANN doesn’t know the extent of the possible impact for sure.

ICANN told us in November that it knows of 176 organizations in 41 countries, fairly evenly spread across the globe, that are currently not prepared to handle the new KSK.

But its data is patchy because only a tiny number of DNS resolvers are actually configured to automatically report which KSKs they’re set up to use.

Key rollovers are recommended by DNSSEC experts to reduce the risk of brute force attacks against old keys. At the root, the original plan was to roll the keys every five years.

ICANN had named October 11 2017 as the date for the first such rollover, but this was pushed back to some time in the first quarter after ICANN became aware of the lack of support for the 2017 KSK.

This was pushed back again in December to Q3 at the earliest, after ICANN admitted it still didn’t have good enough data to measure the impact of a premature roll.

Since then, ICANN has been engaged in (not always successful) outreach to networks it knows are affected and has kicked off discussions among network operators (there’s a fairly lively mailing list on the topic) to try to gauge how cautious it needs to be.

It’s now published an updated plan that’s the same as the original plan but with a date exactly one year late — October 11, 2018.

Between now and then, it will continue to try to get hold of network operators not ready to use the new keys, but it’s not expecting to completely eliminate damage. The plan reads:

Implicit in the outreach plan is the same assumption that the community had for the earlier (postponed) plan: there will likely be some systems that will fail to resolve names starting on the day of the rollover. The outreach will attempt to minimize the number of affected users while acknowledging that the operators of some resolvers will be unreachable.

The plan is open for public comment and will require the assent of the ICANN board of directors before being implemented. You have until April 2 to respond.