Latest news of the domain name industry

Recent Posts

Crunch time, again, for Whois access policy

Kevin Murphy, October 14, 2019, Domain Policy

Talks seeking to craft a new policy for allowing access to private Whois data have hit another nodal point, with the community now pressuring the ICANN board of directors for action.

The Whois working group has more or less decided that a centralized model for data access, with ICANN perhaps acting as a clearinghouse, is the best way forward, but it needs to know whether ICANN is prepared to take on this role and all the potential liabilities that come with it.

Acronym time! The group is known as the Whois EPDP WG (for Expedited Policy Development Process Working Group) and it’s come up with a rough Whois access framework it’s decided to call the Standardized System for Access and Disclosure (SSAD).

Its goal is to figure out a way to minimize the harms that Europe’s General Data Protection Regulation allegedly caused to law enforcement, IP owners, security researchers and others by hiding basically all gTLD registration data by default.

The SSAD, which is intended to be as automated as possible, is the working group’s proposed way of handling this.

The “hamburger model” the EPDP has come up with sees registries/registrars and data requestors as the top and bottom of the sandwich (or vice versa) with some yet-to-be-decided organizational patty filling acting as an interface between the two.

The patty would handle access control for the data requests and be responsible for credentialing requestors. It could either be ICANN acting alone, or ICANN coordinating several different interface bodies (the likes of WIPO have been suggested).

Should the burger be made only of mashed-up cow eyelids, or should it incorporate the eyelids of other species too? That’s now the question that ICANN’s board is essentially being posed.

Since this “phase two” work kicked off, it’s taken about five months, 24 two-hour teleconferences, and a three-day face-to-face meeting to get to this still pretty raw, uncooked state.

The problem the working group is facing now is that everyone wants ICANN to play a hands-on role in running a centralized SSAD system, but it has little idea just how much ICANN is prepared to get involved.

The cost of running such a system aside, legislation such as GDPR allows for pretty hefty fines in cases of privacy breaches, so there’s potentially a big liability ask of notoriously risk-averse ICANN.

So the WG has written to ICANN’s board of directors in an attempt to get a firm answer one way or the other.

If the board decided ICANN should steer clear, the WG may have to go back more or less to square one and focus on adapting the current Whois model, which is distributed among registrars and registries, for the post-GDPR world.

How much risk and responsibility ICANN is willing to absorb could also dictate which specific SSAD models the WG pursues in future.

There’s also a view that, with no clarity from ICANN, the chance of the WG reaching consensus is unlikely.

This will be a hot topic at ICANN 66 in Montreal next month.

Expect the Governmental Advisory Committee, which had asked for “considerable and demonstrable progress, if not completion” of the access model by Montreal, to be disappointed.

Sixty gTLD registries not monitoring security threats

Kevin Murphy, September 18, 2019, Domain Registries

Roughly 5% of gTLD registry operators have been doing no abuse monitoring, despite contractual requirements to do so, a recent ICANN audit has found.

ICANN checked with 1,207 registries — basically all gTLDs — between November 2018 and June, and found about 60 of them “were not performing any security threat monitoring, despite having domains registered in their gTLDs”.

A further 180 (15%) were not doing security checks, but had no registered domains, usually because they were unused dot-brands. ICANN told these companies that they had to do the checks anyway, to remain in compliance.

In all cases, ICANN said, the registries remediated their oversights during the audit to bring their gTLDs back into compliance.

ICANN does not name the non-compliant registries in the summary of the audit’s results, published yesterday (pdf).

Registries under the 2012 new gTLD base registry agreement all have to agree to this:

Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request.

It’s possible to keep tabs on abuse by monitoring domain blocklists such as SpamHaus, SURBL and PhishTank. Some such lists are freely available, others carry hefty licensing fees.

ICANN itself monitors these lists through its Domain Abuse Activity Reporting project, so it’s able to work out the differences between the levels of abuse registries report and what the empirical data suggests.

Registries typically either use these lists via in-house tools or license products provided by vendors such as Neustar, RegistryOffice, Knipp, CSC, DOTZON, Afnic, AusCERT, Shadowserver, Telefonica, Secure Domain Foundation and Netcraft, ICANN said.

Perhaps unsurprisingly, there’s a bit of disagreement between ICANN and some registries about how the somewhat vague obligations quote above are be interpreted.

ICANN thinks registries should have to provide information about specific domains that were identified as abusive and what remediation actions were taken, but some registries think they only have to provide aggregate statistical data (which would be my read of the language).

