14,932
edits
Changes
no edit summary
==Themes==
==Themes==
===Interacting with Governments===
===Interacting with Governments===
* ICANN [[Executive Team]] Response ([[Mandy Carver]]): [[Engagement#GE|ICANN's Government Engagement]] is growing to meet the need to learn about and give input on DNS-related legislation around the world; this is not the purview of the [[GAC]].
* ICANN [[Executive Team]] Response ([[Mandy Carver]]): [[Engagement#GE|ICANN's Government Engagement]] is growing to meet the need to learn about and give input on DNS-related legislation around the world, as this is not the purview of the [[GAC]].
* In the joint ICANN Board-GAC session, the GAC recommended that:
* In the joint ICANN Board-GAC session, the GAC recommended that:
# the board engage in ''less'' formal and ''more'' substantive interactions with the GAC to get more done toward working with governments on geopolitical Internet issues;
# the board engage in ''less'' formal and ''more'' substantive interactions with the GAC to get more done toward working with governments on geopolitical Internet issues;
# how to coordinate messaging to governments and IGOS: ICANN's tripartite arrangement (ICANN Board, Org, and Community) is important but for the purpose of advocacy, it might not be the best model. We should be one in messaging, and unified talking points should be circulated.
# how to coordinate messaging to governments and IGOS: ICANN's tripartite arrangement (ICANN Board, Org, and Community) is important but for the purpose of advocacy, it might not be the best model. We should be one in messaging, and unified talking points should be circulated.
# tracking legislation: ICANN should better engage internally and make a hub to access information from all of the ICANN volunteers; figure out who our friends are on [[cybersecurity]], [https://www.europarl.europa.eu/thinktank/en/document.html?reference=EPRS_BRI(2021)689333NIS2 NIS2], and [[Whois]] issues (to help us interpret them); make better use of [[GAC]] member for early warning signs of potential legislation-related issues; stop thinking of GAC as a monolith;
# tracking legislation: ICANN should better engage internally and make a hub to access information from all of the ICANN volunteers; figure out who our friends are on [[cybersecurity]], [https://www.europarl.europa.eu/thinktank/en/document.html?reference=EPRS_BRI(2021)689333NIS2 NIS2], and [[Whois]] issues (to help us interpret them); make better use of [[GAC]] member for early warning signs of potential legislation-related issues; stop thinking of GAC as a monolith;
# GAC members should bring along their cybersecurity, [[Data Privacy]], and Intellectual property office representatives to gain their perspectives earlier, as they offer a clear picture of the balance between commercial and public interests in their nations
# GAC members should bring along their cybersecurity, [[Data Privacy]], and Intellectual property office representatives to gain their perspectives earlier, as they offer a clear picture of the balance between commercial and public interests in their nations; and
# pay more attention to [[ccTLD]] operators to see how they're managing legislation responses
# pay more attention to [[ccTLD]] operators to see how they're managing legislation responses.
===DNS Abuse===
===DNS Abuse===
*# [[Compromised Domain|Hacked websites]] are now overtaking [[Malicious Domain|maliciously registered domains]] in terms of DNS abuse, which limits access to investigative tools and necessary evidence to catch the perpetrators. Regulation flowing down the hierarchy cannot reach this type of activity because the hackers do not provide accurate email addresses, money trails, or registration data. At best, investigators may find something in the payload. In turn, phishing attacks can go unnoticed and unpunished.
*# [[Compromised Domain|Hacked websites]] are now overtaking [[Malicious Domain|maliciously registered domains]] in terms of DNS abuse, which limits access to investigative tools and necessary evidence to catch the perpetrators. Regulation flowing down the hierarchy cannot reach this type of activity because the hackers do not provide accurate email addresses, money trails, or registration data. At best, investigators may find something in the payload. In turn, phishing attacks can go unnoticed and unpunished.
** [[Samaneh Tajalizadehkhoob]] said ICANN's [[OCTO]] is wondering how to choose which [[RBL]] to use because the office is developing a methodology for selecting RBLs, and Theo responded: look at the metrics (where they get their data from, check for alignment with what you are looking for, a large number of hits).
** [[Samaneh Tajalizadehkhoob]] said ICANN's [[OCTO]] is wondering how to choose which [[RBL]] to use because the office is developing a methodology for selecting RBLs, and Theo responded: look at the metrics (where they get their data from, check for alignment with what you are looking for, a large number of hits).
** [[Stephanie Perrin]] explained that much of the activity is not DNS abuse and perhaps not even criminal; so, how do we regulate this realm? ''Theo explained that he only looks at RBLs that focus on DNS Abuse (and [[CSAM]], which is automatically taken down)''. Also, how do we regulate state-sponsored mischief?
** [[Stephanie Perrin]] explained that much of the activity is not DNS abuse and perhaps not even criminal; so, how do we regulate this realm? Theo explained that he only looks at RBLs that focus on DNS Abuse (and [[CSAM]], which is automatically taken down). Perrin also asked: how do we regulate state-sponsored mischief?
* In the [[CSG]]-[[ICANN Board]] joint meeting, [[Avri Doria]] explained that the [[CCT]] and [[Second Security, Stability, and Resiliency Review]] (SSR2) generated a significant number of recommendations that address [[DNS Abuse]] and [[DNS Abuse Responses|threat mitigation]] and should be considered together in a comprehensive way to fully understand how [[ICANN]] can approach their implementation.
* In the [[CSG]]-[[ICANN Board]] joint meeting, [[Avri Doria]] explained that the [[CCT]] and [[Second Security, Stability, and Resiliency Review]] (SSR2) generated a significant number of recommendations that address [[DNS Abuse]] and [[DNS Abuse Responses|threat mitigation]] and should be considered together in a comprehensive way to fully understand how [[ICANN]] can approach their implementation.
* [[Trusted Notifier|Trusted Notifier Framework]]
* In the "CPH DNS Abuse Work Group Community Update", [[Keith Drazek]] presented on the [[RySG|Registries]] and [[RrSG|Registrars]] Stakeholder Groups' [[Trusted Notifier Framework]], which is a guide for parties entering [[Trusted Notifier]] arrangements.<ref>[https://rrsg.org/wp-content/uploads/2021/10/Final-CPH-Notifier-Framework-6-October-2021.pdf Trusted Notifier Framework, CPH, RRSG.org]</ref> The framework explains the role, responsibilities, and expectations of Trusted Notifiers.
* [[Interisle]] gave a presentation to the [[BC]] on its [https://www.interisle.net/PhishingLandscape2021.html ''Phishing Landscape 2021''].
* [[Interisle]] gave a presentation to the [[BC]] on its [https://www.interisle.net/PhishingLandscape2021.html ''Phishing Landscape 2021''].
* [[Goran Marby]] pointed to [[DNS Security Facilitation - Technical Study Group]] recommendations as an indication of the 12 steps ICANN could take in [[DNS Abuse Responses|response]] to [[Cybersecurity]] if not directly [[DNS Abuse]]
* [[Goran Marby]] pointed to [[DNS Security Facilitation - Technical Study Group]] recommendations as an indication of the 12 steps ICANN could take in [[DNS Abuse Responses|response]] to [[Cybersecurity]] if not directly [[DNS Abuse]]
# A domain name is more at risk of being [[Domain Name Hijacking|hijacked]] if the authInfo code is not managed based on best practice security principles.
# A domain name is more at risk of being [[Domain Name Hijacking|hijacked]] if the authInfo code is not managed based on best practice security principles.
====RPM Phase 2====
====RPM Phase 2====
* The [[IPC]] held a discussion on scoping concerns for the [[UDRP]] Review (by [[Susan Payne]]), from [[John McElwaine]]'s email PowerPoint framework to [[GDD]], including reducing the negativity toward the UDRP to reflect the reality of the majority report; making it data-driven (from [[WIPO]], providers, trends for analysis, [[INTA]]); and not starting from scratch. The [[BC]] supports the IPC's concerns.
* The [[IPC]] held a discussion on scoping concerns for the [[UDRP]] Review (by [[Susan Payne]]), based on a list of suggestions sent by [[John McElwaine]] to [[GDD]], including reducing the negativity toward the UDRP to reflect the reality of the majority report (that it has been a relative success); making it data-driven (from [[WIPO]], providers, trends for analysis, [[INTA]]); and not starting from scratch. The [[BC]] supports the IPC's concerns.
**Use [[Consensus Playbook]]
**Use [[Consensus Playbook]]
**RPM Phase 1 was a disaster, spent too much time on chartering; must do it differently this time ([[Lori Schulman]]), use [[WIPO]] reports as precedent, use data that is already available
**RPM Phase 1 was a disaster, spent too much time on chartering; must do it differently this time ([[Lori Schulman]]), use [[WIPO]] reports as precedent, use data that is already available