Latest news of the domain name industry

Recent Posts

Data leak security glitch screws up ICANN 61 for thousands

Kevin Murphy, March 15, 2018, Domain Policy

A security vulnerability forced ICANN to take down its Adobe Connect conferencing service halfway through its ICANN 61 meeting in Puerto Rico.

The “potentially serious security issue” could “could possibly lead to the disclosure of the information shared in an ICANN Adobe Connect room”, ICANN said in a pair of statements.

Taking down the service for the remainder of the meeting, which ends today, meant that potentially thousands of remote participants were left to cobble together a less streamlined replacement experience from a combination of live streams, transcription and email.

At the last ICANN meeting, over 4,000 unique participants logged into Adobe Connect. With only 1,900 or so people on-site, we’re probably looking at over 2,000 remote participants relying on AC to take part.

At this point, it’s not clear whether ICANN has discovered a previously undisclosed vulnerability in the Adobe service, or whether it simply buggered up its implementation with sloppy configuration settings.

It’s also not clear whether the glitch has been actively exploited to expose private data, though ICANN said it was first reported by a member of the Security and Stability Advisory Committee.

ICANN said in the second of two statements issued yesterday:

The issue is one that could possibly lead to the disclosure of the information shared in an ICANN Adobe Connect room. We are still investigating the root cause of the issue. We have formulated different scenarios based on authentication, encryption, and software versions, which we are testing in a controlled fashion in attempt to replicate and understand the root cause of the issue.

We are working directly with Adobe and with our cloud service provider to learn more.

Adobe Connect is a web conferencing tool that, at least when ICANN uses it for public meetings, combines live video and transcription, PowerPoint presentation sharing, and public and private chat rooms.

I also understand that there’s also a whiteboarding feature that allows participants to collaboratively work on documents in closed sessions.

Given that everything shared in the public sessions (outside of the private chat function) is by definition public, it might be reasonable to assume that ICANN’s primary concern here is how the software is used in closed sessions.

I hear ICANN uses Adobe Connect internally among its own staff and board, where one might imagine private data is sometimes shared. Other relatively secretive groups, such as the Governmental Advisory Committee and Nominating Committee, are also believed to sometimes use it behind closed doors.

While Adobe is infamous for producing buggy, insecure software, and ICANN uses a version of it hosted by a third-party cloud services provider, that doesn’t necessarily mean this wasn’t another ICANN screw-up.

In a similar incident uncovered in 2015, it was discovered that new gTLD applicants could read attachments on the confidential portions of their competitors’ applications, after ICANN accidentally had a single privacy configuration toggle set to “On” instead of “Off” in the hosted software it was using to manage the program.

Ashwin Rangan, ICANN’s CIO and the guy also tasked with investigating the Salesforce issue, has now started a probe into the Adobe issue.

Lawyer: GoDaddy Whois changes a “critical” contract breach

Kevin Murphy, March 13, 2018, Domain Registrars

GoDaddy is in violation of its ICANN registrar contract by throttling access to its Whois database, according to a leading industry lawyer.

Brian Winterfeldt of the Winterfeldt IP Group has written to ICANN to demand its compliance team enforces what he calls a “very serious contractual breach”.

At issue is GoDaddy’s recent practice, introduced in January, of masking key fields of Whois when accessed in an automated fashion over port 43.

The company no longer shows the name, email address or phone number of its registrants over port 43. Web-based Whois, which has CAPTCHA protection, is unaffected.

It’s been presented as an anti-spam measure. In recent years, GoDaddy has been increasingly accused (wrongly) of selling customer details to spammers pitching web hosting and SEO services, whereas in fact those details have been obtained from public Whois.

But many in the industry are livid about the changes.

Back in January, DomainTools CEO Tim Chen told us that, even as a white-listed known quantity, its port 43 access was about 2% of its former levels.

And last week competing registrar Namecheap publicly complained that Whois throttling was hindering inbound transfers from GoDaddy.

