Latest news of the domain name industry

Recent Posts

ICANN apologizes to “arms dealer” claim security firm after email goes missing

Kevin Murphy, August 31, 2020, Domain Registrars

ICANN has apologized to the security company that claimed an accredited registrar was in league with malware distributors, after an email went AWOL.

You may recall that registrar GalComm was accused by Awake Security last month of turning a blind eye to abuse in a report entitled “The Internet’s New Arms Dealers: Malicious Domain Registrars” and that ICANN’s preliminary investigation later essentially dismissed the allegations.

ICANN had told GalComm (pdf) August 18 that Awake had not “to date” contacted ICANN about its allegations, but that appears to have been untrue.

GalComm’s lawyers had in fact emailed a letter to ICANN, using its “globalsupport” at icann.org email address, on August 6, as said lawyers testily informed (pdf) Global Domains Division VP Russ Weinstein August 20.

Weinstein has now confirmed (pdf) that a letter from Awake was received to said email address but “was not escalated internally”. He said he was “previously unaware” of the letter. He wrote:

I apologize for this inadvertent oversight and we will use this as a training opportunity to prevent such errors in the future.

GalComm has been threatening to sue Awake for defamation since the “arms dealer” report was published, so it looks like ICANN’s decision to eat humble pie is probably a prudent way to keep its name off the docket.

The letter from Awake’s lawyers (pdf) also includes a lengthy explanation of why the original report is not, in its view, defamatory.

The lesson for the rest of us appears to be that the ICANN email address in question is probably not the best way to reach ICANN’s senior management.

Weinstein said that abuse complaints about registrars should be sent to its “compliance” at icann.org address.

“Arms dealer” registrar probed by ICANN

Kevin Murphy, August 20, 2020, Domain Registrars

ICANN’s top security thinkers are looking into hotly denied claims that an Israeli registrar collaborated with malware distributors.

Luckily for the registrar, GalComm, so far they’ve come up empty-handed and ICANN has told the company it does not consider it “malicious”.

ICANN told GalComm this week that its Security, Stability and Resiliency team is looking into a report published by security consultancy Awake Security in June entitled “The Internet’s New Arms Dealers: Malicious Domain Registrars”.

The report connected GalComm to over 100 malicious browser extensions, used to steal data, that have been installed 33 million times. GalComm was apparently the attackers’ registrar of choice.

While Awake did not report the registrar to ICANN, GalComm took it upon itself to write to ICANN to deny the allegations, saying that it merely acted as a neutral registrar and had no involvement in hosting or distributing the malware.

It also demanded that Awake retract its report and apologize or face legal consequences. The report is still available.

Now, ICANN has written back (pdf) to assure the registrar that its investigations to date has been “unable to corroborate the findings Awake Security presented and it does appear that Awake Security had an inaccurate picture of the total domains under management by GalComm”.

It added that the investigation is ongoing, however:

Based on the information we have been able to obtain to date, we have no reason to believe it appropriate for GalComm to be considered a “malicious domain registrar” as asserted by Awake Security. However, as noted in Awake Security’s report, the malicious actors behind the domains in question may be utilizing detection evasion techniques. As such, our investigations continue, and we appreciate GalComm’s cooperation and support of those investigations.

ICANN has previously told news outlets that it receives very few complaints about GalComm, none related to malware.

“Horrifying” Zoombombing attack on ICANN meeting, again

Kevin Murphy, June 22, 2020, Domain Policy

ICANN’s eleventh-hour decision to remove password requirements for ICANN 68 was proved wrong almost immediately after the meeting got underway on Zoom today.

According to participants and ICANN itself, several sessions were “zoombombed” this morning, with apparently pornographic content.

Zoombombing is where trolls disrupt public, open Zoom meetings with content designed to offend.

ICANN 68 is taking place on Zoom, but on Kuala Lumpur time. I was asleep during the attacks and ICANN has yet to post the recordings of any of today’s sessions, so I can’t give you any of the details first-hand.

But judging by a handful of social media posts that reference the attack, it seems to have been pornographic in nature. ICANN said it comprised “audio, images and video”.

One participant described it as “funny at first…until it was not”, while another said it was “horrifying” and left her feeling “completely vulnerable”.

ICANN said in a blog post that the trolls were swiftly removed from the sessions.

