- Ssr2-review - lists.icann.org

Re: [Ssr2-review] REMINDER - ACTION REQUEST: Doodle for 24 June plenary call
by MSSI Secretariat June 16, 2020

June 16, 2020

Hi all, If you have not filled out the doodle, please do before the plenary call tomorrow. https://doodle.com/poll/cihbgxi9drbqsnez Thank you, Brenda From: MSSI Secretariat <mssi-secretariat(a)icann.org> Date: Monday, June 15, 2020 at 12:34 PM To: SSR2 RT <ssr2-review(a)icann.org> Subject: ACTION REQUEST: Doodle for 24 June plenary call Dear SSR2 members, Please see doodle poll; https://doodle.com/poll/cihbgxi9drbqsnez and select if you can attend the 24 June SSR2 plenary meeting at 14:00 UTC. 22-25 June is ICANN68<https://68.schedule.icann.org/> which is held during regular working hours in Kuala Lumpur (MYT / UTC+8). We understand some of you may have conflicts. We’re hoping to gauge attendance and will discuss on this Wednesday’s plenary meeting. Thank you! With kind regards, Brenda --- Brenda Brewer, Projects & Operations Assistant Multistakeholder Strategy & Strategic Initiatives (MSSI) Internet Corporation for Assigned Names and Numbers (ICANN) Skype: brenda.brewer.icann

1 0

ACTION REQUEST: Doodle for 24 June plenary call
by MSSI Secretariat June 15, 2020

June 15, 2020

Dear SSR2 members, Please see doodle poll; https://doodle.com/poll/cihbgxi9drbqsnez and select if you can attend the 24 June SSR2 plenary meeting at 14:00 UTC. 22-25 June is ICANN68<https://68.schedule.icann.org/> which is held during regular working hours in Kuala Lumpur (MYT / UTC+8). We understand some of you may have conflicts. We’re hoping to gauge attendance and will discuss on this Wednesday’s plenary meeting. Thank you! With kind regards, Brenda --- Brenda Brewer, Projects & Operations Assistant Multistakeholder Strategy & Strategic Initiatives (MSSI) Internet Corporation for Assigned Names and Numbers (ICANN) Skype: brenda.brewer.icann

1 0

Re: [Ssr2-review] [EXT] Re: SubTeam Privacy
by Barrett, Kerry-Ann June 12, 2020

June 12, 2020