Winterfeldt wrote (pdf) that “nothing in their contract permits GoDaddy to mask data elements, and evidence of illegality must be obtained before GoDaddy is permitted to throttle or deny
port 43 Whois access to any particular IP address”, adding:

The GoDaddy whitelist program has created a dire situation where businesses dependent upon unmasked and robust port 43 Whois access are forced to negotiate wholly subjective terms for access, and are fearful of filing complaints with ICANN because they are reticent to publicize any disruption in service, or because they fear retaliation from GoDaddy…

This is a very serious contractual breach, which threatens to undermine the stability and security of the Internet, as well as embolden other registrars to make similar unilateral changes to their own port 43 Whois services. It has persisted for far too long, having been officially implemented on January 25, 2018. The tools our communities use to do our jobs are broken. Cybersecurity teams are flying blind without port 43 Whois data. And illegal activity will proliferate online, all ostensibly in order to protect GoDaddy customers from spam emails. That is completely disproportionate and unacceptable

He did not disclose which client, if any, he was writing on behalf of, presumably due to fear of reprisals.

He added that his initial outreaches to ICANN Compliance have not proved fruitful.

ICANN said last November that it would not prosecute registrar breaches of the Whois provisions of the Registrar Accreditation Agreements, subject to certain limits, as the industry focuses on becoming compliant with the General Data Protection Regulation.

But GoDaddy has told us that the port 43 throttling is unrelated to GDPR and to the compliance waiver.

Masking Whois data, whether over port 43 or not, is likely to soon become a fact of life anyway. ICANN’s current proposal for GDPR compliance would see public Whois records gutted, with only accredited users (such as law enforcement) getting access to full records.

Registries reject lower fees for anti-abuse prowess

Kevin Murphy, February 16, 2018, Domain Policy

Registries have largely rejected a proposal for them to be offered financial incentives to lower the amount of abuse in their gTLDs.

That’s despite the idea gaining broad support from governments, intellectual property interests and restricted-registration registries.

The concept of ICANN offering discounted fees to registries that proactively fight abuse was floated by the Competition, Consumer Trust, and Consumer Choice Review Team (CCT) back in November.

It recommended in its draft report, among other things:

Consider directing ICANN org, in its discussions with registries, to negotiate amendments to existing Registry Agreements, or in negotiations of new Registry Agreements associated with subsequent rounds of new gTLDs to include provisions in the agreements providing incentives, including financial incentives for registries, especially open registries, to adopt proactive anti-abuse measures.

“Proactive” in this case would mean measures such as preventing known bad actors from registering domains, rather than just waiting for complaints to be filed.

Given that registries have been calling for lower ICANN fees in other instances, one might expect to see support from that constituency.

However, the Registries Stakeholder Group said in a document filed to ICANN’s public comment period on the CCT’s latest recommendations that, it “opposes” the idea of such financial incentives. It said:

The RySG supports recognizing and supporting the many [registry operators] that take steps to discourage abuse, but opposes amending the RA as recommended, to mandate or incentivize ‘proactive’ anti-abuse measures.

The RySG complained that such a system would require lots of complex work to arrive at a definition of abuse and what kinds of measures would qualify as “proactive”.

Even if such definitions could be found, and amendments to the standard RA successfully negotiated, there’s still no guarantee that bad registries would sign up for the incentives or stick to their promises, “resulting in no net improvement to the current situation”, the RySG said.

The group is also concerned that adding more anti-abuse clauses to the RA could increase registries’ risk of liability should they be sued over abuse carried out by their customers.

Not all registries agreed with the RySG position, however.

The informal Verified Top-Level Domains Consortium, which comprises the two registries behind .bank, .insurance and .pharmacy, filed comments supporting the proposal.

It said that gTLDs with vetted eligibility requirements see no abuse but have lower registration volumes and therefore pay higher ICANN fees on a per-domain basis. It said:

