October 2019 - Ssr2-review - lists.icann.org

SSR2 RT Engagement Session | ICANN66 Montreal | 3 November 2019
by MSSI Secretariat Oct. 25, 2019

Oct. 25, 2019

Engagement Session with SSR2 Review Team at ICANN66 | Montreal<https://community.icann.org/x/IZQCBw> Zoom Link: https://icann.zoom.us/my/yul66.517c Date: Sunday, 3 November 2019 Time: 17:00 - 18:30 local Montreal time - additional time zone support here<https://www.timeanddate.com/worldclock/fixedtime.html?msg=SSR2+Engagement+S…> Location: Room 517C ICANN|66 Montreal schedule page HERE<https://66.schedule.icann.org/meetings/1116775>

1 0

SSR2 Face to Face Day 1 | 1 November 2019
by MSSI Secretariat Oct. 25, 2019

Oct. 25, 2019

SSR2 Face to Face Meeting - Day 1 at ICANN66 | Montreal<https://community.icann.org/x/qJMCBw> 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…> Zoom Link: https://icann.zoom.us/my/yul66.512e Room: 512E

1 0

SSR2 Face to Face Day 2 | 2 November 2019
by MSSI Secretariat Oct. 25, 2019

Oct. 25, 2019

SSR2 Face to Face Meeting - Day 2 at ICANN66 | Montreal<https://community.icann.org/x/qJMCBw> 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…> Zoom Link: https://icann.zoom.us/my/yul66.512g Room: 512G ICANN66 | Montréal schedule link: HERE<https://66.schedule.icann.org/meetings/1116929>

1 0

Call summary: SSR2 23 October
by Jennifer Bryce Oct. 24, 2019

Oct. 24, 2019

Dear SSR2 RT members, Please find attached the plenary call report for SSR2 meeting #88, 23 October 2019 at 14:00 UTC. These high-level notes are designed to help SSR2 Review Team members navigate through the content of the call. They are not meant to be a substitute for the recording or transcript, which are posted on the wiki here: https://community.icann.org/x/rpMCBw. The transcript usually becomes available 5 - 7 business days after the meeting. 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

FYI - DNS Abuse definitions
by Denise Michel Oct. 23, 2019

Oct. 23, 2019