It added that it has changed the format of the remainder of ICANN 68, unplugging certain interactive components and requiring passwords to be entered before access is granted.

This means you’re going to have to register for each session and click emailed confirmation links, it appears.

Only the Governmental Advisory Committee is staying on the platform with its original vulnerable configuration.

ICANN had been planning to require passwords since a similar attack at an inter-sessional meeting in March, but changed its mind last week after security upgrades made by Zoom gave leaders a greater sense of confidence in the platform.

It appears that confidence was misplaced.

You won’t need a password for ICANN 68 after all

Kevin Murphy, June 17, 2020, Domain Policy

ICANN has ditched plans to require all ICANN 68 participants to enter a password whenever they enter one of the Zoom sessions at the meeting next week.

The org said today that it will use URLs with embedded passwords, removing the need for user input, after reviewing changes Zoom made last month.

These included features such as a waiting room that enables meeting hosts to vet participants manually before allowing them to enter the meeting proper.

ICANN said: “Please use these links cautiously, only share them on secure channels such as encrypted chat or encrypted e-mail, and never post them publicly.”

ICANN had said last month, before the Zoom changes, that it would require passwords in order to limit the risk of Zoombombing — where trolls show up and spam the meeting with offensive content. One ICANN Zoom session had been trolled in this way in March.

The org also said today that participants will be asked to give their consent to be recorded upon entry to a session.

“It is our hope that this small change empowers attendees by providing quick access and more control over the acceptance of our policies as it relates to attending virtual meetings,” ICANN lied, to cover for the obvious piece of legal ass-covering.

Refuse consent and see how far you get.

Irony alert! Data protection agency complains it can’t get access to private Whois data

Kevin Murphy, May 26, 2020, Domain Policy

A European data protection authority has complained to ICANN after a registrar refused to hand over one of its customers’ private Whois records, citing the GDPR data protection regulation, according to ICANN.

Compounding the irony, the DPA wanted the data as part of its probe into an alleged GDPR violation at the domain in question.

This is the frankly hilarious scenario outlined in a letter (pdf) from ICANN boss Göran Marby to Andrea Jelinek, chair of the European Data Protection Board, last week.

Since May 2018, registrars and registries have been obliged under ICANN rules to redact all personally identifiable information from public Whois records, because of the EU’s General Data Protection regulation.

This has irked the likes of law enforcement and intellectual property owners, who have found it increasingly difficult to discover the identities of suspected bad actors such as fraudsters and cybersquatters.

Registrars are still obliged to hand over data upon request in certain circumstances, but the rules are vague, requiring a judgement call:

Registry and Registrar MUST provide reasonable access to Personal Data in Registration Data to third parties on the basis of a legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.

While an ICANN working group has been attempting to come up with a clearer-cut set of guidelines, administered by a central body, this so-called SSAD (System for Standardized Access/Disclosure) has yet to come to fruition.

So when an unidentified European DPA recently asked a similarly unidentified non-EU registrar for the Whois data of somebody they suspected of GDPR violations, the registrar told it to get stuffed.

It told the DPA it would “not act against a domain name without any clear and unambiguous evidence for the fraudulent behavior” and said it would respond to legal requests in its own jurisdiction, according to ICANN.

The DPA complained to ICANN, and now ICANN is using that complaint to shame the EDPB into getting off the fence and providing some much-needed clarity about when registrars can declassify Whois data without breaking the law.

Marby wrote that registrars are having to apply their “subjective judgment and discretion” and will most often come down on the side of registrants in order to reduce their GDPR risk. He wrote:

ICANN org would respectfully suggest to the EDPB that a more explicit recognition of the importance of certain legitimate interests, including the relevance of public interests, combined with clearer guidelines on balancing, could address these problems.

ICANN org would respectfully suggest to the EDPB to consider issuing additional specific guidance on this topic to ensure that entities with a legitimate interest in obtaining access to non-public gTLD registration data are able to do so. Guidance would in particular be appreciated on how to balance legitimate interests in access to data with the interests of the data subject concerned

ICANN and the EDPB have been communicating about this issue for a couple of years now, with ICANN looking for some clarity on this largely untested area of law, but the EDPB’s responses to data have been pretty vague and unhelpful, almost as if it doesn’t know what the hell it’s doing either.

