Another ICANN conference has come and gone, and, while the timezone was more friendly for us North Americans, it was a bit sad to spend so much time with my ICANN colleagues yet still be so far away from them. ICANN72 saw several interesting sessions: working meetings open to public observation, Stakeholder Group check-ins, and, of course, large plenary sessions where the whole ICANN Community tries to engage on a specific topic.
I’ll share some highlights and insights and, if you want to review full session transcripts, you can always find them on the meeting schedule webpage. There were some overarching themes to ICANN72, so we’re going to approach it that way instead of giving a session-by-session rundown.
Remember: we’re here for you, and our Policy Team is always happy to get more in-depth on any of these topics—just contact your account manager or our Support Team to get in touch and set up a time to talk!
DNS Abuse and how to address it
We were excited to see this issue come to the top of ICANN’s agenda since it’s something we’ve also focused on this year.
Tucows shared our DNS Abuse processes and principles just ahead of ICANN72, and I invite everyone to take a look at our new page, Making the Internet Better. Here we provide context to help a broad audience understand the complex DNS ecosystem and the powers and limitations of the various service providers within it (including a lovely infographic); we also outline what we think needs to happen to clean up the DNS and make the Internet safer.
We believe that mitigating DNS Abuse as it occurs on our platform is not only our obligation as a responsible registrar but is also one of our greatest strengths as a provider. Our abuse response processes have been one of the ways we’ve provided valuable service to our reseller partners. We sincerely hope that what we’ve shared here will inspire other registrars, registries, and Internet providers of all types to join us on this ongoing journey—as many already have.
The Registrar and Registry Stakeholder Groups’ joint DNS Abuse Working Group led a session with the goals of informing the broader ICANN Community about their recent work and engaging in an open dialogue about current concerns and potential future work. The Working Group has several publications to supplement the DNS Abuse Framework that we all know and love, including a new paper on approaches to Business Email Compromise (BEC) scams (link opens a PDF), which I would encourage our reseller partners to read. BEC is a common threat to businesses of all sizes and instances of BEC attacks have risen with the increase in remote work; this paper provides an overview of the problem space and some steps we can all take to help avoid being taken in by Business Email Compromise fraud.
While the definition of DNS Abuse in the DNS Abuse Framework has been used by Registrars and Registries in discussing the issue, in Governmental Advisory Committee (GAC) Discussions, the much broader definition from another Working Group (see Footnote 11 on Page 8 of their Final Report (PDF)) gets used. This definition, “intentionally deceptive, conniving, or unsolicited activities that actually make use of the Domain Name System and/or the procedures used to register domain names,” can include any number of fraudulent activities, including primarily content concerns, which is not within ICANN’s remit. The GAC session also included comments that the current ICANN contracts do not contain clear, enforceable obligations to mitigate threats to the DNS, which we don’t agree with; there is some necessary flexibility in the contractual language but the responsibility to address illegal activity, including DNS Abuse, is present in the Registrar Accreditation Agreement.
The discussion about the role and purview of ICANN Compliance will be something to watch moving forward; in the Q&A with the ICANN Org team, SVP of Compliance Jamie Hedlund confirmed that the Compliance team does enforce obligations related to DNS Abuse—their most recent audit actually focused on the topic—and ICANN’s CEO Göran Marby affirmed that addressing abuse is within ICANN’s scope and mission.
“Prioritization itself has been prioritized” 1
ICANN has been working through an evaluation of different prioritization methods in order to determine how best to prioritize policy development and implementation work; the need to better prioritize work and move more effectively through the existing processes was raised at various meetings between Stakeholder and Constituency groups with the ICANN Board.
Pam Little has been GNSO Councillor for the Registrar Stakeholder Group for the last four years and, at the joint meeting between the ICANN Board and the GNSO Council, one of her final meetings before her term ended, Pam commented on the often drawn-out nature of the policy development process and lack of predictable timing for work moving through that process.
In the four years Pam spent on the GNSO Council, nothing has made it all the way from initiation through to final implementation. What’s going on here? Is the problem that the output from the Policy Development Process is too big, with too many recommendations to be reviewed and implemented in a reasonable period? Or, could it be possible that, when the Policy Recommendations go against what ICANN Org or a given Stakeholder, Constituency, or Advisory group wants, the work to implement those Recommendations is intentionally extended by those groups, since finishing the implementation would finally put into place changes they find undesirable?
There was some pushback from ICANN’s CEO Göran Marby, who said that he disagrees with the claim that nothing has happened (which was not Pam’s assertion) and cited the prioritization work that ICANN Org has underway as an example of meaningful progress. He also highlighted that everyone has limited resources.
The multi-stakeholder model of Internet governance is hard. Consensus is hard. Sometimes it’s simply not possible to reach an outcome everyone likes, especially when it comes to contentious issues. But this doesn’t mean the process has failed. We were pleased to see widespread vocal support of the multi-stakeholder model of Internet governance, even in the wake of dissatisfaction with some policy outcomes. It’s not perfect; the policy development timeframe is perhaps more drawn-out than we might want, but the multi-stakeholder model allows different perspectives to be represented and ensures that final decisions have the support of those most directly bound to follow these policies. We’re not always happy with the policy outcomes, but the system ensures that the process is balanced.
Internet governance vs. governments
Another major topic discussed in various venues at ICANN72 was a question the ICANN Board presented to each Stakeholder Group, Constituency, and Advisory Committee: how can the Board efficiently work with governments around the world to identify issues that affect the ICANN Community and domain name system, as well as educate those governments on issues relating to ICANN’s mission?
There were no strong or conclusive answers, though many groups, including the Registrar and Registry Stakeholder Groups, recommended relying on and empowering the Governmental Advisory Committee (GAC) as the point of connection between ICANN and governments internationally. We also proposed some clarifying questions that could help ICANN better target their efforts: why is this a priority now, do they see problems or gaps in current practices, and what is their desired outcome?
In their responses to the Board’s question, the At-Large Advisory Committee requested more informational materials with fewer buzzwords and acronyms (sadly difficult), while the Commercial Stakeholder Group suggested developing a script that can be used when interacting with local legislators to champion ICANN’s role and mission, working with the GAC to identify pending legislation that may affect the ICANN Community, and encouraging GAC members to bring their Privacy and Data Protection Agency colleagues to the ICANN table. I think that last idea is fantastic and I hope they do!
On top of all that, ICANN has proposed holding 90-minute plenary sessions at ICANN conferences moving forward, which would be dedicated to sharing knowledge and issues relating to legislation worldwide that affects our Community.
Policy development work updates
This wouldn’t be a proper “Sarah Wyld blog post” if I didn’t talk about the EPDP on gTLD Registration Data at least a little bit. While the Phase 1 Implementation Review Team slowly works through the remaining open tasks, the Phase 2 Recommendations are still in the pre-implementation Operational Design Phase (ODP). They’ve sat here for six months and counting as the ODP team works to assess the costs of the proposed Standardized System for Access and Disclosure of non-public domain registration data (SSAD).
This topic came up in an exchange between Steve Crocker (member of the Security and Stability Advisory Committee, or “SSAC”) and ICANN Board members (including CEO Göran Marby) during a meeting between the two groups. The assertion from Steve and the SSAC is that the SSAD (watch those acronyms!) is not fit for purpose because it does not guarantee the disclosure of registration data, though many—Tucows included—do not agree with his view of the SSAD’s purpose. Board member Becky Burr reminded the audience that the relevant registrar or registry must be the party that makes the decision to disclose data (or not), as they are the Data Controller and so have a legal obligation to protect and process the data appropriately.
The SSAC slides (unfortunately not yet available on the meeting page) also included the observation that “SSAC believes it is very important for security investigators to get access to domain name registration data.” This assertion surprised us here at Tucows, as we have received a vanishingly small number of requests for disclosure from security researchers. As we discussed in our most recent Tiered Access stats blog post, which covered the period from September 2020 through to the end of August 2021: “Security researchers, a category of requestors frequently raised and touted as needing urgent access to previously public whois information, are represented in this chart by only one request in period 5. Not 1% of all requests but one single request in this category.” Looking at all disclosure requests we’ve received between May 2018 (when we launched our Tiered Access service) and October 2021, we’ve had a total of 22 requests from security researchers, 25 if you include Certificate Authorities; combined, that’s still only 0.5% of all requests.
I do like to believe that Tucows’ long history of combatting DNS Abuse on our platform has reduced instances of security-related issues on the domains we manage, but I’m not sure that explains the discrepancy here. Is it really the case that security researchers find so few problems on domains registered with us, the second-largest gTLD registrar, that they rarely need to request data from us? Perhaps security researchers do find issues with domains registered here but don’t notify us or request disclosure of registration data because they know we’ll address it on our own, promptly and effectively? Or, could it be that they do not actually require registration data in order to do their work? Unfortunately, we did not have a chance to ask these questions in this session, but I’m hopeful that the opportunity will present itself in the future.
ICANN72 also saw a regular working meeting of the Transfer Policy Development Working Group. The PDP is divided into several phases, which are outlined in the PDP Charter. We’re in Phase 1a right now, working through questions around how transferring a domain between registrars should work. Should the Transfer Authorization Code (TAC) always exist (as it does today), or should it be generated only once the domain owner requests it so they can start their transfer? We’re thinking the second option would be better. Must both the gaining and losing registrars send the Form of Authorization (FOA) email? It’s looking like no—we’ll probably formalize requiring only the losing registrar to send the FOA, which has been the process since the GDPR went into effect in May 2018; it’s working well.
We’ll share information as the PDP progresses, and, when there are decisions made about specific changes that might affect reseller partners (which are still years away), we’ll make sure those are very clearly communicated.
This is all work I’m regularly involved in and thinking about. If it’s of interest to you, please don’t hesitate to contact us so we can set up a time to chat about it (or anything else I’ve covered here) in depth. See you at ICANN73!
1Avri Doria, ICANN Board Member, at the Joint Meeting: ICANN Board and CSG: “prioritization itself, from the ATRT3 recommendations, has been prioritized.” https://72.schedule.icann.org/meetings/kx7AwH9hugHN5KJJv at 01:05:41 in the Zoom recording.