ICANN’s Registration Data Request System and the need to resolve WHOIS access

Access to domain name Registration Data identifying the person(s)/organizations which own and manage different web properties has historically been invaluable in conducting cybersecurity investigations and reducing threats. This information, held by registrars, can help identify who is responsible for malicious domains and prevent them from creating more. Unfortunately, reliable access to WHOIS data was disrupted more than five years ago when the Internet Corporation for Assigned Names and Numbers (ICANN) updated its WHOIS policy to address privacy concerns. Since then, ICANN has been charged with finding a solution to restore access to this data when there are legitimate requests. To this end, ICANN is preparing to launch a new tool this month, the Registration Data Request System (RDRS), to streamline WHOIS requests so registrars can more easily process them. Restoring access to this critical data for legitimate purposes has been a priority for the Cybersecurity Tech Accord for years, and while it is encouraging to see ICANN taking action there remain concerns surrounding the RDRS platform and whether it can be effective for its purpose. 

A long-standing problem

Almost immediately after the European Union’s General Data Protection Regulation (GDPR) came into effect in May 2018, ICANN agreed to a Temporary Specification (the “Temp Spec”) that largely eliminated a user’s access to Registration Data (previously referred to as WHOIS). In November 2018, the Cybersecurity Tech Accord signatories released a public statement to ICANN emphasizing how ICANN’s decision to agree to the Temp Spec. had de facto undermined an essential tool to protect internet users from online threats. At the time, the Cybersecurity Tech Accord signatories welcomed ICANN’s plans to develop a comprehensive framework for accreditation and access but underscored the need for action to be taken immediately to protect the public interest. This action would ensure interim access to WHOIS for cybersecurity uses, and to quickly develop a permanent model providing uniform, swift and enforceable access to WHOIS data that balances both privacy and security concerns.

Three years later, in April 2021, ICANN finally announced the launch of an Operational Design Phase (ODP) for the System for Standardized Access/Disclosure to Nonpublic Registration Data (SSAD) policy recommendations. The culmination of the SSAD ODP was an operational framework which was intended to:

  • Provide a “one stop shop” to Requestors for account setup and verification. 
  • Provide a repeatable request process for Requestors.
  • Reduce or potentially eliminate the need for Contracted Parties to identify Requestors. 
  • Provide some predictability for response times (SLAs) to requests. 
  • Provide automated disclosures in limited circumstances.

The price tag for the development of SSAD was projected to be between $20-27 million and was estimated to take up to 3-4 years for the development alone. 

In February 2023, almost five years after the promulgation of GDPR, and years after ICANN’s stated desire to develop a system to address WHOIS, the SSAD system was put on “hold” and ICANN turned to a less expensive and more temporary solution called the Registration Data Request System (RDRS). The purpose of this new temporary service was to gather “usage and demand data” that can inform the ICANN Board’s evaluation of whether to implement the SSAD. In other words, if there is not enough demand for Registration Data through the RDRS then ICANN will be less inclined to spend additional money and resources on developing the more robust SSAD system. 

Operationalizing the RDRS and key concerns

ICANN now expects to release the RDRS in November 2023. The new RDRS ticketing proof of concept is designed to:  

  • be used by ICANN-accredited registrars that opt-in to participate.
  • be used by individuals and entities such as law enforcement, government agencies, intellectual property attorneys, cybersecurity professionals, among others, with a legitimate interest for access to nonpublic gTLD registration data.
  • benefit Registrars since they can manage and track all requests in a single location.
  • route requests to the appropriate responding registrar potential action, with all interaction between the registrars and requestors to occur outside the system.

While the Cybersecurity Tech Accord signatories welcome the new RDRS ticketing system, there are several concerns worth highlighting. First, if the primary goal of the RDRS is to measure global demand for registration data, the system is ill-designed for that specific purpose. The system does not log a notice if the registrar is not participating in the RDRS. Instead, it will only capture incoming requests for participating registrars and ignore any notices for non-participating registrars. With over 2000 registrars, there may well be hundreds of notices that go uncatalogued as a result. In addition, if enough registrars do not participate in (or drop out of) the RDRS then requestors may very well not send in any requests since this would be an effort in futility. This in turn might give the incorrect appearance that there is little to no demand for access to WHOIS data. 

Second, the key to initiating development of the SSAD system would be to achieve “success” as it relates to processing of requests within the RDRS. But, once again, the RDRS is not designed for this purpose. If all the interactions between the registrars and requestor occurs outside the system, it would be difficult to measure the overall success of the RDRS (i.e., whether compliant or non-compliant responses are being received by requestors). It would therefore be incumbent on each requestor to keep proper records to be provided to ICANN, sua sponte.  Moreover, the system currently does not accommodate notices to or responses from other potential responders such as proxy/privacy service providers and registries. There are documented instances where registries and proxy/privacy providers would provide compliant responses to requests when registrars may not. Without a doubt, having these stakeholders as an integral part of the RDRS ecosystem would increase the success of this proof of concept. 

A pressing challenge that needs a comprehensive solution

As we have pointed out in the past, restrictions on users’ real-time access to registration data has had a material impact on the safety and security of businesses and individuals online. We have highlighted several cases studies in the past to prove this point, including Facebook and FireEye’s respective investigations into Liberty Front Press, Facebook’s (now Meta’s) investigation into Instagramn.xyz’ phishing attack, Microsoft’s ongoing investigation around Strontium/APT28, and Panasonic’s work to protect customers and brand from domain phishing attempts. (See Cybersecurity Tech Accord Statement dated November 18, 2018). 

The Cybersecurity Tech Accord signatories once again reiterate the need for a comprehensive system to protect Internet users from online threats. This is even more necessary in light of the new WHOIS obligations created by the European Union’s recently revised Directive on Network and Information Systems (NIS2), where registries and registrars serving the European Union are required to maintain complete, accurate, and verified databases of domain name contract information, and respond to disclosure requests from legitimate access seekers.

While the RDRS is a welcome start, it does not, on its face, appear to provide the necessary requirements to prove out the demand for registration data and the ultimate success of the RDRS. Accordingly, The Cybersecurity Tech Accord encourages ICANN to update the RDRS and its corresponding domain name policies on WHOIS to be aligned with NIS2.