SSR1 Implementation - GDD

 

 

 

Briefing Date: 1 August 2017

Slides: SSR1 GDD Briefing June 2017 v3.0

Meeting Transcript

Adobe Connect Replay

Questions & answers from the briefing

Grouping: ICANN GDD

#

Recommendation

11

ICANN should finalize and implement measures of success for new gTLDs and IDN fast track that expressly relate to its SSR-related program objectives, including measurements for the effectiveness of mechanisms to mitigate domain name abuse.

12

ICANN should work with the Community to identify SSR-related best practices and support the implementation of such practices through contracts, agreements and MOUs and other mechanisms.

 

Follow-Up Questions & Answers

11

Q: What measurements exist, and are used, for the effectiveness of mechanisms to mitigate domain name abuse, as required in recommendation 11?

11

Q: Please provide details of the measures of success relating to new gTLDs and IDNs that expressly address SSR related program objectives. The link in the SSR1 Report did not resolve.

11

Q: Please provide details of how SSR objectives are explicitly referenced in ICANN’s standard operating procedures, Service Level Agreements and monitoring, emergency back- end registry operators and data escrow, Trademark Clearinghouse, root zone scaling management, DNSSEC-related activities, and Compliance Dept. activities

11

Q: Noting IAG-CCT produced 70 metrics of which a single one (1.13) related to security issues; please provide details of the information gathered according to that metric. The web page of metrics and measures does not include information relating to 1.13.

11

Q: The SSR1 Report refers to Specification 11 as applying to all new gTLD registries. Please provide reports on the number and type of security threats reported by registries under their Specification 11 obligations. Please give details of enforcement action(s) taken by ICANN’s contractual compliance department in relation to Specification 11.

11

Q: How many new gTLD applications were failed (or placed in contention or required to take additional steps) on the basis of the (i) the security and stability review or (ii) the string similarity review.

11

Q: In relation to the IDN ccTLD Fast Track, please give details of any strings that have failed those security and stability checks for security and stability related reasons rather than for consumer confusion – a CCT Review issue.

11

Q: Considering staff and community feedback, how effective is the EPSRP mechanism (the second security and stability review in the IDN ccTLD Fast Track) in detecting and preventing stability and security issues other than consumer confusion?

11

Q: Are there any updates on the status of Coordinated Vulnerability Disclosure Reporting since 2013?

11

Q: Please provide a copy of the report referred to in bullet point 9 of recommendation 11 implementation in the Final Implementation Report. Given that the SSR objectives referred to in the report remain ‘to be defined’ please provide an explanation as to why this recommendation is said to be complete.

11

Q: To what extent was the commissioning of the CDAR report, the Root Stability Study Workshop and the new gTLD program security and stability impact triggered by the SSR1 recommendation, and why is the SSR1 Report not referenced in the published materials relating to those initiatives?

11

Q: What was happening in the 5 years between when the recommendation was approved by the Board and when a draft consultant report was posted in April 2017?

11

Q: On the status and deliverables of Rec 11 it says that ICANN has implemented measures of success for the gTLDs, but we haven’t seen how you’ve implemented measures of success for new gTLDs and IDNs. That’s the first check mark, but what we’ve been provided with is a draft report of some ideas that you could do. How is that considered full implementation of this recommendation?

11

Q: The SSR1 review team called out a number of activities that were operational and within staff’s purview and contained in the SSR framework and called for implementation of measurements and metrics.   Was that work done and is it captured anywhere? To clarify, as part of the SSR1 report related to rec 11, the SSR1 review team noted ICANN administration of the new gTLD Program, IDN program, significant SSR related issues that are in the framework. They called for more specific goals, measurements and impact assessment. Was that work done and is it captured somewhere else?

11

Q: Is there more information on the steps that ICANN has taken in the past five years to facilitate data access and activities that involved other entities that had ownership or responsibilities on related activities?

11

Q: Broadly, in looking at the dashboard for rec 11 and all the checkmarks including operational items, it’s really unclear how staff defined and measured success related to SSR. It’s hard to see how the basic spirit of this recommendation was implementation, especially with an idea paper from a consultant. But in terms of the last 5 years and what staff did to implement, it’s unclear. Can you gather more information and provide more clarity and facts?

11

Q: In a commercialized world of DNS service provision where data is considered to be a corporate asset, do you feel that either ICANN or the community at large have access to meaningful metrics? I cite the barriers that exist on information on root servers. Is this a barrier to the entire objective, that access to data appears to be challenging?

 

A: Geoff Huston (asker) clarified that he feels this is a question for the review team to answer, not ICANN org.

11

Q: Do you think it is ICANN staff’s responsibility to gather, analyze and publish this data or do you feel that it’s ICANN’s responsibility to facilitate others to do that?

 

A: Question answered during the call. See meeting record .

12

Q: In what way have the recommendations contained in the paper, “Identifier System Attack Mitigation Methodology,” been integrated into contracts, agreements and MoUs as envisioned by SSR1 recommendation 12?

12

Q: Is there a central, up-to-date resource to see how the ISSSR team, and other professionals in the SSR field, have worked with SOs and ACs to identify additional, targeted best-practices for their constituents? Are there pointers to or records of those engagements?

12

Q: What are some examples of significant MoUs with international entities that have SSR-practices embedded within them?

12

Q: Is the only place where ICANN has documented work on recommendations for web application protection and development of resources for security awareness in the report from the 4th Global DNS Stability, Security and Resiliency Symposium?

12

Q: Has there been a Global DNS Stability, Security and Resiliency Symposium since 2014?

12

Q: With regards to establishing best practices and integrating these into agreements to which ICANN enters: It’s linked to a paper that raises a whole host of issues and addresses proposed activities but it’s unclear how that then relates to integrating those into agreements into which ICANN has entered over the past 5 years. Can you provide more specific information on how best practices are reflected in agreements that ICANN has entered into?

12

Q: ‘Addressing SSR practices in MOUs’ links to a page that holds all of the MOUs. Can you provide some quantification of SSR-related practices in MOUs and more information on which ones contain SSR-related practices, which practices they contain, and how all that’s tracked or the implementation is assessed?

12

Q: Which sections of the revised new gTLD registry agreement does OCTO staff feel advance SSR best practices and objectives?

12

Q: Is there any quantification or more detailed information on what the working relationship with the APWG has yielded?

 

A: Question answered via email .

1) cross-community collaboration on APWG white papers, see   https://apwg.org/resources/apwg-reports/whitepapers, including these topics:
- registrar best/recommended practices
- web vulnerabilities survey
- subdomain registration phishing practices
- whois data and phishing
- twice annual global phishing surveys

2) cross-posting of SSAC documents for APWG community, again see   https://apwg.org/resources/apwg-reports/whitepapers

3) cross-fertilization of subject matter expertise
- incoming SSAC chairperson is originally from APWG community
- several SSAC members are originally from APWG community
- registry (e.g., Afilias, Org) and registrar (Blackknight, GoDaddy) staff have joined APWG

4) Our membership provides access to APWG eCrimeX phishing data for the DAAR project

5) Collaboration on an Accelerated Malicious Domain Suspension program (AMDoS) see   https://apwg.org/apwg-news-center/amdos/ for registries and registrars.

12

Q: What has changed after the implementation of Rec#12 as compared with the past?

 

A: Question answered during the call. See meeting record .