Dear Colleagues, As you know we had a meeting with SSAC during which we discussed SSAC¹s advice on the work of the EPSRP Working Group. Yesterday SSAC met to discuss further actions, as we agreed during our discussion. Hereby I forward to you their initial response and more information on their further actions. During our Council meeting we must decide on our actions. Kind regards, ]{atrina On 06/11/16 22:21, "Patrik Fältström" <paf@frobbit.se> wrote:

Dear Katrina,

The SSAC is an advisory group to the ICANN Board and community. It is our view that our advice should stand on its own merits, and by its quality, be respected, listened to and acted upon. Because of this, we take input like this from the ccNSO very seriously. It was not our intention to be disrespectful, although we understand and regret that our message was interpreted as such.

The charter of SSAC states:

³The role of the Security and Stability Advisory Committee ("SSAC") is to advise the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems.²

This includes operational matters (e.g., pertaining to the correct and reliable operation of the root zone publication system), administrative matters (e.g., pertaining to address allocation and Internet number assignment), and registration matters (e.g., pertaining to registry and registrar services). SSAC engages in ongoing threat assessment and risk analysis of the Internet naming and address allocation services to assess where the principal threats to stability and security lie, and advises the ICANN community accordingly. The SSAC has no authority to regulate, enforce, or adjudicate. Those functions belong to other parties, and the advice offered here should be evaluated on its merits.

As part of its role, SSAC investigates whether important SSR related principles are included in policies to be implemented by ICANN, and specifically in this case, the principles explained in SAC-084, Conservatism, Inclusion and Stability. These principles should not only, for example, be included in evaluation processes like EPSRP, but must also be taken into account when policies are changed. In such a case, the SSAC advocates that policy cannot be relaxed in such a way that issues based on the processes are created and these action can not be undone.

The SSAC further understands that some comments the SSAC made on the EPSRP were on that part of the policy provided as input to the working group, and as such, did not form part of the open comment period within which the SSAC responded.

The SSAC does however see a clear relationship between confusability and security issues. Confusability can definitely lead to security issues such as phishing and it is equally as important to minimize such confusability in IDNs as it is in non-IDNs. The SSAC considers that, for security reasons, policies related to the evaluation of strings should be conservative regarding confusability.

There seems to be a misunderstanding of the SSAC¹s view on the linkage between confusability and security. For example, the Final Implementation Plan for IDN ccTLD Fast Track Process states[1], ³If the Panel identifies that a requested string may raise significant security and stability issues, or is confusingly similar to an existing TLD or applied-for TLD.² Thus, the SSAC has initiated work to review both the harmonization of IDN related processes in ICANN and the relationship between confusability and security.

Finally, as a general comment, the SSAC would like to recommend being careful when using terms like uppercase or lowercase without defining those terms. For example, by looking at stability when applying functions like toLower() to either an individual code point or a string.

The SSAC will continue to study the ccNSO document and provide complete feedback within four weeks.

Patrik Fältström SSAC Chair

1. https://www.icann.org/en/system/files/files/idn-cctld-implementation-plan- 05nov13-en.pdf sec 4.2