ICANN’s Inaction on NIS2 Tests the Effectiveness of the Multistakeholder Model

Home / Blogs

ICANN’s Inaction on NIS2 Tests the Effectiveness of the Multistakeholder Model

	By Mason Cole Internet Governance Advisor at Perkins Coie
	December 11, 2023 Views: 9,883 Comments: 5

ICANN’s response to the European Union’s Network and Information Security Directive (NIS2) is a litmus test on whether its policy processes can address the needs of all stakeholders, instead of only satisfying the needs of the domain industry. Early indications from the ICANN Hamburg meeting point to another disappointment for law enforcement, cybersecurity professionals, and the many businesses seeking to reinstate WHOIS as required by NIS2. ICANN should change course and update its global WHOIS policy to be consistent with NIS2, as called for by the CyberTech Accord in its recent blog.

Background

Years-long inaction on ICANN’s part has led to governmental frustration in lack of progress on critical issues, like DNS abuse, domain name registration data policy, and other matters of importance. It’s been proven again that when ICANN isn’t proactive on issues such as these, a vacuum is created, enabling others to step in to manage needed changes through fragmented regulation.

This has been the case with NIS2, a directive that clarified the legal basis under the General Data Protection Regulation (GDPR) to collect, maintain, and disclose “WHOIS” information—the registration data of domain name owners. ICANN, by its own admission, was late to the game in terms of updating its global WHOIS policy to be consistent with GDPR. Then, registries and registrars (“contracted parties”) managed to over-correct in addressing GDPR (with ICANN’s complicity) in a way that has nearly completely hidden WHOIS data from those who rely on it to prevent or mitigate online harms. The stated reason for the over-correction was uncertainty over whether GDPR allowed access to WHOIS data. But now, the pendulum has swung too far in the direction of: “We don’t care—no one can have this data.”

During these delays, DNS abuse continued to grow exponentially (see, for example, Interisle Consulting Group’s August 2023 phishing landscape report, which documented a tripling of phishing attacks over the previous three-year period). This prompted a response by the European Commission (EC), which observed the gulf created between a blanked WHOIS and cybercrime growth and included revised WHOIS policy in Article 28 of the NIS2 directive. Without ICANN brokering a compromise between the “we really need some data, and we’ll play by data access rules” and “no, you can’t have it” camps, the EC stepped in.

NIS2 accomplished what ICANN did not: a reasonable compromise on WHOIS data access, including distinguishing between legal and natural person data, free-of-charge access, reasonable response times, and the like. The rest of the world sees relief on the horizon.

Prior to the start of the Hamburg meetings, a gathering of (mostly) contracted parties seemed to realize for the first time what NIS2 requires. There was heightened concern about the operational changes necessary for compliance. EU representatives reminded registries and registrars that NIS2 is long established, will become EU member state law, and will require some retrofitting in order to come into compliance, such as to require all registries to maintain complete, accurate, and verified WHOIS.

We’re now at risk of seeing a repeat of the last-minute rush to comply with GDPR in 2018. While ICANN’s current position appears to be that NIS2 compliance is no worry, the community isn’t so sure and is hoping ICANN will come around to reconcile the conflicts between ICANN’s current policy and NIS2. A chart (shown at the end of this post) developed by members of the Commercial Stakeholder Group identifying these differences could serve the starting point for a new Temporary Specification to update global WHOIS policy to track NIS2.

Failure to do so endangers the ICANN model—of which the great majority of us are fans. It’s safe to say that no one wants to see ICANN moving further towards the precipice—things already are tenuous enough.

To be clear, this is not an editorial of derision of the ICANN model. But if we want to maintain our independence as a community of DNS coordinators, prevent the almost certain attempt by some world powers to gain control of this critical resource and shut out important voices (with WSIS+20 just around the corner), we need to do better to be inclusive and find compromise. It’s not too late.