Will this latest example of the unintended consequences of GDPR give the Board the kick up the bum it needs to start talking in specifics? We’ll have to wait and see.

After Zoom trolling, ICANN 68 will be password-protected

Kevin Murphy, May 6, 2020, Domain Policy

If you want to show up to ICANN 68, which will be held online next month, you’re going to need a password.

ICANN said this week that it’s updating its Zoom software and standard configuration to require passwords. In a blog post outlining a number of changes to its Zoom instance, ICANN said:

The most impactful change is the new requirement that all meetings be secured with a password. This is the first step recommended by security professionals to keep meetings secure, and one which we had largely adopted org-wide prior to making it a requirement for all. We will make another announcement in the coming weeks regarding how this may impact joining meetings during ICANN68, as we work towards the best overall solution.

Quite how this could work while maintaining the usual openness of ICANN’s public meetings — which have always been free to attend basically anonymously — remains to be seen.

At ICANN 67, Zoom sessions that were open to the public simply required you to enter a name. Any name. At in-person public meetings, I don’t think you even need to show ID to get a hall pass.

The changes come in the wake of a “Zoombombing” incident during a minor meeting in March, during which trolls showed up via a publicly-posted link and flooded the session with “inappropriate and offensive” audio and imagery.

ICANN meeting got “Zoombombed” with offensive material

Kevin Murphy, April 27, 2020, Domain Policy

An ICANN meeting held over the Zoom conferencing service got “Zoombombed” by trolls last month.

According to the organization, two trolls entered an ICANN 67 roundup session for Spanish and Portuguese speakers on March 27 and “shared inappropriate and offensive audio and one still image” with the legitimate participants.

The session was not password protected (rightly) but the room had (wrongly) not been configured to mute participants or disable screen-sharing, which enabled the offensive material to be shared.

The trolls were quickly kicked and the loopholes closed, ICANN said in its incident report.

ICANN appears to have purged the meeting entirely from its calendar and there does not appear to be an archive or recording, so I sadly can’t share with you the gist of the shared content.

Zoombombing has become an increasingly common prank recently, as the platform sees many more users due to the coronavirus-related lockdowns worldwide.

Go here to help fight against coronavirus abuse

Kevin Murphy, March 26, 2020, Domain Tech

A coalition of over 1,000 security experts, domain name providers and others have got together to help coordinate efforts to combat abusive coronavirus-related domains.

A workspace on the collaboration platform Slack has been growing steadily since it was created a week ago, enabling technology professionals to exchange information about the alarming number of sites currently trying to take advantage of the pandemic.

You can join the channel via this link. Thanks to Theo Geurts of RealtimeRegister.com for passing it along.

The collection of chat rooms appears to have been created by Joshua Saxe, chief scientist at security software firm Sophos, March 19. There are currently 1,104 members.

There’s a channel devoted to malicious domains, which is being used to share statistical data and lists of bad and good coronavirus-related domains, among other things.

Across the workspace, a broad cross-section of interested parties is represented. Current members appear to come from security companies, governments, law enforcement, registries, registrars, ICANN, healthcare providers, and others.

It seems like a pretty good way for the technical members of the domain name industry to keep track of what’s going on during the current crisis, potentially helping them to put a stop to threats using domains they manage as they emerge.

As it releases free download, DomainTools says 68,000 dangerous coronavirus domains have been registered

Kevin Murphy, March 26, 2020, Domain Services

More than 68,000 coronavirus-related domain names have been registered so far in 2020, according to data released by DomainTools today.

The domain intelligence services company has started publishing a list of these domains, updated daily, for free on its web site. You have to submit your email address to get it.

The download comprises a CSV file with three columns: domain, reg date, and Domain Risk Score.

This final field is based on DomainTools’ in-house algorithms that estimate how likely domains are likely to be used in nefarious activities, based on criteria including the domain’s connection to other, known-bad domains.

Only domains with a score of 70 or above out of 100 — indicating they will likely be used for activities such as phishing, malware or spam — will be included on the list, the company said.

The list will be updated daily at 0000 UTC.

You can find out more and obtain today’s list here.

Hacking claims resurface as .hotel losers force ICANN to lawyer up again

Kevin Murphy, February 7, 2020, Domain Policy

The fight over .hotel has been escalated, with four unsuccessful applicants for the gTLD whacking ICANN with a second Independent Review Process appeal.

