September 2019 - Ssr2-review

SSR2 Face to Face Day 2 | 2 November 2019
by MSSI Secretariat Sept. 30, 2019

Sept. 30, 2019

SAVE THE DATE: SSR2 Face to Face Meeting - Day 2 at ICANN66 | Montreal Saturday, 2 November 2019 -- 9:00 AM - 5:00 PM/EDT (local Montreal time) -- time zone support here<https://www.timeanddate.com/worldclock/fixedtime.html?msg=SSR2+Face+to+Face…> Remote participation details TBA.

1 0

SSR2 Face to Face Day 1 | 1 November 2019
by MSSI Secretariat Sept. 30, 2019

Sept. 30, 2019

SAVE THE DATE: SSR2 Face to Face Meeting - Day 1 at ICANN66 | Montreal Friday, 1 November 2019 -- 9:00 AM - 5:00 PM/EDT (local Montreal time) -- time zone support here<https://www.timeanddate.com/worldclock/fixedtime.html?msg=SSR2+Face+to+Face…> Remote participation details TBA.

1 0

Operating Standards recommendations text
by Jennifer Bryce Sept. 30, 2019

Sept. 30, 2019

Dear SSR2 Review Team members, For your reference, the Operating Standards for Specific Reviews are available here: https://www.icann.org/en/system/files/files/operating-standards-specific-re…. As a reminder and as discussed on the call last week, the Operating Standards were adopted by the ICANN Board on 23 June 2019. As the SSR2 Review was already in progress when the Operating Standards were adopted, the team may choose whether it wishes to operate under the Operating Standards. Below is a cut and paste of the section in the document related to review recommendations (see page 26), as requested on the call last week. Please let us know if you have further questions. 4.1 Recommendations Review team members are empowered to formulate recommendations based on their research and evaluation of facts. The review team is expected to use all reasonably available information to provide answers, solutions, and recommendations to the issues, problems, and questions raised within the scope of the review. The review team is encouraged to provide context, inputs received, and overview of relevant discussions as they pertain to each of the recommendations. The review team should state each finding clearly and the corresponding recommendation. To help assure effective implementation and long-lasting improvements, the review team is expected to address all issues raised in the scope and provide specific, measurable, achievable, realistic, and time-bound (SMART) recommendations based on fact-based findings. The review team is strongly encouraged to lay out problems it discovered and explain how its recommendations will address these, leading to substantive improvements. To facilitate the eventual implementation of its recommendations, the review team shall include, wherever possible, relevant metrics and applicable key performance indicators (KPIs) that could be applied to assess the implementation of each of its recommendations. To assure the feasibility and usefulness of its recommendations, the review team shall consult with ICANN organization and Board in addition to its community-wide outreach. An open and transparent exchange between the review team, subject matter experts, ICANN organization, ICANN Board must occur so that the identified problems, the recommended solutions, and the expected impact of implementation is clearly defined and well understood by all. The review team shall take into consideration the expected impact of implementation on ICANN resources and on the ICANN community workload. Also, the review team should consider whether there is sufficient community capacity and expertise to ensure successful implementation. These considerations should not limit the number of recommendations a review team may issue. Recommendations shall address specific problems as identified by the review team. Review teams are encouraged to categorize each recommendation as ‘high priority’, ‘medium priority’, or ‘low priority’, as a useful guideline for the planning of the implementation work, as prescribed in the Bylaws (Section 4.6 (a) (vii) (A)). Best, Jennifer -- Jennifer Bryce MSSI Associate Project Manager Internet Corporation for Assigned Names and Numbers (ICANN) Email: jennifer.bryce(a)icann.org Skype: jennifer.bryce.icann www.icann.org

1 0

Re: [Ssr2-review] [EXT] Re: Internet Hall of Fame Inductions
by Barrett, Kerry-Ann Sept. 28, 2019

Sept. 28, 2019