ICANN should help to offset these costs to create a more level playing field with high-volume unrestricted registries, i.e., to enhance competition as well as consumer trust. If ICANN made it more financially advantageous to verify eligibility, other registries may be encouraged to adopt this model. The outcome would be the elimination of abuse in these verified TLDs.

Outside of the industry itself, the Governmental Advisory Committee and IP interests such as the Intellectual Property Constituency and INTA, filed comments supporting anti-abuse incentives.

The IPC “strongly” supported the recommendation, but added that the finer details would need to be worked out to ensure that lower ICANN fees did not translate automatically to lower registration fees and therefore more abuse.

Shocking nobody, it added that “abuse” should include intellectual property infringements.

Conversely, the Non-Commercial Stakeholders Group said it “strongly” opposes the recommendation, on the basis that it would push ICANN into a “content policeman” role in violation of its technical mandate:

ICANN is not a US Federal Trade Commission or an anti-fraud unit or regulatory unit of any government. Providing guidance, negotiation and worse yet, financial incentives to ICANN-contracted registries for anti-abuse measures is completely outside of our competence, goals and mandates. Such acts would bring ICANN straight into the very content issues that passionately divide countries — including speech laws, competition laws, content laws of all types. It would invalidate ICANN commitments to ourselves and the global community. It would make ICANN the policemen of the Internet, not the guardians of the infrastructure. It is a role we have sworn not to undertake; a role beyond our technical expertise; and a recommendation we must not accept.

Also opposed to incentivizing anti-abuse measures was the Messaging, Malware and Mobile Anti-Abuse Working Group (an independent entity, not an ICANN working group), which said there’s no data to support such a recommendation.

The reports provide no data that showcase what the implications of altering the economic underpinnings of a highly competitive market may entail, including inadvertent side effects such as registries that already sell low price domains being rewarded with lower ICANN fees. In fact, it may ultimately result in a race to the bottom and higher rates of domain abuse.

Instead, M3AAWG said that ICANN should concentrate is contractual compliance efforts on those registries that the data shows already have large amounts of abuse — presumably meaning the likes of .top, .gdn and the Famous Four Media stable.

ICANN itself filed a comment on the proposal, pointing out that it is not able to unilaterally impose anti-abuse measures into registry agreements.

One imagines that lowering fees at a time when its own budget is under a lot of pressure would probably not be something ICANN would be eager to implement.

These comments and more were summarized in ICANN’s report on the CCT public comment period, published yesterday. The comments themselves can be found here.

The comments feed back into the CCT review team’s work ahead of its final report, which is due to be published some time during Q1.

Under its bylaws, the CCT review is one of the things that ICANN has to complete before it opens the next round of new gTLD applications.

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.

Research finds homograph attacks on big brands rife

Kevin Murphy, January 22, 2018, Domain Tech

Apparent domain name homograph attacks against major brands are a “significant” problem, according to research from Farsight Security.

The company said last week that it scanned for such attacks against 125 well-known brands over the three months to January 10 and found 116,113 domains — almost 1,000 per brand.

Homographs are domains that look like other domains, often indistinguishable from the original. They’re usually used to phish for passwords to bank accounts, retailers, cryptocurrency exchanges, and so on.

They most often use internationalized domain names, mixing together ASCII and non-ASCII characters when displayed in browsers.

To the naked eye, they can look very similar to the original ASCII-only domains, but under the hood they’re actually encoded with Punycode with the xn-- prefix.

Examples highlighted by Farsight include baŋ, amazoṇ.com and fà

Displayed as ASCII, those domains are actually, and

Farsight gave examples including and excluding the www. subdomain in a blog post last week, but I’m not sure if it double-counted to get to its 116,113-domain total.

As you might imagine, almost all of this abuse is concentrated in .com and other TLDs that were around before 2012, judging by Farsight’s examples. That’s because the big brands are not using new gTLDs for their primary sites yet.

Farsight gave a caveat that it had not generally investigated the ownership of the homograph domains it found. It’s possible some of them are defensive registrations by brands that are already fully aware of the security risk they could present.