The contracts also don’t specify how frequently registries much carry out security reviews.

Of the 80% (965) of registries already in compliance, 80% (772) were doing daily abuse monitoring. Others were doing it weekly, monthly, or even quarterly, ICANN found, all of which appear to be in line with contractual requirements.

ICANN must do more to fight internet security threats [Guest Post]

ICANN and its contracted parties need to do more to tackle security threats, write Dave Piscitello and Lyman Chapin of Interisle Consulting.

The ICANN Registry and Registrar constituencies insist that ICANN’s role with respect to DNS abuse is limited by its Mission “to ensure the stable and secure operation of the internet’s unique identifier systems”, therefore limiting ICANN’s remit to abuse of the identifier systems themselves, and specifically excluding from the remit any harms that arise from the content to which the identifiers point.

In their view, if the harm arises not from the identifier, but from the thing identified, it is outside of ICANN’s remit.

This convenient formulation relieves ICANN and its constituencies of responsibility for the way in which identifiers are used to inflict harm on internet users. However convenient it may be, it is fundamentally wrong.

ICANN’s obligation to operate “for the benefit of the Internet community as a whole” (see Bylaws, “Commitments”) demands that its remit extend broadly to how a domain name (or other Internet identifier) is misused to point to or lure a user or application to content that is harmful, or to host content that is harmful.

Harmful content itself is not ICANN’s concern; the way in which internet identifiers are used to weaponize harmful content most certainly is.

Rather than confront these obligations, however, ICANN is conducting a distracting debate about the kinds of events that should be described as “DNS abuse”. This is tedious and pointless; the persistent overloading of the term “abuse” has rendered it meaningless, ensuring that any attempt to reach consensus on a definition will fail.

ICANN should stop using the term “DNS abuse” and instead use the term “security threat”.

The ICANN Domain Abuse Activity Reporting project and the Governmental Advisory Committee (GAC) use this term, which is also a term of reference for new TLD program obligations (Spec 11) and related reporting activities. It is also widely used in the operational and cybersecurity communities.

Most importantly, the GAC and the DAAR project currently identify and seek to measure an initial set of security threats that are a subset of a larger set of threats that are recognized as criminal acts in jurisdictions in which a majority of domain names are registered.

ICANN should acknowledge the GAC’s reassertion in its Hyderabad Communique that the set of security threats identified in its Beijing correspondence to the ICANN Board were not an exhaustive list but merely examples. The GAC smartly recognized that the threat landscape is constantly evolving.

ICANN should not attempt to artificially narrow the scope of the term “security threat” by crafting its own definition.

It should instead make use of an existing internationally recognized criminal justice treaty. The Council of Europe’s Convention on Cybercrime is a criminal justice treaty that ICANN could use as a reference for identifying security threats that the Treaty recognizes as criminal acts.

The Convention is recognized by countries in which a sufficiently large percentage domain names are registered that it can serve the community and Internet users more effectively and fairly than any definition that ICANN might concoct.

ICANN should also acknowledge that the set of threats that fall within its remit must include all security events (“realized security threats”) in which a domain name is used during the execution of an attack for purposes of deception, for infringement on copyrights, for attacks that threaten democracies, or for operation of criminal infrastructures that are operated for the purpose of launching attacks or facilitating criminal (often felony) acts.

What is that remit?

ICANN policy and contracts must ensure that contracted parties (registrars and registries) collaborate with public and private sector authorities to disrupt or mitigate:

  • illegal interception or computer-related forgery,
  • attacks against computer systems or devices,
  • illegal access, data interference, or system interference,
  • infringement of intellectual property and related rights,
  • violation of laws to ensure fair and free elections or undermine democracies, and
  • child abuse and human trafficking.

We note that the Convention on Cybercrime identifies or provides Guidance Notes for these most prevalently executed attacks or criminal acts:

  • Spam,
  • Fraud. The forms of fraud that use domain names in criminal messaging include, business email compromise, advance fee fraud, phishing or other identity thefts.
  • Botnet operation,
  • DDoS Attacks: in particular, redirection and amplification attacks that exploit the DNS
  • Identity theft and phishing in relation to fraud,
  • Attacks against critical infrastructures,
  • Malware,
  • Terrorism, and,
  • Election interference.

In all these cases, the misuse of internet identifiers to pursue the attack or criminal activity is squarely within ICANN’s remit.