Congrats KC :) Sincerely, Kerry-Ann Barrett Cybersecurity Policy Specialist Organization of American States On Sep 27, 2019, at 12:47 PM, Matogoro Jabera <jaberamatogoro(a)gmail.com<mailto:jaberamatogoro@gmail.com>> wrote: CAUTION: EXTERNAL SENDER Congratulations KC, you really deserved it taking it account the contribution you made to the broad area. On Fri, 27 Sep 2019, 17:27 Steve Conte, <steve.conte(a)icann.org<mailto:steve.conte@icann.org>> wrote: I’d like to say Congratulations to KC for being inducted into the Internet Hall of Fame https://www.internethalloffame.org/blog/2019/09/27/2019-internet-hall-fame-… Steve _______________________________________________ Ssr2-review mailing list Ssr2-review(a)icann.org<mailto:Ssr2-review@icann.org> https://mm.icann.org/mailman/listinfo/ssr2-review _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Ssr2-review mailing list Ssr2-review(a)icann.org<mailto:Ssr2-review@icann.org> https://mm.icann.org/mailman/listinfo/ssr2-review _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

2 1

Mozilla Fellow 2019 - 2020
by Matogoro Jabera Sept. 27, 2019

Sept. 27, 2019

https://foundation.mozilla.org/en/blog/introducing-our-29-newest-mozilla-fe… Dear Colleagues, It is a great honor to join 29 Mozilla Fellows for the year 2019 - 2020 hailing from more than 10 countries globally. I understand it has come with great responsibility BUT I promise with the help of my almighty God who cares much about me, I will be able to make it. It is also a honor to all of those who cares and support my work. Regards, Matogoro

2 1

Re: [Ssr2-review] [EXT] Mozilla Fellow 2019 - 2020
by Barrett, Kerry-Ann Sept. 27, 2019

Sept. 27, 2019

Congrats Matogoro Sincerely, Kerry-Ann Barrett Cybersecurity Policy Specialist Organization of American States On Sep 27, 2019, at 12:49 PM, Matogoro Jabera <jaberamatogoro(a)gmail.com<mailto:jaberamatogoro@gmail.com>> wrote: CAUTION: EXTERNAL SENDER https://foundation.mozilla.org/en/blog/introducing-our-29-newest-mozilla-fe… Dear Colleagues, It is a great honor to join 29 Mozilla Fellows for the year 2019 - 2020 hailing from more than 10 countries globally. I understand it has come with great responsibility BUT I promise with the help of my almighty God who cares much about me, I will be able to make it. It is also a honor to all of those who cares and support my work. Regards, Matogoro _______________________________________________ Ssr2-review mailing list Ssr2-review(a)icann.org<mailto:Ssr2-review@icann.org> https://mm.icann.org/mailman/listinfo/ssr2-review _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

1 0

Internet Hall of Fame Inductions
by Steve Conte Sept. 27, 2019

Sept. 27, 2019

I’d like to say Congratulations to KC for being inducted into the Internet Hall of Fame https://www.internethalloffame.org/blog/2019/09/27/2019-internet-hall-fame-… Steve

5 4

SSR2 RT Engagement Session | ICANN66 Montreal | 4 November 2019
by MSSI Secretariat Sept. 27, 2019

Sept. 27, 2019

Engagement Session with SSR2 Review Team at ICANN66 | Montreal<https://community.icann.org/x/IZQCBw> Zoom Link: TBA Date: Monday, 4 November 2019 Time: 15:15-16:45 local Montreal time - additional time zone support here<https://www.timeanddate.com/worldclock/fixedtime.html?msg=SSR2+Engagement+S…> Location: 518

1 0

Questions re: the Recommendations from the Abuse/Compliance sub-team
by Heather Flanagan Sept. 27, 2019

Sept. 27, 2019

