Response to SSR2 Pending - Likely to be Approved Recommendations Clarifying Questions for Implementation Shepherds 16 March 2022 SSR2 Recommendation 6.1 a. Is it the intent of SSR2 RT that ICANN org develop these resources for voluntary adoption or make use of already developed resources? If the latter, can the implementation shepherds provide references to those resources? As described at the beginning of Section 3 in the SSR2 Final Report, some ccTLDs are certified in accordance to ISO/IEC 27001:2013 and/or ISO 22301:2012. The idea to to encourage gTLDs to follow this example. The ccTLD that have chosen to this approach have resources, and the SSR2 RT did not envision the development of additional resources. b. How should adoption of the voluntary measures be measured? The SSR2 RT is calling for transparency and accountability in this recommendation (and many others). The SSR2 Implementation Shepherds encourage ICANN org to setup a web page that contains the audit status information for TLDs so that registrants can be informed. c. Who should determine whether the voluntary measures are sufficiently or insufficiently adopted? The SSR2 RT recommended standarized audits so that anyone can determine whether the voluntary measures have been adopted. The following web page provides an example, while recognizing that it is not totally on point: https://www.denic.de/en/content-pool/information-security-master/ d. Assuming the statement "ICANN org should implement the best practices and objectives in contracts, agreements, and MOUs” should be interpreted to read “ICANN Org should require contracted parties to implement the best practices and objectives via contracts, agreements, and MOUs”, is it the intent of the SSR2 RT for ICANN org to modify existing contracts, agreements, and MOUs to require this implementation or is the intent that future contracts, agreements, and MOUs include this requirement? While the SSR2 RT would prefer the earliest possible adoption, it is well understood that it will take time to work with all of the contracted parties, and some of them will resist change to their agreements. The recommendation is intended for these contracts to be strengthened based on the best practices and incorporated on each re-negotiated agreement or new negotiated. SSR2 Recommendation 6.2 a. What specific additional requirements does the SSR2 intend to be imposed regarding coordinated vulnerability disclosure reporting that is not already covered in the existing Coordinated Vulnerability Disclosure Reporting framework? The SSR2 RT heard about people that tried to report something and were redirected and redirected until they just gave up. The goal is to provide a single point of reporting, and it looks like the Coordinated Vulnerability Disclosure Reporting framework is intended to do that. The metric of success should be testimony from users that they were able to easily make vulnerability disclosures. b. Please provide examples of specific outcomes and/or benefits to relevant parties the SSR2 RT would expect. Success is achieved when users have an easier time with coordinated vulnerability disclosure reporting. c. Please provide examples of other potential “SSR-related issues” besides breach that should be included in such reporting to ICANN, in accordance with the SSR2 RT’s expectations for implementation of this recommendation. Please see footnote 29 in the SSR2 Final Report. The goal is to follow expert guidance regarding breaches and vulnerability disclosures. SSR2 Recommendation 7.4 a. What would the Implementation Shepherds consider would be the likelihood of an incident that impacts the whole of the United States or North America? The SSR2 Implementation Shepherds recognize that this recommendation might have been more clear had it appeared in the DNSSEC portion of the report. The point of the recommendation is to provide diversity in the jurisdiction in which the facilities that house the DNSSEC Root KSK, even if the facility outside the United States is only for DR purposes. b. The recommendation mentions Culpeper. Culpeper is only used as a KSK facility. ICANN has 2 KSK facilities; Culpeper and El Segundo. ICANN has corporate data center locations elsewhere in DC and LA separate from KSK facilities. Does this recommendation mean the locations where the corporate infrastructure is located? Or the separate locations that house the KSK/IANA infrastructure? This recommendation is about the facilities that house the DNSSEC Root KSK. c. The majority of ICANN org corporate services (payroll, finance, DMS, CMS, email, meeting services, etc.) are provided by third parties. Given that the majority of these outsourced services make up the backbone of business operations for ICANN org, can the implementation shepherds please clarify why having an additional DR site outside of U.S. territory provides enough of an added benefit to justify the additional cost? The point of the recommendation is to provide diversity in the jurisdiction in which the facilities that house the DNSSEC Root KSK. The SSR2 RT felt that this diversity is worth the additional cost. SSR2 Recommendation 9.2 a. Compliance enforces RAA obligations related to accuracy of registration data. Please clarify what this recommendation seeks from Compliance beyond what the function currently performs in this area? The SSR2 Implementation Shepherds observe that it has been three years since the SSR2 RT spoke with Compliance about this topic. At that time, Compliance told the SSR2 RT that they did not have the tools that they need. It would help the whole ICANN community if there were much greater transparency around Compliance. In the view of the SSR2 Implementation Shepherds, ICANN org should provide details of what Compliance does in this area, with supporting public documentation of how they approach it, and summary results of audits. The question seems to be aimed at a portion of SSR2 Recommendation 9.2. Please consider the whole recommendation: ICANN org should proactively monitor and enforce registry and registrar contractual obligations to improve the accuracy of registration data. This monitoring and enforcement should include the validation of address fields and conducting periodic audits of the accuracy of registration data. ICANN org should focus their enforcement efforts on those registrars and registries that have been the subject of over 50 complaints or reports per year regarding their inclusion of inaccurate data to ICANN org. In addition, please note that SSR2 Recommendation 9.3 also calls for external audits of the compliance activities, including the ones that are described above. The SSR2 Implementation Shepherds would be very comfortable with calling SSR2 Recommendation 9.2 implemented when ICANN org has published the results of the external audit results related to accuracy of maintenance registration data, and highlighting the results for registrars and registries that have been the subject of over 50 compliants or reports per year regarding their responding to queries with inaccurate WHOIS data. b. For actions that are not included in the current RAA, please explain how the SSR2 Implementation Shepherds believe Compliance can perform these actions, including the authority it believes Compliance has to carry out these actions. The SSR2 RT is calling for transparency and accountability. The SSR2 RT did not see any conflict in the recommended actions and the current RAA. If ICANN org believes otherwise, a public explanation of the conflict is the next appropriate action. This recommendation can be considered implemented when audits are happening regularly, and summaries published. SSR2 Recommendation 16.2 a. Please clarify the purpose the RT identified for the creation of specialised groups within Compliance that understands privacy requirements and principles? In the SSR2 Final Report, the three paragraphs before SSR2 Recommendation 16 explain the purpose for the three recommendations in this section. In fact, the last paragraph repeats a request by the RDS review team that was not implemented. b. What kind of role would these groups play? Is the RT suggesting that these new groups should be responsible for enforcement of non-ICANN mandated policies that Contracted Parties might choose to apply to their operations? The role of these groups would be to implement SSR2 Recommendations 16.1, 16.2, and 16.3. They would not be responsible for enforcing registry and registrar policies, but they can track them. For example, ICANN org could require registries and registrars to provide a link to their privacy policies, and then ICANN org can automate publishing the the policies in the online index of registrars. More importantly, this group ought to provide legal expertise and support for law enforcement and consumer protection representatives during evolution of the RDS framework. c. Please describe any current deficiencies the RT identified in enforcement of the RA/RAA privacy requirements. The SSR2 Implementation Shepherds believe facilitate law enforcement and consumer protection needs under the RDS framework while preserving privacy to the greatest extent possible. SSR2 Recommendation 16.3 a. Please explain how the SSR2 Implementation Shepards believe ICANN Compliance can perform audits of privacy policies adopted by registrars outside the requirements of the RAA and community-developed policy, including the authority it believes Compliance has to carry out these actions. The SSR2 Final Report asks the registrars to have procedures in place to address privacy breaches. The SSR2 RT did not ask for an audit that these procedures are followed. Under GDPR, CCPA, and other emerging privacy regulation, the SSR2 Implementation Shepherds think that the procedures should be publicly available. This aspect of transparency is likely to be required regardless of any action taken by ICANN at this point. SSR2 Recommendation 20.1 a. ICANN org has a small internal team that conducts this type of work and there are also many unknowns about the research level (e.g. what an algorithm roll would entail; whether an 'empirically verifiable' business process is accomplishable). Because of this, ICaNN org proposes that it would be more realistic and practical to have a process that contains evaluation checkpoints that allow circumstances to be assessed and provide for a potential course correction. Would the RT find this acceptable? The recommendation is based on research and live clinical results that have already been produced, and an openly available process-definition tool (based on a formal language) called Little-JIL. The research that was conducted used this tool and process definition language to model live patient medical processes (i.e., specifying the process that doctors must follow when treating patients to ensure their medical safety). The SSR2 RT felt that this research would generalize to key transitions in the DNSSEC Root zone, which would likely be far less complex than the medical processes that were modeled and implemented in the research literature. Please see footnote 117 in the SSR2 Final Report for two references to this research. Little-JIL uses a graphical interface to construct processes, which is likely to be as helpful to DNSSEC Root key management as it was to doctors and patients in the medical setting.