The complaint resurrects old claims that a former lead on the successful application, now belonging to Afilias, stole trade secrets from competing applicants via a glitched ICANN web site.

It also revives allegations that ICANN improperly colluded with the consultant hired to carry out reviews of “community” applications and then whitewashed an “independent” investigation into the same.

The four companies filing the complaint are new gTLD portfolio applicants MMX (Minds + Machines), Radix, Fegistry, and Domain Venture Partners (what we used to call Famous Four).

The IRP was filed November 18 and published by ICANN December 16, but I did not spot it until more recently. Sorry.

There’s a lot of back-story to the complaint, and it’s been a few years since I got into any depth on this topic, so I’m going to get into a loooong, repetitive, soporific, borderline unreadable recap here.

This post could quite easily be subtitled “How ICANN takes a decade to decide a gTLD’s fate”.

There were seven applicants for .hotel back in 2012, but only one of them purported to represent the “hotel community”. That applicant, HOTEL Top Level Domain, was mostly owned by Afilias.

HTLD had managed to get letters of support from a large number of hotel chains and trade groups, to create a semblance of a community that could help it win a Community Priority Evaluation, enabling it to skip to the finish line and avoid a potentially costly auction against its rival applicants.

CPEs were carried out by the Economist Intelligence Unit, an independent ICANN contractor.

Surprisingly to some (including yours truly), back in 2014 it actually managed to win its CPE, scoring 15 out of the 16 available points, surpassing the 14-point winning threshold and consigning its competing bidders’ applications to the scrap heap.

There would be no auction, and no redistribution of wealth between applicants that customarily follows a new gTLD auction.

Naturally, the remaining applicants were not happy about this, and started to fight back.

The first port of call was a Request for Reconsideration, which all six losers filed jointly in June 2014. It accused the EIU of failing to follow proper procedure when it evaluated the HTLD community application.

That RfR was rejected by ICANN, so a request for information under ICANN’s Documentary Information Disclosure Policy followed. The losing applicants reckoned the EIU evaluator had screwed up, perhaps due to poor training, and they wanted to see all the communications between ICANN and the EIU panel.

The DIDP was also rejected by ICANN on commercial confidentiality grounds, so the group of six filed another RfR, asking for the DIDP to be reconsidered.

Guess what? That got rejected too.

So the applicants then filed an IRP case, known as Despegar v ICANN, in March 2015. Despegar is one of the .hotel applicants, and the only one that directly plays in the hotel reservation space already.

The IRP claimed that ICANN shirked its duties by failing to properly oversee and verify the work of the EIU, failing to ensure the CPE criteria were being consistently applied between contention sets, and failing in its transparency obligations by failing to hand over information related to the CPE process.

While this IRP was in its very early stages, it emerged that one of HTLD’s principals and owners, Dirk Krischenowski, had accessed confidential information about the other applicants via an ICANN web site.

ICANN had misconfigured its applicant portal in such a way that any user could very access any attachment on any application belonging to any applicant. This meant sensitive corporate information, such as worst-case-scenario financial planning, was easily viewable via a simple search for over a year.

Krischenowski appears to have been the only person to have noticed this glitch and used it in earnest. ICANN told applicants in May 2015 that he had carried out 60 searches and accessed 200 records using the glitch.

Krischenowski has always denied any wrongdoing and told DI in 2016 that he had always “relied on the proper functioning of ICANN’s technical infrastructure while working with ICANN’s CSC portal.”

The applicants filed another DIDP, but no additional information about the data glitch was forthcoming.

When the first IRP concluded, in February 2016, ICANN prevailed, but the three-person IRP panel expressed concern that neither the EIU nor ICANN had any process in place to ensure that community evaluations carried out by different evaluators were consistently applying the CPE rules.

The IRP panel also expressed concern about the “very serious issues” raised by the ICANN portal glitch and Krischenowski’s data access.

But the loss of the IRP did not stop the six losing applicants from ploughing on. Their lawyer wrote to ICANN in March 2016 to denounce Krischenowski’s actions as “criminal acts” amounting to “HTLD stealing trade secrets of competing applicants”, and as such HTLD’s application for .hotel should be thrown out.

Again, to the best of my knowledge, Krischenowski has never been charged with, let alone convicted of, any criminal act.