Thanks Heather Sincerely, Kerry-Ann Barrett Cybersecurity Policy Specialist Organization of American States On Jun 11, 2020, at 3:23 PM, Heather Flanagan <hlf(a)sphericalcowconsulting.com> wrote: CAUTION: EXTERNAL SENDER Hello all, The sub team’s comments have been added to the Public Comment Feedback spreadsheet in tab 2 “Organized by section”. https://docs.google.com/spreadsheets/d/1DQpPA0aLDsW5IHLKgQqHtW-5860CKGCuTYI… Heather Flanagan — Translator of Geek to Human https://sphericalcowconsulting.com On Jun 4, 2020, 10:24 PM -0700, Barrett, Kerry-Ann <KABarrett(a)oas.org>, wrote: Dear team, Amendments and comments included in google docs here for review and discussion: https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1M…<https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1M…> Also see proposed response to public comments on action taken in red: BC 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements The BC concurs with this recommendation. Duly Noted SSAC 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements (3.4.9) Why is the topic of “Privacy” in Workstream 4 a Future Challenge? This would conventionally be classified as a current topic. Does the SSR2 RT have evidence that ICANN org is not adequately focusing on Privacy and SSR Measurements already? The recommendation implies that the review has taken the position that the level of focus and attention is inadequate, but has not provided any material in the report that substantiates such a conclusion. Duly noted. The observation was made in the context of while this is a current issue, as data privacy evolves there needs to be a dedicated focus on ensuring ICANN remains abreast of emerging challenges in data privacy including evolving compliance requirements. The growth of data is exponential and increasing security vulnerabilities has led to data breaches. The logic flows from the weaving together of security measures with managing risk factors such as data breaches. In some organizations the role of a Chief Data Officer has worked alongside the Chief Information Security Officer which has been mentioned in the SSR2 Recommendation 6. SSAC 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements (3.4.10) The report notes in the section relating to Rationale and Findings on Privacy, that “ICANN org, in having a privacy policy that covers registration information and having Bylaws that requires it enforce its own policies, is in conflict with their statement that ICANN org is not responsible for data protection and privacy.” This is an unusual 17 interpretation of the ICANN statement, in that the disclaimer is about the general state of privacy on the Internet while the org does have a privacy policy relating to data gathered by the org. Noted and language amended to reflect accuracy in the interpretation of the relevant references. RySG 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements While the RySG supports ICANN tracking new technology and evolving privacy laws and regulations as part of its overall risk management management, the RySG believes that much of this recommendation is out of scope for SSR2. Specifically, we oppose the creation of specialized compliance officers to micromanage contracted party operations. Registries and registrars are responsible for complying with all local laws - ICANN’s compliance team doesn’t need to duplicate the function of local law enforcement. The RySG also notes its support for recommendation 31. SSR2 recognizes the close inter-relationship between security and privacy which is why it was identified as a key component that data privacy not be micro managed but managed in order to ensure compliance is ensured whenever there are related regulations and data breaches minimized in collaboration with ICANN org security team. IPC 29 The IPC is supportive of this recommendation, while noting that the following recommendation is unclear and potentially subject to unintended interpretation in implementation: ‘ICANN org’s DPO should also be responsible for external DNS PII’. Noted and clarification provided as the intent is to ensure that ICANN org is being proactive in identifying and complying with all the laws and regulations that govern data capture, use, retention, security, and disposal SSAC 29.1 ICANN org should monitor and regularly report on the privacy impact of technologies like DoT (DNS over TLS) and DoH (DNS over HTTPS). (3.4.11) In terms of using the SMART criteria for the report’s recommendations it is not clear how this particular recommendation is directly relevant to ICANN. The manner of DNS name resolution between stub and recursive name resolvers on the Internet, and the protocols used to perform such resolution appears to fall outside the scope of ICANN’s activities and authority. Because of this question of direct relevance to ICANN’s scope and mission, this action may be more appropriately included as part of the report’s set of “suggestions,” and listed on the basis of the broader topic of potential actions by ICANN org that would provide value to the community through the provision of assessments of aspects of the larger environment of the domain name space and its evolving use. The SSAC is aware of current activity within both ICANN org and the ICANN community in this space already, including a recently published SSAC study on the implications of DNS over HTTPS and DNS over TLS, and there is some lack of clarity 18 as to how this recommendation differs from current practice. This suggestion is supported as SSAC sees value but noted it misplacement. SSR2 RT has taken this onboard for evaluation. ICANN Board 29.1 ICANN org should monitor and regularly report on the privacy impact of technologies like DoT (DNS over TLS) and DoH (DNS over HTTPS). If the SSR2 RT believes additional monitoring and reporting of areas that are within ICANN org’s remit are needed, the Board would encourage the SSR2 RT to provide clear statements of what issues or risks exist from the current operational model, how the SSR2 RT recommendation will address them, and what relevant metrics could be applied to assess implementation. SSR2 RT notes this and the intent of the recommendation was to ensure that privacy concerns were specifically addressed. RrSG 29.1 ICANN org should monitor and regularly report on the privacy impact of technologies like DoT (DNS over TLS) and DoH (DNS over HTTPS). For recommendation 29.1, this appears to be outside of ICANN's remit. SSR2 RT has noted this comment and has it under evaluation. SSAC 29.2 ICANN org’s consensus policies and agreements with registry operators and registrars should, therefore, have clauses to reflect compliance with these while ensuring that the DNS is not fragmented because of the need to maintain/implement minimum requirements governing the collection, retention, escrow, transfer, and display of registration data, which includes contact information of the registrant, administrative, and technical contacts as well as technical information associated with a domain name. (3.4.12) The introduction of the concept of DNS “fragmentation” makes no clear sense in this context. The recommendation should phrase the concern in a different way that avoids the particular term “fragmentation”, or explain the concept of “fragmentation” in detail. Amended to provide clarity. RrSG 29.2 ICANN org’s consensus policies and agreements with registry operators and registrars should, therefore, have clauses to reflect compliance with these while ensuring that the DNS is not fragmented because of the need to maintain/implement minimum requirements governing the collection, retention, escrow, transfer, and display of registration data, which includes contact information of the registrant, administrative, and technical contacts as well as technical information associated with a domain name. The RrSG needs additional information about recommendation 29.2, as it is not clear what problem or concern this addressing- those obligations already exist. Amended to provide clarity. ICANN Org 29.2 SSR2 Recommendation 29.2: “with these” Requests for clarification of terms Amended to provide clarity. ICANN Board 29.4 ICANN org’s DPO should also be responsible for external DNS PII. The DPO should provide guidance to managers and stakeholders regarding responsibilities and procedures and monitor and report on relevant technical developments. It is unclear to the Board what it means for ICANN to “be responsible for external DNS PII.” SSR2 RT notes this and recommended for deletion. [OAS.org]<http://www.oas.org/> Sincerely Kerry-Ann Barrett Cybersecurity Program Officer Secretariat of the Inter-American Committee against Terrorism (CICTE) Secretariat for Multidimensional Security (SMS) Organization of American States 1889 F Street NW Washington D.C. 20006 [http://www.oas.org/en/sms/signature_images/phone.png] (202) 370 4675 - [http://www.oas.org/en/sms/signature_images/fax.png] (202) 458 3857 www.oas.org/cyber<http://www.oas.org/cyber> @KerryOAS<https://twitter.com/KerryOAS>| @OEA_Cyber<https://twitter.com/OEA_Cyber> Register to our distribution list here!<http://oas.us11.list-manage.com/subscribe?u=353ff0663258ae5a775d460db&id=10…> _______________________________________________ Ssr2-review mailing list Ssr2-review(a)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

