SEPTEMBER 2013 – SSAC Liaison Report
(as at 22Sep13)
1. SSAC MEETINGS. The SSAC Meeting scheduled on 12 September was cancelled.
2. SSAC WORK PARTIES. I am currently participating in two SSAC Work Parties:
- Identifier Abuse Metrics Work Party – Participated in a teleconference with a survey participant on 29 August but was an apology for the Work Party Meeting on 12 September due to my travel schedule.
- DNS Abuse Work Party - I was an apology for the meetings on 5 and 19 September due to my travel schedule.
3. BOARD RISK MANAGEMENT FRAMEWORK WORKING GROUP. Having received the final report by Westlake Governance, the Board-level DNS Risk Management Framework Working Group (DNS RMF WG) has initiated a public comment cycle prior to sending the Framework to the ICANN Board and staff for implementation. I drafted an initial response which has been updated by Olivier Crepin-Leblond, with input from Alejandro Pisanty, and the final draft is currently being voted upon.
4. SSAC WORKSHOP. The SSAC Workshop is being held on 24-26 September in Los Angeles. Unfortunately, because of prior commitments, I am unable to attend and unlikely to be able to join by teleconference.
5. RELEASE OF SAC061: SSAC COMMENT ON ICANN’S INITIAL REPORT FROM THE EXPERT WORKING GROUP ON GTLD. On 6 September, the SSAC released SAC061 in response to the Initial Report of the EWG. In that report, the following four recommendations were made:
Recommendation 1: SSAC reiterates its recommendation from SAC055: The ICANN Board should explicitly defer any other activity (within ICANN’s remit) directed at finding a ‘solution’ to ‘the WHOIS problem’ until the registration data policy has been developed and accepted in the community. The EWG should clearly state its proposal for the purpose of registration data, and focus on policy issues over specific implementations.
Specifically, SSAC does not believe the EWG has answered the question of the purpose of registration data. A clear statement of the purpose is essential before a thorough and complete risk analysis can be completed of the proposed next generation directory services.
Recommendation 2: The ICANN Board should ensure that a formal security risk assessment of the registration data policy be conducted as an input into the Policy Development Process.
A separate security risk assessment should also be conducted regarding the implementation of the policy.
Recommendation 3: SSAC recommends that the EWG state more clearly its positions on the following questions of data availability:
A. Why is a change to public access justified? This explanation should describe the potential impact upon ordinary Internet users and casual or occasional users of the directory service.
B. Does the EWG believe that access to data currently accessible in generic Top Level Domain (gTLD) WHOIS output should become restricted? If so, what fields and to what extent exactly? Under the EWG proposal, queries from non- authenticated requestors would return only “public data available to anyone, for any purpose”. At this time it is unspecified what the set of “public data available to anyone” is, and therefore it is unclear if the infrequent or non-professional users will lose access to data they rely upon, when they need it. It appears that Annex C may recommend that non-authenticated users be denied access to several data elements that they can access today via WHOIS. Annex C also neglects to mention Administrative, Technical, and Billing contacts. Will access to a currently public source of data be degraded and made less useful for a large number of users so that a smaller number of users can receive enhanced access, and if so why is such a shift justified?
C. Should all gTLD registries be required to provision their contact data into the Aggregated Registration Data Service (ARDS)? There may be jurisdictions that prohibit by law the export of personally identifiable information outside the jurisdiction. If so, the ARDS may not be a viable way to deliver data accuracy and compliance across all gTLDs.
D. Does the EWG propose more types of sensitive registration data be provisioned into ARDS than are found in current gTLD WHOIS output? This question was left unanswered in Annex C. Proposals to do so should be justified.
a. For example, the EWG listed the Internet Protocol (IP) address of the registrant as a type of registration data. Does the EWG propose that this data be provisioned by registrars to the registries, and then from the registries into the ARDS and made available to those parties with a need to perform the stated purpose of “Abuse Mitigation”? In such cases, the EWG needs to demonstrate a justification that goes beyond saying that the provisioning of such data would “serve the purpose” of certain data consumers. Instead, the question is whether giving additional parties access to such data is a good idea, and how it might be justified.
b. The EWG also listed “EPP Transfer Key” as a type of registration data. We assume this is the EPP auth_info code for a domain. The provisioning of EPP auth_info codes into a meta-registry poses a major security risk and should never be allowed.
Recommendation 4: The SSAC suggests that the EWG address this recommendation from SAC058: “SSAC Report on Domain Name Registration Data Validation”:
As the ICANN community discusses validating contact information, the SSAC recommends that the following meta-questions regarding the costs and benefits of registration data validation should be answered:
- What data elements need to be added or validated to comply with requirements or expectations of different stakeholders?
- Is additional registration processing overhead and delay an acceptable cost for improving accuracy and quality of registration data?
- Is higher cost an acceptable outcome for improving accuracy and quality?
Would accuracy improve if the registration process were to provide natural persons with privacy protection upon completion of multi-factored validation?
