NEEDED FOR CYBERSECURITY INVESTIGATIONS

TEMP SPEC

EPDP POLICY OUTPUT

REASONABLE ACCESS:

Reasonable access is necessary for legitimate interests in cybersecurity investigations.

Reasonable access must be provided. 

Registrar and Registry Operator 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.  (Appendix A, Sec. 4.1)

Reasonable access no longer a MUST.  Contracted parties have only the obligation to consider requests.

“The Contracted Party SHOULD make a threshold determination (without considering the underlying data) about whether the requestor has established an interest in the disclosure of personal data.” (Phase 2 Initial Report, Recommendation #6)

CENTRALIZATION:

A centralized system for data request decisions increases predictability and usability by centralizing decision-making and avoiding a fragmented system.

Decisions are decentralized at each of the registrars and registries.

Temp spec preserved Thick WHOIS, which is a form of centralization, and produced a less fragmented system. (Appendix A, 2.1)

Proposed system is a non-centralized ticketing system, leaving decisions to individual registrars.

Non-centralized ticketing intake system with inconsistent fulfillment schemes at registrar level.  (Phase 2 Initial Report, Sec. 4.1).

Unclear whether Thick WHOIS survives; there is strong disagreement between the Board and the contracted parties on the Phase 1 recommendations. (Phase 1 – Rec. 7)

ACCREDITATION:

Accreditation speeds access for trusted requestors by having requestors vetted by a preliminary validation regime.

The community should pursue an accreditation model.  (Annex item #1)

Phase 2 Policy for accreditation for SSAD users is of limited utility.  Accreditation policy provides no assurances that properly formatted requests submitted by an accredited entity will result in disclosure or access of data. (Phase 2, Rec. 1) 

ACCURACY:

Reliable, accurate underlying data is critical to investigatory capability, and is a GDPR requirement.

“Personal Data SHALL be accurate and, if necessary, kept current.”  (Appendix C, Sec. 1.4)

EPDP failed to address accuracy, leaving the matter to the GNSO, where it’s unlikely to be addressed. (Addendum Sec. 1.2)

This is in contravention of GDPR Article 5(1)d, which demands accuracy. 

LEGAL vs. NATURAL:

Legal person data is outside the remit of GDPR.  By applying GDPR to legal persons, data is unnecessarily redacted. 

ORG field which designates a legal entity’s name is UNREDACTED

(Appendix A, 2.3)

ORG field is REDACTED with no obligation to publish without consent (Phase 1 Rec 12).

EPDP failed to consider whether LEGAL PERSON data can result in automated or manual disclosures upon request.  The result is that there can be blanket denials even when there is no personal data in the record.

AUTOMATION:

Automated decision-making makes lookups more efficient and less prone to subjectivity and allows a system to scale to the cybersecurity issue at hand. 

Automated decision making can be considered.
(Sec. 7.1.15)

Also, by leaving ORG Field and CITY field UNREDACTED, automation that enabled correlation of data to bad actors was possible, based on the publicly available information.

EPDP failed to address meaningfully, letting contracted parties off the hook.

While the policy says automation is allowed only where “technically and commercially feasible and legally permissible” (Phase 2 Initial Report Sec. 3.1), proposed use cases for obvious cases of automation have been dismissed.

REVERSE WHOIS & HIGH VOLUME, INSTANTANEOUS ACCESS:

Access to non-public registrant data must be scalable and allow for requests that allow multiple domain names under common ownership and control.

Temp Spec calls for balancing query volume with realistic investigatory needs.

[Consider] Limitations in terms of query volume…balanced against realistic investigatory cross-referencing needs. (Annex item #6)

While no timelines were specified for response, there MUST be “reasonable access”.

EPDP failed to address, because it was deemed out of scope.

(Phase 2 Initial Report Recommendation 12)

No instantaneous access required; maximum response times are 30 days for regular requests, and a shorter, unspecified time for URGENT requests, applicable to requests made directly to a registry/registrar (Phase 1, Rec 18); SLAs in Phase 2 Rec 9 are for response times for requests submitted through the SSAD (i.e. 85% of responses within 24 hours for urgent requests, 2 days for non-urgent), with an acceptable response being denial of disclosure in these time periods.

DISCLOSURE BASED ON SPECIFIC CRITERIA:

Disclosures should be made for specific legitimate purposes that result in access for all properly formatted & supported requests submitted by accredited users.

Temp Spec supports a framework.

“…to address issues involving domain name registrations, including but not limited to: consumer protection, investigation of cybercrime, DNS abuse, and intellectual property protection.”  (Sec. 4.4.8)

EPDP has agreed to an updated Purpose 2 for which accredited users can submit requests for IP and cybersecurity needs, but there is no guaranteed access to data when citing these purposes.  (Phase 2, Rec 4)

DISCLOSURE TO ICANN:

ICANN needs access for compliance-related inquiries and to enforce RA and RAA.  Without such access, there is no compliance function.

Access for ICANN is mandated.

“Registry Operator and Registrar MUST provide reasonable access to Registration Data to ICANN.” (Sec. 5.7)

ICANN may get access upon request.  The EPDP’s recommendation is weak and leaves ICANN in a position where contracted parties can refuse to provide data for Compliance.

“Compliance may request data directly from the registrar or registry only as necessary.”  (Addendum Sec. 3.5)

PRIVACY/PROXY DISCLOSURE:

A WHOIS policy that doesn’t cover privacy/proxy leaves a gaping hole, impacting over 100 million registrations under privacy/proxy regimes.

Temp Spec mandates P/P registration access.

“Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email.”  (Appendix A, Sec. 2.6)

ICANN is silent on P/P implementation, and the EPDP now allows redaction of pseudonymized email addresses and refuses to take up other privacy/proxy issues.

(Phase 1, Rec. 14).

MECHANISM FOR EVOLUTION:

To be effective over time, the access model must have the ability to mature and adapt.

Temp Specification automatically evolved with changes in applicable law.

When laws, regulations or case law allows for disclosure, there MUST be disclosure (Appendix A Sec. 4.2)

EPDP has not agreed on an evolution model that does not give veto rights to either the NCSG or CPH, which will result in the status quo & no further changes, even if the law evolves to support more automated disclosures.

COMPLIANCE ENFORCEMENT CAPABILITY:

Cybersecurity needs require strict enforcement of disclosure obligations to ensure the access is predictable, scalable, and responsive.

ICANN has the ability to enforce the Temp Spec’s clearer obligations as “MUST” (e.g., MUST provide reasonable access”)

Not addressed and, in fact, made worse by a decision to turn ICANN-mandated access to “may” request data from contracted parties.  

No ability to challenge improper denials of requests.  ICANN Compliance has stated that it will NOT review individual complaints where the request has been denied.