SubTeam Privacy
by Barrett, Kerry-Ann June 11, 2020

June 11, 2020

Dear team, Amendments and comments included in google docs here for review and discussion: https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1M…<https://docs.google.com/document/d/1WTnaEk2pW0V85FRXk1uUN4O-co7DcDIXb_9_-1M…> Also see proposed response to public comments on action taken in red: BC 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements The BC concurs with this recommendation. Duly Noted SSAC 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements (3.4.9) Why is the topic of "Privacy" in Workstream 4 a Future Challenge? This would conventionally be classified as a current topic. Does the SSR2 RT have evidence that ICANN org is not adequately focusing on Privacy and SSR Measurements already? The recommendation implies that the review has taken the position that the level of focus and attention is inadequate, but has not provided any material in the report that substantiates such a conclusion. Duly noted. The observation was made in the context of while this is a current issue, as data privacy evolves there needs to be a dedicated focus on ensuring ICANN remains abreast of emerging challenges in data privacy including evolving compliance requirements. The growth of data is exponential and increasing security vulnerabilities has led to data breaches. The logic flows from the weaving together of security measures with managing risk factors such as data breaches. In some organizations the role of a Chief Data Officer has worked alongside the Chief Information Security Officer which has been mentioned in the SSR2 Recommendation 6. SSAC 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements (3.4.10) The report notes in the section relating to Rationale and Findings on Privacy, that "ICANN org, in having a privacy policy that covers registration information and having Bylaws that requires it enforce its own policies, is in conflict with their statement that ICANN org is not responsible for data protection and privacy." This is an unusual 17 interpretation of the ICANN statement, in that the disclaimer is about the general state of privacy on the Internet while the org does have a privacy policy relating to data gathered by the org. Noted and language amended to reflect accuracy in the interpretation of the relevant references. RySG 29 Focus on Privacy and SSR Measurements and Improving Policies Based on Those Measurements While the RySG supports ICANN tracking new technology and evolving privacy laws and regulations as part of its overall risk management management, the RySG believes that much of this recommendation is out of scope for SSR2. Specifically, we oppose the creation of specialized compliance officers to micromanage contracted party operations. Registries and registrars are responsible for complying with all local laws - ICANN's compliance team doesn't need to duplicate the function of local law enforcement. The RySG also notes its support for recommendation 31. SSR2 recognizes the close inter-relationship between security and privacy which is why it was identified as a key component that data privacy not be micro managed but managed in order to ensure compliance is ensured whenever there are related regulations and data breaches minimized in collaboration with ICANN org security team. IPC 29 The IPC is supportive of this recommendation, while noting that the following recommendation is unclear and potentially subject to unintended interpretation in implementation: 'ICANN org's DPO should also be responsible for external DNS PII'. Noted and clarification provided as the intent is to ensure that ICANN org is being proactive in identifying and complying with all the laws and regulations that govern data capture, use, retention, security, and disposal SSAC 29.1 ICANN org should monitor and regularly report on the privacy impact of technologies like DoT (DNS over TLS) and DoH (DNS over HTTPS). (3.4.11) In terms of using the SMART criteria for the report's recommendations it is not clear how this particular recommendation is directly relevant to ICANN. The manner of DNS name resolution between stub and recursive name resolvers on the Internet, and the protocols used to perform such resolution appears to fall outside the scope of ICANN's activities and authority. Because of this question of direct relevance to ICANN's scope and mission, this action may be more appropriately included as part of the report's set of "suggestions," and listed on the basis of the broader topic of potential actions by ICANN org that would provide value to the community through the provision of assessments of aspects of the larger environment of the domain name space and its evolving use. The SSAC is aware of current activity within both ICANN org and the ICANN community in this space already, including a recently published SSAC study on the implications of DNS over HTTPS and DNS over TLS, and there is some lack of clarity 18 as to how this recommendation differs from current practice. This suggestion is supported as SSAC sees value but noted it misplacement. SSR2 RT has taken this onboard for evaluation. ICANN Board 29.1 ICANN org should monitor and regularly report on the privacy impact of technologies like DoT (DNS over TLS) and DoH (DNS over HTTPS). If the SSR2 RT believes additional monitoring and reporting of areas that are within ICANN org's remit are needed, the Board would encourage the SSR2 RT to provide clear statements of what issues or risks exist from the current operational model, how the SSR2 RT recommendation will address them, and what relevant metrics could be applied to assess implementation. SSR2 RT notes this and the intent of the recommendation was to ensure that privacy concerns were specifically addressed. RrSG 29.1 ICANN org should monitor and regularly report on the privacy impact of technologies like DoT (DNS over TLS) and DoH (DNS over HTTPS). For recommendation 29.1, this appears to be outside of ICANN's remit. SSR2 RT has noted this comment and has it under evaluation. SSAC 29.2 ICANN org's consensus policies and agreements with registry operators and registrars should, therefore, have clauses to reflect compliance with these while ensuring that the DNS is not fragmented because of the need to maintain/implement minimum requirements governing the collection, retention, escrow, transfer, and display of registration data, which includes contact information of the registrant, administrative, and technical contacts as well as technical information associated with a domain name. (3.4.12) The introduction of the concept of DNS "fragmentation" makes no clear sense in this context. The recommendation should phrase the concern in a different way that avoids the particular term "fragmentation", or explain the concept of "fragmentation" in detail. Amended to provide clarity. RrSG 29.2 ICANN org's consensus policies and agreements with registry operators and registrars should, therefore, have clauses to reflect compliance with these while ensuring that the DNS is not fragmented because of the need to maintain/implement minimum requirements governing the collection, retention, escrow, transfer, and display of registration data, which includes contact information of the registrant, administrative, and technical contacts as well as technical information associated with a domain name. The RrSG needs additional information about recommendation 29.2, as it is not clear what problem or concern this addressing- those obligations already exist. Amended to provide clarity. ICANN Org 29.2 SSR2 Recommendation 29.2: "with these" Requests for clarification of terms Amended to provide clarity. ICANN Board 29.4 ICANN org's DPO should also be responsible for external DNS PII. The DPO should provide guidance to managers and stakeholders regarding responsibilities and procedures and monitor and report on relevant technical developments. It is unclear to the Board what it means for ICANN to "be responsible for external DNS PII." SSR2 RT notes this and recommended for deletion. [OAS.org]<http://www.oas.org/> Sincerely Kerry-Ann Barrett Cybersecurity Program Officer Secretariat of the Inter-American Committee against Terrorism (CICTE) Secretariat for Multidimensional Security (SMS) Organization of American States 1889 F Street NW Washington D.C. 20006 [http://www.oas.org/en/sms/signature_images/phone.png] (202) 370 4675 - [http://www.oas.org/en/sms/signature_images/fax.png] (202) 458 3857 www.oas.org/cyber<http://www.oas.org/cyber> @KerryOAS<https://twitter.com/KerryOAS>| @OEA_Cyber<https://twitter.com/OEA_Cyber> Register to our distribution list here!<http://oas.us11.list-manage.com/subscribe?u=353ff0663258ae5a775d460db&id=10…>