Afilias wrote to ICANN not many weeks later, April 2016, to say that it had bought out Krischenowski’s 48.8% stake in HTLD and that he was no longer involved in the company or its .hotel application.

And ICANN’s board of directors decided in August 2016 that Krischenowski may well have accessed documents he was not supposed to, but that it would have happened after the .hotel CPE had been concluded, so there was no real advantage to HTLD.

A second, parallel battle against ICANN by an unrelated new gTLD applicant had been unfolding over the same period.

A company called Dot Registry had failed in its CPE efforts for the strings .llc, .llp and .inc, and in 2014 had filed its own IRP against ICANN, claiming that the EIU had “bungled” the community evaluations, applying “inconsistent” scoring criteria and “harassing” its supporters.

In July 2016, almost two years later, the IRP panel in that case ruled that Dot Registry had prevailed, and launched a withering attack on the transparency and fairness of the ICANN process.

The panel found that, far from being independent, the EIU had actually incorporated notes from ICANN staff into its CPE evaluations during drafting.

It was as a result of this IRP decision, and the ICANN board’s decision that Krischenowski’s actions could not have benefited HTLD, that the losing .hotel applicants filed yet another RfR.

This one lasted two and a half years before being resolved, because in the meantime ICANN launched a review of the CPE process.

It hired a company called FTI Consulting to dig through EIU and ICANN documentation, including thousands of emails that passed between the two, to see if there was any evidence of impropriety. It covered .hotel, .music, .gay and other gTLD contention sets, all of which were put on hold while FTI did its work.

FTI eventually concluded, at the end of 2017, that there was “no evidence that ICANN organization had any undue influence on the CPE reports or engaged in any impropriety in the CPE process”, which affected applicants promptly dismissed as a “whitewash”.

They began lobbying for more information, unsuccessfully, and hit ICANN with yet another RfR in April 2018. Guess what? That one was rejected too.

The .hotel applicants then entered into a Cooperative Engagement Process — basically pre-IRP talks — from October 2018 to November 2019, before this latest IRP was filed.

It’s tempting to characterize it as a bit of a fishing expedition, albeit not a baseless one — any allegations of ICANN’s wrongdoing pertaining the .hotel CPE are dwarfed by the applicants’ outraged claims that ICANN appears to be covering up both its interactions with the EIU and its probe of the Krischenowski incident, partly out of embarrassment.

The claimants want ICANN to be forced to hand over documentation refused them on previous occasions, relating to: “ICANN subversion of the .HOTEL CPE and first IRP (Despegar), ICANN subversion of FTI’s CPE Process Review, ICANN subversion of investigation into HTLD theft of trade secrets, and ICANN allowing a domain registry conglomerate to takeover the ‘community-based’ applicant HTLD.”

“The falsely ‘independent’ CPE processes were in fact subverted by ICANN in violation of Bylaws, HTLD stole trade secrets from at least one competing applicant, and Afilias is not a representative of the purported community,” the IRP states.

“HTLD’s application should be denied, or at least its purported Community Priority relinquished, as a consequence not only for HTLD’s spying on its competitors’ secret information, but also because HTLD is no longer the same company that applied for the .HOTEL TLD. It is now just a registry conglomerate with no ties to the purported, contrived ‘Community’ that it claims entitled to serve,” it goes on.

ICANN is yet to file its response to the complaint.

Whether the IRP will be successful is anyone’s guess, but what’s beyond doubt is that if it runs its course it’s going to add at least a year, probably closer to two, to the delay that .hotel has been languishing under since the applications were filed in 2012.

Potentially lengthening the duration of the case is the claimants’ demand that ICANN “appoint and train” a “Standing Panel” of at least seven IRP panelists from which each three-person IRP panel would be selected.

The standing panel is something that’s been talked about in ICANN’s bylaws for at least six or seven years, but ICANN has never quite got around to creating it.

ICANN pinged the community for comments on how it should go about creating this panel last year, but doesn’t seemed to have provided a progress report for the last nine months.

The .hotel applicants do not appear to be in any hurry to get this issue resolved. The goal is clearly to force the contention set to auction, which presumably could happen at Afilias’ unilateral whim. Time-to-market is only a relevant consideration for the winner.

With .hotel, and Afilias’ lawsuit attempting to block the .web sale to Verisign, the last round of new gTLD program, it seems, is going to take at least a decade from beginning to end.