Registries or registrars should be contractually obliged to take actions that are necessary to mitigate these misuses, including suspension of name resolution, termination of domain name registrations, “unfiltered and unmasked” reporting of security threat activity for both registries and registrars, and publication or disclosure of information that is relevant to mitigating misuses or disrupting cyberattacks.

No one is asking ICANN to be the Internet Police.

The “ask” is to create policy and contractual obligations to ensure that registries and registrars collaborate in a timely and uniform manner. Simply put, the “ask” is to oblige all of the parties to play on the same team and to adhere to the same rules.

This is unachievable in the current self-regulating environment, in which a relatively small number of outlier registries and registrars are the persistent loci of extraordinary percentages of domain names associated with cyberattacks or cybercrimes and the current contracts offer no provisions to suspend or terminate their operations.

This is a guest editorial written by Dave Piscitello and Lyman Chapin, of security consultancy Interisle Consulting Group. Interisle has been an occasional ICANN security contractor, and Piscitello until last year was employed as vice president of security and ICT coordination on ICANN staff. The views expressed in this piece do not necessary reflect DI’s own.

ICANN’s new conferencing software has a webcam security bug

Kevin Murphy, July 10, 2019, Domain Tech

ICANN can’t catch a break when it comes to remote participation security, it seems.

Having just recently made the community-wide switch away from Adobe Connect to Zoom, partly for security reasons, now Zoom has been hit by what many consider to be a critical zero-day vulnerability.

Zoom (which, irrelevantly, uses a .us domain) pushed out an emergency patch for the vulnerability yesterday, which would have allowed malicious web sites to automatically turn on visitors’ webcams without their consent.

Only users of the installable Mac client were affected.

According to security researcher Jonathan Leitschuh, who discovered the problem, Zoom’s Mac client was installing a web server on users’ machines in order to bypass an Apple security feature that requires a confirmatory click before the webcam turns on.

This meant a web site owner could trick a user into a Zoom session, with their camera turned on by default, without their knowledge or consent.

If you’re in the habit of keeping your webcam lens uncovered, that’s potentially a big privacy problem, especially if you do most of your remote coverage of ICANN meetings from the toilet.

It appears that Leitschuh, who reported the problem to Zoom three months ago, took issue with what he saw as the company’s ambivalent attitude to fixing it in a timely fashion.

When he finally blogged about it on Monday, after giving Zoom a 90-day “responsible disclosure” period to issue a patch, the problem still hadn’t been fully resolved, he wrote.

But, following media coverage, Zoom’s new patch apparently removes the covert web server completely. This removes the vulnerability but means Apple users will have to click a confirmation button before joining Zoom meetings in future.

Zoom is used now for all of ICANN’s remote participation, from sessions of its public meetings to discussions of its policy-making working groups.

I really like it. It feels a lot less clunky than Adobe, and it’s got some nifty extra features such as the ability to skip around in recordings based on an often-hilarious machine-transcription sidebar, which makes my life much easier.

One of the reasons ICANN made the switch was due to a bug found in Adobe Connect last year that could have been used to steal confidential information from closed meetings.

ICANN actually turned off Adobe Rooms for remote participants halfway through its public meeting in Puerto Rico due to the bug.

The switch to Zoom was hoped to save ICANN $100,000 a year.

Airline hit with $230 million GDPR fine

Kevin Murphy, July 8, 2019, Domain Policy

British Airways is to be fined £183.39 million ($230 million) over a customer data breach last year, by far the biggest penalty to be handed out under the General Data Protection Regulation to date.

This story is not directly related to the domain name industry, but it does demonstrate that European data protection authorities are not messing about when it comes to GDPR enforcement.

About 500,000 BA customers had their personal data — including full payment card details — stolen by attackers between June and September last year, the UK Information Commissioner’s Office said today..

It is believed that they obtained the data not by hacking BA’s database, but rather by inserting a script hosted by third-party domain that executed whenever a customer transacted with the site, allowing credentials to be captured in real time.

The ICO said its decision to fine $183.39 million — which amounts to more than 1.5% of BA’s annual revenue — is preliminary and can be appealed by BA.

Under GDPR, which came into effect in May 2018, companies can be fined up to 4% of revenue.

The biggest pre-GDPR fine is reportedly the £500,000 penalty that Facebook was given due to the Cambridge Analytica scandal.

GDPR is of course of concern to the domain industry due to the ongoing attempts to make sure Whois databases are compliant with the laws.