3 2

Call summary: SSR2 Plenary - 10 June 2020
by MSSI Secretariat June 11, 2020

June 11, 2020

Dear SSR2 RT members, Please find attached the plenary call report for SSR2 meeting #113, 10 June 2020 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/gwQdC. The transcript usually becomes available 5 - 7 business days after the meeting. With kind regards, Brenda --- Brenda Brewer, Projects & Operations Assistant Multistakeholder Strategy & Strategic Initiatives (MSSI) Internet Corporation for Assigned Names and Numbers (ICANN) Skype: brenda.brewer.icann

1 0

Fwd: [EXT] Abuse Subgroup - SSR2
by Barrett, Kerry-Ann June 10, 2020

June 10, 2020

Sincerely, Kerry-Ann Barrett Cybersecurity Policy Specialist Organization of American States Begin forwarded message: From: Denise Michel <denisemichel(a)fb.com> Date: June 9, 2020 at 7:52:09 PM EDT To: "kc(a)caida.org" <kc(a)caida.org>, "Barrett, Kerry-Ann" <KABarrett(a)oas.org>, "laurin.weissinger(a)yale.edu" <laurin.weissinger(a)yale.edu>, "eric(a)osterweil.net" <eric(a)osterweil.net>, "norm(a)webcatcher.ca" <norm(a)webcatcher.ca>, Scott McCormick <scott.m.mccormick(a)gmail.com>, Scott McCormick <scott.mccormick(a)reciprocitylabs.com> Subject: [EXT] Abuse Subgroup - SSR2 CAUTION: EXTERNAL SENDER Hi. Following-up on our sub-group call – we agreed to divide up and fill columns E through H in the subgroup google spreadsheet<https://docs.google.com/spreadsheets/d/1Lunaxnjh_5xcUAn4JvWs4szhrHijOAVrQTW…> that Laurin created, and we’ll discuss next Tuesday, with a goal of reaching a rough consensus on how to handle each comment. Here’s some additional context for each column (Laurin please correct if I misunderstood): E) Preparer Comments – brief, general summary of comment/s for that item F) Actions – briefly note how we intend to respond to comment G) General Actions – broad, high level actions regarding recommendation/sub-recommendation H) Response – brief public response to comment; this column holds our proposed response to each comment for inclusion in final report annex. Assignments (feel free to do more and/or trade recommendations as these are random assignments; if you won’t be able to do one, let me know) 10 - Denise 11 - Laurin 12 – Kerry Ann 13 - KC 14 - Scott 15 - Eric 16 - Norm 17 - Denise Once we’ve processed the comments, we’ll work on red-line edits of the draft report sections for Recs 10 – 17. (For those not on the call) I’ve suggested that we merge some sub-recommendations and reorganize the Recs as follows: * Compliance (recommendations 10, 17, 18) * Contractual changes (recommendations 15, 16) * Abuse management & data (11, 13, 14, 19) (Not sure where Rec 12 -- EPDP on access to WHOIS data -- should go. Comments and suggestions on any of this is most welcome! Best, Denise