Hello all These questions relate specifically to the Recommendations section offered by the Abuse/Compliance sub-team, starting on page 31 of the Google doc. As mentioned in my note with questions re: the findings, I am happy to put these questions in the doc itself, but am uncertain who should be assigned to the comments to make sure they are addressed. https://docs.google.com/document/d/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXm… <https://docs.google.com/document/d/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXm…> — 1. Does this mean separate the registrar/registry compliance activities from all other ICANN activities, or separate them from each other? "Since ICANN derives most of its funding from registrars and registries, it should separate its registrar and registry compliance activities to ensure neutral and effective compliance with contracts.” (Page 32 of the Google doc) — 2. I’m increasingly confused in how the team uses the word “Compliance”. Sometimes that seems to refer to an action, sometimes a department, sometimes an initiative. For example: "The ICANN Board must empower the Compliance Office to react to complaints and require Compliance to initiate investigation and enforce against those aiding and abetting systemic abuse.” Do you have any suggestions on how I might differentiate between the different uses of Compliance? It feels a lot like the differences between ICANN, ICANN Org, ICANN community… — 3. I can parse this sentence right up to the “act now” component. The recommendation seems to suggest that ICANN should use the current definition while also support redefining it by using the definitions outlined in the Convention on Cybercrime. Can someone help clarify what’s expected here? "Abuse Definitions & Reporting - ICANN Board and ICANN Org should overhaul ICANN’s approach to DNS abuse definitions, tracking and reporting, including implementing community review recommendations and other security-related actions, act now using the current “DNS abuse” definition and in parallel use international conventions to evolve the definition, create a single portal for all complaints, and make public reporting mandatory.” (Page 33 of the Google doc) And "Use the current DNS Abuse definition and take into account the processes and definitions outlined in the Convention on Cybercrime.[38]. Forego new efforts to have ICANN Org or the ICANN community re-define DNS Abuse and instead adopt the additional term and evolving external definition of “security threat”—a term used by the ICANN DAAR project, the GAC (in its Beijing Communique and for Spec 11), and operational security communities – to use in conjunction with ICANN DNS Abuse definition.” (Page 33 of the Google doc) — 4. Is this level of specificity appropriate for the report, or should this be summarized into "ICANN should establish and maintain a single complaint portal for all complaints, that which automatically directs reports to relevant parties, including appropriate Registrars. All reports and their responses should be viewable to the public, and ICANN should include information regarding these reports in their annual report." "The process would work as follows: 1) Complaint submitted, ticket number created, sent to registrar; 2) Registrar responds, ticket closed. Registrar does not, goes to registry; and 3) Registry responds, ticket closed. Registry does not respond, it goes to ICANN. Reports to non-participating ccTLDs to be forwarded via email. — 5. I am unclear about the use of “Contracted Parties” in this recommendation. Does this always refer to the parties that contract directly with ICANN, or does it also refer to any subcontracts formed by the direct contracted parties? "Policies and agreements with Contracted Parties – adopt new ones that meaningfully impact mitigation of DNS abuse and security threats[14] , including changes to WHOIS, incentives for contracted parties for abuse mitigation, incorporate measures to mitigate “DNS abuse” and “security threats” in agreements with contracted parties, estalish a performance metrics framework, and institutionalize training and certifications for contracted parties and key stakeholders.” (Page 35 of the Google doc) — 6. Is there a particular date or date range that should be added here? Also, [16] does not point to anything applicable ([16] was used earlier in the examples for the findings - see "Verisign blog, Q2 2018 DDOS Trends Report: 52 Percent of Attacks Employed Multiple Attack Types”). Should there be a different reference used? Is a reference needed here at all? "ICANN org must enforce norms within XXX[16] .” (Page 35 of the Google doc) — 7. There are several items that look like they should be citation pointers (as in [16] above) that do not point to an appropriate reference. Is there a master list somewhere of what was intended in the Recommendation section, or should these citation tags be removed? — 8. Is this level of specificity appropriate to the report, or should this be left as a business decision detail for ICANN? “..., and provide a Registrar with a discount down to the current $0.18 per domain name for low abuse levels.” (Page 36 of the Google doc) "This should include, as a priority, provisions that establish thresholds of abuse (3% of registration or 30 total whichever is the higher) at which compliance inquiries are automatically triggered, with a higher threshold (10% of all registrations) at which registrars and registries are presumed to be in default of their agreements.” (Page 37 of the Google doc) — 9. The first set of recommendations refers to ICANN making improvements to SSR by updating contracts. In the third set of recommendations, it states that "ICANN’s legal authority to address compliance, security, and/or stability of the DNS, is based on the bylaws and in relation to compliance by Registrars the Service Level Agreements.” Are these items in conflict in any way?