Issue	EPDP Phase 1	IRT Draft Policy	NIS2 Language
Registries—Thick WHOIS	Rec #7. The EPDP Team recommends that the specifically-identified data elements under “[t]ransmission of registration data from Registrar to Registry”, ... must be transferred from registrar to registry provided an appropriate legal basis exists and data processing agreement is in place. [EXCLUDES CONTACT DATA]	Section 7.5 Registrar MAY transfer the following data elements to Registry Operator if supported by the Registry Operator.	(109) Maintaining accurate and complete databases of domain name registration data (WHOIS data) and providing lawful access to such data is essential to ensure the security, stability and resilience of the DNS, which in turn contributes to a high common level of cybersecurity across the Union. For that specific purpose, TLD name registries and entities providing domain name registration services should be required to process certain data necessary to achieve that purpose. Such processing should constitute a legal obligation within the meaning of Article 6(1), point (c), of Regulation (EU) 2016/679. That obligation is without prejudice to the possibility to collect domain name registration data for other purposes, for example on the basis of contractual arrangements or legal requirements established in other Union or national law. Article 28: 1. For the purpose of contributing to the security, stability and resilience of the DNS, Member States shall require TLD name registries and entities providing domain name registration services to collect and maintain accurate and complete domain name registration data in a dedicated database with due diligence in accordance with Union data protection law as regards data which are personal data.
Purpose Statement	Rec 1, Purpose 2: “Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission through enabling responses to lawful data disclosure requests.”	None	See Recital 109 (above). (110) The availability and timely accessibility of domain name registration data to legitimate access seekers is essential for the prevention and combating of DNS abuse, and for the prevention and detection of and response to incidents.
Complete and Accurate Database	None	None	(109) - That obligation aims to achieve a complete and accurate set of registration data and should not result in collecting the same data multiple times. The TLD name registries and the entities providing domain name registration services should cooperate with each other in order to avoid the duplication of that task.
Administrative Contact	Rec 5:The EPDP Team recommends that the data elements ... (are required to be collected by registrars. [Excludes admin contact] Rec 29: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no or incomplete Registered Name Holder contact information, the EPDP team recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains Registered Name Holder contact information.	Section 6.1 of Draft Policy lists data elements that MUST be collected (excludes admin). Section 6.8: Registrar MAY delete administrative contact data that was collected prior to the effective date of this Policy.	Article 28 2. For the purposes of paragraph 1, Member States shall require the database of domain name registration data to contain the necessary information to identify and contact the holders of the domain names and the points of contact administering the domain names under the TLDs. Such information shall include: (a) the domain name; (b) the date of registration; (c) the registrant’s name, contact email address and telephone number; (d) the contact email address and telephone number of the point of contact administering the domain name in the event that they are different from those of the registrant.
Verification of Contacts	Rec 4: The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy.	N/A	Article 28 3. Member States shall require the TLD name registries and the entities providing domain name registration services to have policies and procedures, including verification procedures, in place to ensure that the databases referred to in paragraph 1 include accurate and complete information. Member States shall require such policies and procedures to be made publicly available.
Accuracy of Registration Data	Rec 4: The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy.	N/A	(111) In order to ensure the availability of accurate and complete domain name registration data, TLD name registries and entities providing domain name registration services should collect and guarantee the integrity and availability of domain name registration data. In particular, TLD name registries and entities providing domain name registration services should establish policies and procedures to collect and maintain accurate and complete domain name registration data, as well as to prevent and correct inaccurate registration data, in accordance with Union data protection law. ... The TLD name registries and the entities providing domain name registration services should adopt and implement proportionate procedures to verify domain name registration data. Those procedures should reflect the best practices used within the industry and, to the extent possible, the progress made in the field of electronic identification. Examples of verification procedures may include ex ante controls carried out at the time of the registration and ex post controls carried out after the registration. The TLD name registries and the entities providing domain name registration services should, in inparticular, verify at least one means of contact of the registrant.
Legitimate Access Seekers		N/A	(110) The availability and timely accessibility of domain name registration data to legitimate access seekers is essential for the prevention and combating of DNS abuse, and for the prevention and detection of and response to incidents. Legitimate access seekers are to be understood as any natural or legal person making a request pursuant to Union or national law. They can include authorities that are competent under this Directive and those that are competent under Union or national law for the prevention, investigation, detection or prosecution of criminal offences, and CERTs or CSIRTs. Article 28 5. Member States shall require the TLD name registries and the entities providing domain name registration services to provide access to specific domain name registration data upon lawful and duly substantiated requests by legitimate access seekers, in accordance with Union data protection law.
Response SLAs for Disclosures	Rec 18—SLA is 30 days	Section 10.5-6 of Draft Policy is 30 days, with urgent requests subject to 2 business days	Article 28 5. ...Member States shall require the TLD name registries and the entities providing domain name registration services to reply without undue delay and in any event within 72 hours of receipt of any requests for access. Member States shall require policies and procedures with regard to the disclosure of such data to be made publicly available.
Publication of Legal Person’s Data	Rec 17: 1) The EPDP Team recommends that Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so.	Section 9.2.2 of Draft Policy makes it optional and allows redactions	(112) TLD name registries and entities providing domain name registration services should be required to make publicly available domain name registration data that fall outside the scope of Union data protection law, such as data that concern legal persons, in line with the preamble of Regulation (EU) 2016/679. For legal persons, the TLD name registries and the entities providing domain name registration services should make publicly available at least the name of the registrant and the contact telephone number. The contact email address should also be published, provided that it does not contain any personal data, such as in the case of email aliases or functional accounts. Article 28 4. Member States shall require the TLD name registries and the entities providing domain name registration services to make publicly available, without undue delay after the registration of a domain name, the domain name registration data which are not personal data.
Disclosure of non-public data on request	EPDP Rec 18—limited to requests- not access, with no guarantees of disclosure for lawful and substantiated requests	Section 10.1-5 of draft policy	(112) ...TLD name registries and entities providing domain name registration services should establish policies and procedures for the publication and disclosure of registration data, including service level agreements to deal with requests for access from legitimate access seekers. Those policies and procedures should take into account, to the extent possible, any guidance and the standards developed by the multi-stakeholder governance structures at international level. Article 28: 5. Member States shall require the TLD name registries and the entities providing domain name registration services to provide access to specific domain name registration data upon lawful and duly substantiated requests by legitimate access seekers, in accordance with Union data protection law.
Access Procedures		REDRESS is a request system, not an access system	(112) ...The access procedure could include the use of an interface, portal or other technical tool to provide an efficient system for requesting and accessing registration data.
Service Level Agreement for Responses	Rec #18-Response time for a response to the requestor will occur without undue delay, but within maximum of 30 days unless there are exceptional circumstances.	10.5 Registrar and Registry Operator MUST acknowledge receipt of a Reasonable Request for Lawful Disclosure, which meet the format required by Registrar or Registry Operator, without undue delay, but no more than two (2) business days from receipt and MUST respond without undue delay, but no more than thirty (30) calendar days from acknowledgement absent exceptional circumstances.	Article 28, Section 6: Member States shall require the TLD name registries and the entities providing domain name registration services to reply without undue delay and in any event within 72 hours of receipt of any requests for access.
Reseller Obligations	Optional to collect Reseller Data	Collecting Reseller Information is optional (Draft Policy Section 6.1)	Article 6 Definitions (22) ‘entity providing domain name registration services’ means a registrar or an agent acting on behalf of registrars, such as a privacy or proxy registration service provider or reseller. Article 28 [All of the requirements apply equally to resellers because they apply to “entities providing domain name registration services.”
Proxy Obligations	Rec 14 In the case of a domain name registration where an “affiliated” privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar (and Registry where applicable) MUST include in the public RDDS and return in response to any query full non-personal RDDS data of the privacy/proxy service, which MAY also include the existing privacy/proxy pseudonymized email.	N/A	Article 6 Definitions (22) ‘entity providing domain name registration services’ means a registrar or an agent acting on behalf of registrars, such as a privacy or proxy registration service provider or reseller. Article 28 [All of the årequirements apply equally to privacy/proxy services because they apply to “entities providing domain name registration services.”
Charges for Access	None	N/A	(112) Member States should ensure that all types of access to personal and non-personal domain name registration data are free of charge.

By Mason Cole, Internet Governance Advisor at Perkins Coie

Filed Under

Comments

Another option Rubens Kuhl – Dec 11, 2023 4:12 PM

Perhaps NIS2 doesn’t require reinstation of WHOIS, and the whole premise of this article is flawed ? Or, if ICANN is reading NIS2 wrong, file a suit in Belgian court as soon as Belgium publishes its implementation of the directive ?

# 1 Reply | Link | Report Problems

Why change when already fully compliant? Volker Greimann – Dec 12, 2023 1:39 AM

Nothing in current ICANN policy prohibits registrars and registries from complying with appicable law. Nothing in current ICANN policy prohibits full compliance with NIS2. Current ICANN policy is therefore already in full compliance with NIS2, even though contracted parties and other parties providing registration services (resellers) may have some adapting of their current processes to do.
It is helpful that the NIS2 indirectly references current ICANN policies as a model how to do so.

# 2 Reply | Link | Report Problems

IF ICANN is Replaced, They Have Only Themselves to Blame Rick Lane – Dec 13, 2023 5:57 AM

This is an excellent overview of how the EU has stepped in to correct ICANN’s failure to fix the Dark WHOIS issue that puts EU cybersecurity, child protection, and consumer privacy at risk and the real risk to ICANN’s future by not hearing the clarion calls.

It is also a shame that after more than 5 years of ICANN’s decision to allow WHOIS to go dark, the US Congress and Biden Administration have yet to enact legislation following the EU’s lead to protect US cybersecurity, children, and consumer privacy. Instead, the Dept of Commerce and NTIA are trying to make the .US ccTLD go Dark (https://lnkd.in/eGrp7ED4
). Studies have shown the .US already has the most domain name abuse/cybersecurity risk of any ccTLD, outpacing China (.cn) and Russia (.ru) country codes.

# 3 Reply | Link | Report Problems

Whois did not go dark Volker Greimann – Dec 13, 2023 7:48 AM

Whois just became compliant with data privacy laws and regulations. Blasting the personal information of all registrants into the ether for all to see was problematic from a privacy perspective for a long time and seeing it adressed with the event of the GDPR resulted in a great reduction in the receipt of spam, identity theft, phishing and other abuse registrants were regularly and in volume subjected to. The new obligations regarding publication of legal entity data will not prevent one incident of DNS abuse, or do you believe criminals go out of their way to register legal entities to register their domains? This is not happening now and will not be likely to happen in the future either...

# 4 Reply | Link | Report Problems

If ICANN is Replaced, They Have Only Themselves to Blame Rick Lane – Dec 13, 2023 5:58 AM

# 5 Reply | Link | Report Problems

The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.