1 0

Apologies for today
by Eric Osterweil June 10, 2020

June 10, 2020

Hi all, I am sorry that I won’t be able to join today, but expect to be catching up starting this week. Eric

2 1

SSR2 agenda 10 June 2020
by Jennifer Bryce June 10, 2020

June 10, 2020

Dear SSR2 RT members, Below is the agenda for the next SSR2 plenary call, scheduled for Wednesday 10 June @ 14:00 - 15:00 UTC. 1. Welcome, roll call, SOI updates * Status update on outstanding questions to ICANN org 2. Discuss subteam timeline: 1 July is the deadline for subteams to reach phase 4 (see chart here<https://docs.google.com/spreadsheets/d/1cOZ1lPXqHfuZNt68zvB5xRB63eBoL3gonDb…> for status) 3. Subteam report outs: * Recommendation 27 subteam response to public comments (see here<https://docs.google.com/spreadsheets/d/1DQpPA0aLDsW5IHLKgQqHtW-5860CKGCuTYI…>) * Privacy grouping * Risk grouping * Abuse grouping * Others? 1. AOB 2. 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

2 1

ICANN Organization Blog on DNS Abuse
by danko.jevtovic＠board.icann.org June 10, 2020

June 10, 2020

ICANN Organization Blog on DNS Abuse https://www.icann.org/news/blog/icann-org-s-multifaceted-response-to-dns-ab… Danko

4 7

Risk Section for tomorrow
by Weissinger, Laurin June 9, 2020

June 9, 2020

Dear all, Please see the “new” risk section for our discussions on tomorrow’s call. Please have a read through. Keep in mind this is not final but a basis for further discussion. Section with all our changes accepted (easier read): https://docs.google.com/document/d/1_FBhOUV1vQ_MGVW40Q6wmZEntdj-iVrGRd6J197… Our changes, with markup: https://docs.google.com/document/d/1MJrPzXTngRCrdXLuiyPf7SeZsuPvwjjFGFoooQs… All comments and our actions: https://docs.google.com/spreadsheets/d/1Oj3NB_lU2APbqLi53zIjNR9Cv2YuohrWzx-… All the best Laurin

1 0