As discussed, here’s background on the definitions of “DNS abuse” that have been used in ICANN over the years. As you know, the Board didn’t approve most of the CCT Review’s recommendations and one of their cited reasons (surprisingly) was that DNS abuse first needed to be defined. Staff and some ICANN groups have subsequently pursued this issue. I think SSR2’s proposed approach strikes the appropriate balance and is a useful contribution to this discussion -- essentially that: ICANN is responsible for enforcing its contracts and following through on its plans and obligations based on the existing definitions of DNS abuse that have been well-vetted and used by ICANN for many years, while simultaneously evolving the definition of DNS abuse in conjunction with outside experts to keep pace with user harm tied to the internet’s unique identifiers. Best, Denise Denise Michel denisemichel(a)fb.com<mailto:denisemichel@fb.com> 1 Community developed definitions of key terms (eg DNS Security; DNS Abuse) 1.1 CCT Report – 2018 (CCT Review<https://www.icann.org/en/system/files/files/cct-final-08sep18-en.pdf>) The CCT is a community review, so the definitions adopted in the report are community-developed or approved, and the review has been subject to public comment. DNS Abuse is defined by the CCT (at footnote 11, p8) as follows. The footnote makes clear that the definition was developed through the ICANN Community: “DNS Abuse” is a term used by the Review Team that refers to “intentionally deceptive, conniving, or unsolicited activities that actively make use of the DNS and/or the procedures used to register domain names” (see p. 3 of the “New gTLD Program Safeguards Against DNS Abuse: Revised Report” referenced below). “DNS Security Abuse” in the context of this report refers to specific, technical forms of abusive behavior: malware distribution, phishing, pharming, botnet command-and-control, and spam in the DNS. For more on how abuse has been characterized by the ICANN Community, see the Registration Abuse Policies Working Group’s Final Report (29 May 2010), At the glossary, DNS Abuse and DNS Security Abuse are defined as: DNS Abuse Intentionally deceptive, conniving or unsolicited activities that actively exploit the DNS and/or the procedures used to register domain names. DNS Security Abuse DNS abuse related to cybersecurity, such as malware distribution, phishing, pharming, botnet command-and- control, and high volume spam. Note that ‘DNS Security Abuse’ includes ‘high volume spam’. 1.2 New gTLD Program Safeguards Against DNS Abuse: Revised Report - 2016 (New gTLD Safeguards Report<https://newgtlds.icann.org/en/reviews/dns-abuse/safeguards-against-dns-abus…>) The report was commissioned by the CCT as part of their work. It was written by ICANN staff in consultation with ‘expert constituencies’, and was subject to public comment[1]. The revised report was published in 2016. The definition of DNS Abuse adopted by the CCT was coined in the New gTLD Program Safeguards report. 1.3 Registration Abuse Policies Working Group – 2010 (RAP WG<https://gnso.icann.org/sites/default/files/filefield_12530/rap-wg-final-rep…>) The ICANN Registration Abuse Policies Working Group Final Report is 126 pages long, and provides detailed examination of the various ways in which domain names can be and are abused. Recommendation #1 under ‘Malicious use of domain names’ the team unanimously recommends the creation of non-binding best practices to help contracted parties address the illicit use of domain names (see p12, and pp 50-70). The subject areas include policies for identifying and investigating malicious use such as malware and phishing). It contains the following definitions, which were adopted by unanimous consensus of the community represented through the working group (see page 19) Abuse is an action that: * Causes actual and substantial harm, or is a material predicate of such harm, and * Is illegal or illegitimate, or is otherwise considered contrary to the intention and design of a stated legitimate purpose, if such purpose is disclosed. Section 5 of the report lists out numerous registration abuses. Section 6 of the RAPWG report considers ‘Malicious use of domain names’, particularly ‘e-crime’. As a general point, in relation to fast-flux, ‘but also spamming, malware distribution, online child pornography, phishing, botnet command-and-control, 419 scams and others’, the malicious or illicit behaviour ‘may be mitigated by stopping the domain name from resolving…. in the ICANN context, stopping the resolution of the domain is the relevant issue, since that is what registrars and registries have the technical ability to make happen.’ 1.4 Draft working definitions – GNSO drafting team – 2009 (reference<https://gnso.icann.org/sites/default/files/filefield_5950/whois-working-def…>) The RAPWG report references a document entitled ‘Draft Working Definitions prepared by the GNSO Drafting Team for further use by the GNSO Council as of 18 February 2009’ This document’s definition of misuse is cited with approval by the RAPWG 2) Misuse See study #s 1, 14, GAC 3 for examples of use in context. Misuse is an action that causes actual harm, is the predicate to such harm, is illegal or illegitimate, or is otherwise considered contrary to intention and design of a stated legitimate purpose, if such purpose is disclosed. When applied to Whois data, such harmful actions may include the generation of spam, the abuse of personal data, intellectual property theft, loss of reputation or identity theft, loss of data, phishing and other cybercrime related exploits, harassment, stalking, or other activity with negative personal or economic consequences. The predicate to harmful action often includes automated email harvesting, domain name registration by proxy/privacy services to aid wrongful activity, and support of false or misleading registrant data. Predicate acts might include the use of Whois data to develop large email lists for commercial purposes. ________________________________ [1] https://www.icann.org/en/system/files/files/report-comments-new-gtld-safegu…

1 0

FW: Re: DNS Blocking
by Barrett, Kerry-Ann Oct. 23, 2019

Oct. 23, 2019

A contribution to this discussion, I think is of interest, can be found in a recent document published by some registries and registrars (like Amazon, GoDaddy, Tucows), concerning their role (and ICANN's) in DNS blocking. They hope it "will facilitate a productive conversation that moves the multistakeholder community forward towards a shared understanding of DNS Abuse and Website Content Abuse and the roles registrars and registries serve in addressing them." http://www.circleid.com/pdf/Framework_to_Address_Abuse_20191017.pdf

1 0

DNS abuse discussion
by Danko Jevtovic Oct. 22, 2019

Oct. 22, 2019

Another interesting link: https://www.securityskeptic.com/2019/10/report-criminal-abuse-of-domain-nam… http://www.interisle.net/sub/CriminalDomainAbuse.pdf Best, Danko Jevtović ICANN Board of Directors member <mailto:danko.jevtovic@board.icann.org> danko.jevtovic(a)board.icann.org <https://www.icann.org/resources/pages/board-of-directors> www.icann.org <http://fb.com/dankoj> fb.com/dankoj <https://www.linkedin.com/in/dankoj> linkedin.com/in/dankoj <http://twitter.com/dankoj> twitter.com/dankoj Skype: <callto:dankoj> callto:dankoj mobile: +381-65-3496666

2 1

SSR2 agenda 23 October 2019
by Jennifer Bryce Oct. 22, 2019

Oct. 22, 2019

Dear SSR2 RT members, Below is the agenda for the next SSR2 plenary call, scheduled for Wednesday 23 October at 14:00 UTC. 1. Welcome, roll call, SOI updates 2. Confirm that everyone is comfortable with the existing set of recommendations (see Google doc<https://docs.google.com/document/d/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXm…>) 3. AOB 4. Confirm action items, decisions reached 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

Blacknight, GoDaddy, PIR, Donuts & Amazon Take Stand on Domain Abuse
by Danko Jevtovic Oct. 19, 2019

Oct. 19, 2019

Interesting post and an initiative: Blacknight, GoDaddy, PIR, Donuts & Amazon Take Stand on Domain Abuse https://blacknight.blog/blacknight-godaddy-pir-donuts-amazon-take-stand-on-… https://thenew.org/pir-fighting-abuse-join-us/ https://blacknight.blog/wp-content/uploads/2019/10/Framework-to-Address-Abu… Danko

2 1

discussion on call today per dropping part of recommendation 24 on alternate roots
by k claffy Oct. 17, 2019

Oct. 17, 2019

i propose to delete the text about recommending that ICANN measure alternate roots, for the following reason: -- i think we need to prioritize the tremendous amount of measurement we are recommending icann do of the current ICANN-coordinated ecosystem. -- if i received this recommendation, it is not clear to me what i would measure and how, and how i would know whether the results of the measurement are achieving the intended effect. the last part applies to SSR3. -- alternate roots do and will exist and there is nothing icann can or should do about them except make sure that "icann is not following its own bylaws and its own principles of accountability and transparency" is not a legitimate reason for such roots to grow and proliferate. our recommendations should focus on these principles in an SSR context. proposed deletion in between @@@@ below, from https://docs.google.com/document/d/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXm… k Recommendation 24: (Root Zone Data) -- Rec 24, 25, 30, 31, 32, 33, 34 For each root-zone related service and any gTLD service that ICANN has purview over, including the serving of data sets, e.g., CZDS, ICANN should create or bring into existence a list of statistics and metrics that reflect the health operational status (such as availability and responsiveness) of that service, and publish a directory of these services, data sets, and metrics on a single page on the icann.org web site, such as under the Open Data Initiative ODI initiative. This would address strategic objectives 1 and 2, and strategic goal 2.1, increasing transparency and simplifying PDPs. ICANN should create a single document describing these services, data sets, and metrics, and integrate community feedback via public mechanisms to improve these services, data sets and metrics on a continual basis. The frequency of publication should be decided be (by default) annual, but may be altered by community consensus. These metrics shall include: -- Root Zone Measures (Key Performance Indicators, KPIs): ICANN should create or commission the development of formal KPIs for the DNS Root zone (including DNSSEC, availability, integrity, abuse, etc.), so that its SSR aspects can me concisely and systematically measured and tracked. KPIs should be produced as summaries over both the previous year and longitudinally (to illustrate any baseline behaviors). Community feedback should be requested regularly, considered, and collated after each report. Where appropriate, feedback should be incorporated into follow-on reports. The data used to measure the results in these reports should be archived and made publicly available, along with any and all methodologies (to foster reproducibility). At the moment, no such reporting exists, denying stakeholders the possibility to assess key SSR indicators over time. This will address strategic objectives 1, 2, 3, 4, and 5, as well as strategic goals 1.1, 1.2, 2.1, 3.2, 3.4 and 4.1, @@@@ BEGIN DELETE -- Root zone KPIs, KPIs for known alternate root zones, deltas of data about delegated Top-Level Domains (TLDs) in each of these roots. As justification of this: as the set of delegated TLDs continues to be critical for online services, and there exists the potential for new generic TLDs (gTLDs) to be added in the future, periodic measurements and longitudinal analyses are critical necessities for understanding the SSR of the global DNS. This addresses strategic objectives 1, 2, 3, 4, and 5, as well as strategic goals 1.1, 1.2, 2.1, 3.2, 3.4 and 4.1. @@@@ END DELETE -- To address strategic objectives 1, 2, 3, 4, and 5, as well as strategic goals 1.1, 1.2, 2.1, 3.2, 3.4 and 4.1, ICANN should create (or commission the creation of) a framework for assessing and measures that codify the propagation delay of root zone changes to instances. - The IANA registries include many needed parameters that are specified by RFCs in the IETF. Their availability and integrity are paramount and needs to be clearly illustrated to the community. At the moment, no such reporting exists, denying stakeholders the possibility to assess key SSR indicators over time. ICANN should create a set of measures that demonstrate the size, growth, and composition of the IANA registries, and also the global network availability of these registries. These shall be measured, and archived (per above). The data in these (and any other measurements) should be archived and made publicly available, along with any and all methodologies (to foster reproducibility). At the moment, no such reporting exists, denying stakeholders the possibility to assess key SSR indicators over time.

3 2