1 0

Questions re: the Abuse/Compliance Findings text
by Heather Flanagan Sept. 27, 2019

Sept. 27, 2019

Hello all, I’m working through the text added by the Abuse/Compliance sub-team, and have a first batch of questions ready. I am happy to put these in the doc itself, but am uncertain who should be assigned to the comments to make sure they are addressed. The current text can be found here, starting on page 16 according to Google docs (the doc itself says page 15) https://docs.google.com/document/d/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXm… <https://docs.google.com/document/d/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXm…> — 1. Is this a section heading, or was this intended to be an endnote? (See page 20 in the google doc) "[1] Gaps: SecurityWorld Threats & ICANN’s failed attempts to mitigate harms? Action” -- 2. Does anyone have any concerns about moving entirety of the examples to an appendix? My working draft (I haven’t put this in the google doc yet) has revised the text on pages 17-25 in the Google doc as follows: The SSR2 team identified a significant upward trend in multiple examples of abusive behaviors that can and often do leverage the DNS. Cybercriminals and other threat actors capitalize on identifiable gaps in DNS security measures currently in place. Relevant trends especially have been observed since the first SSR Review Team report was adopted by the Board in 2012. See Appendix $foo for examples. In our review of ICANN’s activities, we found that the publications and statements from ICANN Org have consistently understated or omitted the impact of systemic abuse of the DNS and its use as a platform for launching systematic attacks on individual and organizational systems worldwide. See Appendix $bar for details in the areas of New gTLD Abuse, Registrar Accreditation Agreements, and gTLD Registry Agreements. -- 3. With regards to: "2. [Additional information & cites to be added] Recommendations from the Government Advisory Committee, e.g., safeguards applicable to all new gTLDs[cite] also call for WHOIS validation, security checks, security threat reporting and complaint handling. [add additional key communique SSR recommendations and Constituency filings]” (page 26 of the Google doc) is The GAC itemized advice (https://gac.icann.org/advice/itemized/ <https://gac.icann.org/advice/itemized/>) the correct place to point a citation, or should there be something(s) more specific? — 4. What additional information is required here? "ICANN also failed to act on additional SSAC recommendations aimed at registries that would help improve DNS security, stability, and resiliency. [add additional]” (page 26 of the Google doc) In terms of citations, this section already points to https://www.icann.org/groups/ssac/documents <https://www.icann.org/groups/ssac/documents> — 5. On the last SSR2 RT call, a suggestion was made to point in some way to the CCT report. Should this section be revised to do that? Would that resolve the comment re: adding additional text? "3. Similar recommendations offered by review teams commissioned by ICANN to assess WHOIS[32] and Competition, Consumer Trust and Consumer Choice[33] have not been adopted by the ICANN Board. As of now, these have not been addressed in registry or registrar agreements with appropriate enforcement mechanisms. ICANN’s Compliance Performance Measurements Reports[34] illustrate the gravity and longevity of the WHOIS inaccuracy problem, but the measurements are otherwise unhelpful. Compliance does not report details of resolution, and there is no transparency in the disposition process that ICANN and contracted parties employ, and responses provided to complainant lack detail. [add additional text re review recommendations]” (page 27 of the Google doc) — 6. This sentence is problematic: "However, ICANN Org has never stated what tools it needs and how its current, narrow interpretation of the RAA and RAs hamper its work.” (Page 29 o the Google doc) Does ICANN admit anywhere that it actually has a current, narrow interpretation of the RAA and RA contracts? I see the they have said they don’t have tools, but the implication that they also say they have a narrow interpretation might be wrong. Is this more how the SSR2 RT sees things?

1 1