Current Developments in DNS Privacy | IGF 2023

David Huberman

The summary emphasises the importance of DNS privacy, as DNS queries can reveal personal information about individuals. The clear text nature of DNS data until a few years ago made it accessible to anyone. This highlights the urgent need for developing protocols that ensure DNS privacy. The DNS was created in 1983, but privacy-focused developments only began in the last five to six years.

Paul Makapetris, the inventor of DNS, is credited for solving significant issues regarding the scaling and knowledge of all hosts on the internet. Prior to DNS, existing processes were unable to scale effectively. The creation of a distributed system through DNS enabled anyone to access information about hosts and their corresponding IP addresses, greatly enhancing the functionality and efficiency of the internet.

Jeff Houston, the chief scientist of APNIC, is regarded as a highly respected authority in the field of internet engineering. His deep understanding of the internet and its engineering aspects is acknowledged by David Huberman. As a thought leader, Jeff Houston is considered one of the best sources for discussing technical considerations related to DNS privacy.

In conclusion, DNS privacy is crucial due to the potential exposure of personal information through DNS queries. The delay in developing protocols for DNS privacy is seen as a missed opportunity, considering the long history of DNS and the recent start of privacy-focused developments. The invention of DNS by Paul Makapetris is credited for resolving critical issues associated with scaling and knowledge of internet hosts. Overall, Jeff Houston’s expertise in internet engineering is seen as valuable for discussions on the technical considerations of DNS privacy.

Geoff Huston

DNS privacy is an incredibly important issue, as DNS queries can track online activities, and if someone sees your DNS queries in real time, they essentially have access to all your secrets. Manipulations of DNS queries are also possible, as applications believe the first answer they receive. However, the DNS industry has made positive strides towards improving DNS privacy and security. Efforts such as query name minimisation and implementing encryption protocols like HTTPS and QUIC are being employed to protect DNS transactions. Despite these advancements, there is a challenge in balancing the need for an efficient network with the need for privacy in the DNS. Additionally, the technical community is working towards an opaque system that removes attributions in name use, but this may lead to a loss of transparency. The role of ICANN in DNS privacy is uncertain, and applications have gained control over the DNS, leaving traditional infrastructure operators behind. This shift towards application-driven technologies presents challenges for infrastructure operators. Overall, DNS privacy is a critical concern, and while improvements are being made, there are still challenges to address.

Manal Ismail

The European General Data Protection Regulation (GDPR) has had a significant impact on the GTLD Whois landscape. It mandates the reduction of personally identifiable information in registration data, radically changing the landscape. However, implementation of GDPR varies depending on the registry or registrar involved, resulting in a fragmented system. This has introduced several key issues, including increased ambiguity regarding the differentiation between legal and natural persons.

To address these challenges, there is a pressing need for standardized regulations and mechanisms for accessing non-public registration data and responding to urgent requests. However, reaching an agreement on the necessary policy recommendations has proven difficult. For example, the Governmental Advisory Committee (GAC) has found the proposed three-business-day timeline for responding to urgent requests unreasonable.

Another challenge arises from the lack of policy applicable to domain registrations subject to privacy proxy services. The use of privacy proxy protection has increased over time, and governments within the GAC are unsure of how to address this issue. The absence of clear policies in this regard makes it difficult to ensure compliance and protect privacy rights.

Improving the accuracy of GTLD registration data is a prioritized area of work. The GAC principles place great importance on the accuracy of this data, and ICANN is preparing a comprehensive assessment of the activities it may undertake to study accuracy obligations in light of applicable data protection laws and contractual authority.

During discussions, Manal Ismail expressed agreement with Steve and Farzi regarding the significance of data collected during the proof of concept. This demonstrates the recognition of the value of such data in informing decision-making and shaping policies.

Moreover, Manal Ismail believes in the necessity of constructive and inclusive discussions within ICANN’s bottom-up multi-stakeholder model. Despite diverse views, all participants were observed speaking from a public interest perspective. This highlights the importance of finding a balance between privacy and safety while considering the broader societal impact of ICANN’s decisions.

In conclusion, the GDPR has brought about significant changes in GTLD Whois records, necessitating the need for standardized regulations and mechanisms for accessing registration data and addressing urgent requests. The lack of policies applicable to domain registrations with privacy proxy services poses additional challenges. Efforts are being made to improve the accuracy of registration data. It is crucial to recognize the value of collected data during the proof of concept and engage in constructive and inclusive discussions to strike a balance between privacy and safety within ICANN’s bottom-up multi-stakeholder model.

Audience

During the ICANN62 Policy Forum, discussions on data privacy and access covered several crucial points. One speaker highlighted the potential harm caused by publicly accessible personal data of domain name registrants. For 20 years, this sensitive information, including mailing addresses, phone numbers, and email addresses, was available to the public. This raised concerns regarding the potential risks and harm that could arise from such unrestricted access to personal data.

On the positive side, another speaker mentioned the improvement brought by the advent of privacy proxies. This development allowed for increased privacy protection by masking personal information in domain registrations. This was seen as a step in the right direction towards improving domain privacy.

The forum also acknowledged and appreciated ICANN’s focus on DNS privacy. In one of the workshops, ICANN specifically titled it as DNS privacy and emphasized the importance of privacy in addition to access. This recognition highlighted the commitment to address privacy concerns and protect the data of internet users.

Transparency and accountability regarding law enforcement’s access to people’s data were deemed important. It was stressed that governments and law enforcement agencies should be transparent in their requests for access. This would ensure that there are clear processes in place for requesting and granting access to personal data, minimizing the potential for misuse or abuse.

Concerns were raised about the implementation of metrics for requester’s access, particularly when the requesters are from authoritarian countries. Questions were posed regarding the accessibility of data to law enforcement in such countries and the verification process to ensure compliance with ethical standards. These concerns emphasized the need for a robust system that prevents unauthorized access to personal information.

The audience also expressed the need for clarification on who has access to the data and how it is granted. This highlighted the importance of defining and understanding access privileges to ensure that data is only accessed by authorized entities and for legitimate reasons.

The adoption of the Registration Data Access Protocol (RDAP) was seen as a positive development. RDAP is a standardized protocol aimed at improving data access and security in domain registrations. However, concerns were raised regarding data privacy and security under the new protocol. The example of Indonesia was mentioned, where a local law prohibits the disclosure of data, even for legitimate law enforcement interests. This highlighted the challenges of reconciling different data protection regulations and ensuring compliance.

Data ownership was emphasized as a fundamental aspect of data protection and privacy discussions. Registrars were highlighted as having an obligation to comply with the data protection laws of the country whose residents’ data they hold. With potential obligations under multiple data protection laws based on the nationality of residents, the need for clarity and understanding of data ownership became crucial.

The forum also recognized the importance of ICANN, IETF, and IANA in addressing DNS privacy and developing policies. There was an expectation for these organizations to be actively involved in considering the costs and benefits of potential tools and providing guidance on DNS privacy.

Regarding Request Distribution Reporting System (RDRS), concerns were raised about its adequacy as a measure of demand. The need for improvements, such as the ability to allow bulk uploading of requests and retaining requester data for analysis, was suggested. It was proposed to hire a privacy lawyer for an in-depth review to ensure the system’s effectiveness.

The uncertainty of registrar participation in RDRS and its potential impact on requesters’ engagement was highlighted. It was remarked that promises on the operation of RDRS could not be successfully delivered due to the unknown number of participating registrars. A negative initial experience discouraging further engagement was also mentioned as a potential consequence.

Suggestions were made to retain data for evaluation purposes to provide an incentive for requesters to continue participating, despite potential initial disappointments. The low submission of requests indicated that some requesters might be tackling the issue without relying on data, but the importance of data retention for downstream analytics was emphasized.

Making participation in the Expansive Secure Synchronized Access and Disclosure (ESSAD) program mandatory was seen as beneficial. It was recognized that ESSAD could potentially serve as a valuable resource for data gathering and enhance the effectiveness of data access and disclosure.

ICANN’s participation in discussions on DNS abuse was mentioned, indicating a commitment to address and mitigate abuse issues in the domain name system. This participation demonstrated the recognition of the importance of maintaining a secure and abuse-free online ecosystem.

The lack of uptake of encrypted DNS, DNSSEC, and other protocols was highlighted, raising concerns about the security of the internet infrastructure. The need for end-user involvement in the design and implementation of standards was emphasized to ensure better adoption and implementation.

Lastly, the importance of not compromising enterprise cybersecurity through the “going dark” phenomenon was emphasized. Privacy was viewed as deluded without security, and it was emphasized that removing all data without ensuring proper security measures would lead to a worse privacy condition than before.

In conclusion, the discussion at the ICANN62 Policy Forum highlighted the necessity of addressing data privacy concerns while ensuring responsible data access. It underscored the importance of transparency, accountability, and clarity in the process of granting data access, especially for law enforcement agencies. The adoption of protocols such as RDAP and ESSAD were seen as positive steps towards improving data privacy and access. However, concerns regarding privacy, security, and the participation and effectiveness of various systems were also raised, emphasizing the need for continuous improvement and collaboration among stakeholders to ensure a secure and privacy-focused internet ecosystem.

Becky Burr

The discussion revolves around the need to protect privacy in the Domain Name System (DNS), particularly with regards to WHOIS data. WHOIS data contains information about the registrant of a domain name, and access to this data can potentially be misused for phishing, fraud, and suppressing free expression.

To ensure appropriate handling of data, it is important to adhere to fair information practice principles, which include principles of lawfulness, fairness, transparency, and accountability. These principles should guide the way data is dealt with in the DNS.

One notable development in 2018 was when WHOIS data went offline and became accessible only upon request. This change was made to provide better accountability and protection of privacy in the DNS ecosystem.

While ICANN (Internet Corporation for Assigned Names and Numbers) plays a role in supporting and facilitating registrars in their data processing responsibilities, it cannot dictate the outcome of the balancing test that registrars must perform when determining the accessibility of data. The responsibility for data processing lies with the respective registrars.

Queries associated with an IP address can provide information about individual and institutional internet uses. However, it is argued that not all queries associated with an IP address should be public. The public nature of the DNS is essential for resolving queries, but privacy considerations should also be taken into account.

Registrars, who hold the data, make decisions about the release of data based on a variety of circumstances. These decisions are informed by the relevant laws, regulations, and the registrars’ own company policies. The release of data should consider legitimate interests and the privacy rights of the individuals involved.

Data ownership is a complex issue that is fundamental to the discussion of data protection and privacy. Modern data protection laws apply not just to processing data within a country but also to the information about residents of that country. When users register a domain name with a registrar, they agree to the registrar’s privacy policy. Additionally, the ICANN contract requires registrars to make certain disclosures.

Compliance with the law is crucial for registrars. Even if registrars are located outside a particular country, they may have obligations under the law of the country where the resident whose information they hold is located. Therefore, registrars must comply with the applicable laws and regulations governing the processing of data.

In terms of encouraging participation, it is suggested that collecting data for downstream analytics can serve as an incentive for registrars to participate. This data can offer valuable insights into the DNS ecosystem. There is even a suggestion to make participation mandatory for all registrars, as it is seen as important for the overall functioning and improvement of the system.

Finally, there is an acknowledgement of the importance of understanding the needs of requesters through the system. This understanding can help address any issues or concerns and improve the overall experience for all parties involved.

In conclusion, the discussion highlights the importance of protecting privacy in the DNS, specifically in relation to WHOIS data. Fair information practice principles should guide appropriate data handling, and registrars are responsible for complying with relevant laws and regulations. Data ownership and privacy are complex issues that need to be considered in the context of data protection. Encouraging participation and understanding the needs of requesters are also essential for the effective functioning of the DNS ecosystem.

Yuko Yokoyama

ICANN (Internet Corporation for Assigned Names and Numbers) is developing a new service called RDRS (Registration Data Request Service), which aims to simplify the process of requesting non-public GTLD (Generic Top-Level Domain) registration data. RDRS will act as a centralized platform for registrars to submit and receive data requests, benefiting stakeholders such as law enforcement agencies, IP attorneys, and cybersecurity professionals.

RDRS is a voluntary service and ICANN cannot force registrars to disclose data through this platform. The decision to disclose or not lies with the registrars, and RDRS operates as a proof of concept service for up to two years.

Key features of RDRS include the automated identification of domain managers, eliminating the need for requesters to identify them themselves. Additionally, requesters will have access to their past and pending requests within the system.

It is important to note that the disclosure of requested data is not guaranteed by RDRS. Each registrar conducts a balancing test before deciding whether to disclose data, taking into account local laws and other applicable regulations. This ensures compliance with legal regulations and protects individual privacy rights.

Only ICANN accredited registrars have access to the RDRS system. They act as intermediaries between requesters and the platform, holding the registration data and routing requests accordingly.

In summary, ICANN’s RDRS aims to streamline the process of requesting non-public GTLD registration data. It provides a central platform for registrars to submit and receive data requests, benefiting stakeholders such as law enforcement agencies, IP attorneys, and cybersecurity professionals. However, the decision to disclose data is ultimately up to the registrars, considering local laws and regulations. Only ICANN accredited registrars can use the RDRS system.

David Huberman:
you for your patience. Welcome to this workshop. I could use my glasses, thank you. Welcome to this workshop. We are going to be discussing current developments in DNS privacy. And why are we going to be discussing that? Well, when the internet was created in the 1960s, 70s and 80s, we were just trying to engineer solutions that would work, that would allow us to intercommunicate. And in 1983, Paul Makapetris was able to invent the DNS to solve two important problems that we were having at that time. One of them was about scaling. One of them was being able to know what all the hosts on the internet were. And the way we were doing it did not scale at all. And so the DNS was able to fill that gap by creating a distributed system that would allow everyone everywhere to know all the hosts and all the names on the internet and map them to the IP addresses that are necessary for computers to talk to one another. Importantly, it also, okay, thank you. Importantly, it also enabled email, it enabled email at scale, because email before 1983, you had to be a human router, you had to describe all the different steps that an email needed to take in order to reach its destination. The DNS allowed us to scale that. So all you needed to know is where someone was me at ICANN.org. And then on the left side of the app, all you needed to know was my address, david.huberman for the local routing of that email. Okay, so why am I giving you all this history? Because from 1983, until really, five or six years ago, ish, all of the DNS data that everybody in the world used and communicated in their queries was all in clear text, it was all out in the open for everybody to see if you were listening on the wire, or if you were operating a DNS element that was looking at your query. And this is a problem because DNS queries have a lot of information about who we are and what we’re doing. It’s 2023, or back then it was 2017, 2016. And this was not acceptable anymore. Privacy is a right, privacy is a responsibility. So we began to develop solutions to increase the privacy of the DNS. I am very honored and you are very lucky that we are going to hear today from four world class experts, who are going to talk about some of these developments, both historically and contemporarily. Today on the panel, Becky Burr. Online, we have Manal Ismail, we have Jeff Houston, and we will end with some new developments here at ICANN with Yuko Yokoyama. So to begin our session and to set us in a good historical perspective and a good legal perspective, it’s my honor to introduce Becky Burr. Becky Burr is a member of the ICANN board. She’s a world class privacy attorney in Washington, D.C. And most importantly, ICANN is entirely Becky’s fault. So if we could please put presentation one, if we could please put those slides up. Becky, to you.

Becky Burr:
Thank you so much and thank you all for being here. If we could go to the next slide. We’re going to talk about two aspects of DNS privacy. I bet some of you are here because you heard DNS privacy and you thought, okay, this is about IP addresses and queries and things. Some of you heard DNS privacy and you’re here because of WHOIS. We’re going to talk about both of those things. And our hope is that we’ll go through the presentations pretty quickly and have a lot of time for discussion. So we’re going to go sort of way back in the WHOIS way back machine world. In 1998, when the U.S. government issued the white paper on domain name management, it said we need to have an organization that ensures that there are policies out there that require that registrant data, including name and address and contact information, is included in the registry database and available to anyone with access to the internet. Now, the world has changed a little bit and I think if you recall the discussion about access to domain name registration data in NIS2, the European Commission directive, European Union directive, it says something slightly different. It does say that policies should ensure that registrant data is collected, that it includes all of those things, and it should be available to people who have legitimate, people who are verified and authenticated to have legitimate interests in that data. So we’ve come a way down the road in terms of finessing the way we think about access to registrant data to reflect the fact that the world has evolved in terms of considerations about privacy. If we go to just the privacy principles, I’m not going to give you a lecture on data privacy law. I’m just going to tell you that almost all data privacy law is built on fair information practice principles and they’re very fundamental principles that guide how you deal with data in an appropriate way. We’re not going to talk about all of these. This happens to be the formulation of fair information practices that’s found in the GDPR, but they’re all quite similar. The things that we need to talk about in terms of DNS privacy for our discussion today is the lawfulness, fairness, and transparency principle that provides that if you’re processing personal data, it has to be lawful and fair and transparent. And fairness is the issue that we’ll think about here in terms of is the processing harmful, unduly harmful, unexplained, misleading, or surprising to the data subject, and accountability and controllers, the people who make decisions about what data is collected, how it’s processed, what’s it used for. Under modern fair information practice principles, those people are accountable for their use of their processing of data. So let’s just talk about the fairness analysis because I think if we’re all on the same page, we’ll do better here. As I said, it’s about is the processing unduly detrimental or surprising or harmful to a data subject? And you think about it in a couple of ways. What’s the purpose of the processing? Is the processing, is the purpose legitimate? Is it legal? Is it ethical? There’s a necessity component, which is do you need to process this data to achieve the goal that we’ve just decided is legitimate? Is it proportionate? Is there a less intrusive way to get the information you need, achieve the goal that you’ve set out with processing this? And you take those two things and you apply essentially about balancing tests. And you say, given the purpose that I want to balance, that I want to process this data for and the considerations about whether there’s a less intrusive way to do it, how does this balance out? How do my legitimate interests compare to the fundamental privacy rights of the individual data subject? So if we apply that in the context of domain name registrant data, we can go back and talk about the original purpose way back when was really for engineers to resolve routing issues. They needed to be able to get in touch with somebody to resolve an issue. But the function of this data has evolved over time. It’s now used, and this is not a new development. This is really since commercialization on the internet began in 1992. This data can be used to identify and mitigate cybersecurity threats, to fight crime and fraud, to protect consumers, and to protect intellectual property. But it also can be, and most assuredly is being used for marketing, for phishing, for fraud, and for suppression of free expression. So there are some important reasons to process this data. There are also some significant potential for misuse of the data. And when we’re talking about balancing, we think about that. The necessity test is, does the registrant data need to be publicly available for anyone to process? Is there a less intrusive way to address the legitimate interests of cybersecurity threats, crime prevention, and the like? And we saw that in 2018 when GDPR went into effect, WHOIS went essentially offline. It wasn’t published on the internet for anybody to see without any kind of accountability. You had to come and ask for it. And that also was a way of making users more accountable. Because before, nobody knew who was looking at WHOIS information and for what purpose. If you have to ask for it, if you have to provide an email address, there’s more accountability. So considering both those tests, is the access to DNS data proportionate? Is it fair? Is it lawful? The answer to that, I’m sure, is clear as mud to everybody, because it really depends on the context. It depends on so many variables that you can’t have a bright line test. You have to think about this in specific context. So the question then becomes, who gets to decide? And I think it’s useful to focus on this for just a minute. Because remember, we said we’re going to talk about fairness. We’re also going to talk about the accountability principle. And under every data protection law that I’m aware of, the controller, the person who makes the decisions about what data is collected and how it’s used, is responsible and is accountable for applying that balancing test. So in the domain name world, registrars are surely controllers. I don’t think that there’s any question about that. Lots of people will debate whether ICANN is a joint controller or not. I don’t think we need to do that for our purposes. You can decide whatever you want on that. Because whatever the answer is, ICANN can’t determine the outcome of the balancing test for registrars, who are themselves controllers and who must conduct the balancing test themselves. So that puts ICANN in a very difficult position. Because people say to ICANN, why are you not making registrant data available? And the answer is, we don’t get to decide. The registrar who has the data, who is delivering it to somebody in response to a request, they are under the law, accountable for and responsible for making that decision. And even if ICANN was willing to say to every registrar on the planet, if you get fined, no problem, we’ll indemnify you, we’ll take care of you. ICANN still can’t have a policy that says you must do something that you think is against the law. So I just think that we really need this question of who decides has to be fundamental in the way we think about privacy. I didn’t mean to do that. So if ICANN can’t dictate the balancing test outcome, can its policies and can its tools facilitate and support that process? Can we make it easier for people to submit requests? Can we make it easier to ensure that registrars have the information that they need to conduct the balancing test that they’re required to conduct? We’re going to talk about that. Yuko is going to talk a little bit about that in the context of a tool that ICANN is rolling out shortly. Now, the other kind of DNS privacy that we’re going to talk about is the more technical kind. And the DNS, what IP address corresponds to what name, is necessarily public. If that information is not public, you can’t resolve queries. But the queries themselves are not necessarily public. And IP queries that are associated with the IP address of the requesting server can tell you things about individual and institutional internet uses, who’s searching for what. People will differ on how good a tool it is to do that, but there’s no doubt that you can get some information. And there are several technical organizations who are working on this aspect, and Jeff Houston, who is on with us, will talk about that. So I’m going to move on quickly to Manal Ismail, our dear colleague from ICANN, who is going to talk about the government perspective on these issues. And I’m hoping that we will have a lot of time for a discussion, because we almost always can have a pretty lively conversation here.

David Huberman:
Okay. If we could please put the presentation down, thank you. And Manal, if you are using slides, if you would be so kind as to share your screen. Otherwise, if not, please go ahead.

Manal Ismail:
Thank you. Thank you very much, David. I’m not using slides, so I’m good to start. And good morning, good afternoon, and good evening, everyone. I’m sorry to miss the opportunity to be with you all in Kyoto. My name is Manal Ismail. I’m chief expert internet policies at the National Telecom Regulatory Authority of Egypt and former chair of ICANN’s governmental advisory committee, the GAC, and now representing Egypt on the committee. Thank you for inviting me to join this distinguished panel on DNS privacy, and many thanks, Becky, for the excellent setting of the scene. In light of the evolving landscape in DNS governance and the ongoing changes related to access of registration data, governments are striving to strike the right balance between, on one hand, privacy protection and responsible handling of DNS registration data, and on the other hand, ensuring transparency, accountability, and access to accurate and reliable registration data. There are great efforts by ICANN in that respect so far, but I will focus my intervention on four key public policy concerns from a government perspective, of course. Related to, first, reduction of registration data and the differentiation between legal and natural persons. Second, access to non-public registration data and the timeline for for response to urgent requests. Third, the privacy proxy service and fourth and last on accuracy of registration data. So to start with the reduction of registration data and the differentiation between legal and natural persons, as you may all know, and as Becky has highlighted previously registration data were made available through free and public Whois services. Starting the 25th of May, 2018, the European General Data Protection Regulation came into force mandating the reduction of any personally identifiable information which changed radically the GTLD Whois landscape and left ICANN grappling with the potential impact of this on Whois services. Just before that on 17 May, 2018, the ICANN board adopted an emergency measure referred to as Temporary Specification or TempSpec for short, in order to enable registries and registrars to comply with the GDPR while maintaining the existing Whois system to the greatest extent possible. This TempSpec allowed the registries and registrars to redact registration data information unless of course provided with registrant’s consent and required the registries and registrars to provide reasonable access to non-public registration data only based on legitimate interest and for a legitimate purpose. This created the fragmented system with distinct policies depending upon the registry or registrar involved and introduced a number of important issues including distinguishing between registration data of legal and natural persons. And this is to allow for public access to legal person’s data since it does not fall within the limit of the GDPR. The relevant policy development process proposed only a mechanism to facilitate the differentiation for those who wish. So it’s kept merely as an option. Therefore, governments in the GAC urged the development of more precise policies that would protect personal data while publishing non-personal data. Noting that a significant percentage of domain names are registered by legal entities and that some analysis shows that a considerably larger set of registration information was redacted around 57.3% as compared to what is required by GDPR estimated to be only 11.5%. Now moving to access to non-public registration data and the timeline for response to urgent requests. In continuation of community work to develop an accreditation and access model that complies with GDPR, a policy development process was conducted and proposed a standardized system for access and disclosure as said for short where consensus was achieved on aspects relating to accreditation of requesters and centralization of requests. Yet agreement could not be reached on the policy recommendations necessary to provide for standardized disclosure. And the ICANN community is now expecting the rollout of a voluntary proof of concept, the registration data request service which is expected to inform future consideration of the ASAN in terms of demand and I believe Yoko will be speaking more to this. Yet certain public concerns are likely to remain such as the lack of centralization with regard to disclosing data, lack of a mechanism for review of disclosure decisions and worries that the recommendations could create a system that is too expensive for its intended users. Additionally, governments, members of the GAC of course are concerned regarding the timeline for response to urgent requests. And by urgent here, we mean limited circumstances that pose an imminent threat to life, injury, critical infrastructure or child exploitation. The proposed timeline contains improvements of course such as an explicit reference to the general expectation of the response within 24 hours and the requirement to notify the requester if additional time is needed. Yet it allows for not one but two extensions that could bring this timeline up to three business days. And the GAC finds three business days not a reasonable time period for responding to urgent requests and moreover, the use of business days injects uncertainty into the process where the three business days would stretch to seven calendar days depending on diversity of global holidays and work weeks. So in an effort to reach a compromise, there was a proposal that the extension notification must include three things. First, confirmation that the relevant operator has reviewed and considered the urgent request on its merit and determined additional time is needed. Second, rationale for why additional time is needed. And third and last, the timeframe for response which is expected of course, not to exceed two business days from the time of receipt. In a recent exchange, the board requested more information from GAC members on their experience with urgent requests and the GAC confirmed its intention to provide such information and acknowledged ongoing work to gather scenarios and use cases of urgent requests and related experience with contracted parties. Moving to the third point on privacy proxy, governments within the GAC are concerned that there is still no policy applicable to domain registrations subject to privacy proxy services which in effect create a double shield of privacy. The GAC requested that at least the registration data record clearly indicates whether the data is protected by a privacy proxy service or not. Particularly that per a study by Interisle Consulting Group, the use of privacy proxy protection has increased over time from 20.1% in 2013 to about 29.2% in 2020. In addition, lessons learned from the COVID experience indicated that 65% of a sample of domains reported to the FBI had registrant data obfuscated by privacy proxy services. And again, during a recent exchange between the GAC and the board, it was acknowledged that the use of privacy proxy services is increasing and it was suggested that meaningful access to registration data would mean integrating the privacy proxy providers into the system similar to how the registrars are integrated. Finally, on accuracy, in GAC principles on GTLD, who is services issued in March, 2007, the government stressed the importance of accuracy of who is data and who is services and that the who is services must comply with applicable national laws. Also, ICANN by-laws recognize that ICANN shall work with supporting organizations and advisory committees to improve accuracy and access to GTLD registration data, as well as consider, of course, safeguards for protecting such data. In addition, dedicated ICANN review teams have considered levels of accuracy of registration data, where the first team found that only 23% of who is records were fully accurate. And the second assessed that data accuracy rate is still high, as high as 30 to 40%. In response to that, ICANN had put in place who is accuracy reporting system, which has stopped publishing reports because it relied on collecting publicly available data. And in 2021, an accuracy scoping team was formed. However, its work has been suspended given data protection concerns around whether ICANN has legitimate purpose that is proportionate. And the work is currently pending outcome of engagement with the European data protection authorities, as well as negotiations between ICANN and contracted parties. So to conclude, the GAC is currently examining opportunities for advancing work on accuracy of registration data. And ICANN is preparing a comprehensive assessment, I understand, of what activities it may undertake to study accuracy obligations in light of applicable data protection laws and its contractual authority to collect such data. I leave it at this, apologies if I exceeded the 10 minutes and I’ll turn it back to you, David, please.

David Huberman:
Oh, thank you so much, Manal. That was extremely helpful to understand the four key public policy concerns that the GAC has today in this area. There’s a lot to discuss here and there’s a lot of people, I think, who would like to have their voices here, but bear with us for just a few more minutes, please, because we wanna finish setting the table here so we can have a good interaction and a good discussion. I’d like to turn now online to our friend, Geoff Houston. Jeff, are you with us?

Geoff Huston:
Yes, I am, thank you.

David Huberman:
Great, thanks, Jeff. It’s good to hear your voice. He probably doesn’t need an introduction, but just in case, Jeff Houston is the chief scientist of APNIC, the Regional Internet Registry in the Asia Pacific region. Jeff embodies the concept of a thought leader. Jeff is someone who understands the internet and how it’s engineered better than almost anyone in the world. And so to help us understand some of the technical considerations in DNS privacy and putting the discussion that Becky and all have laid out for us in a technical context, Jeff, can you take us through some of this, please?

Geoff Huston:
Yes, thank you. And I must admit, I have to say first off that my background is technical, not policy-based. And so when you say DNS privacy to me, I don’t immediately swing over to the registration issue. I don’t. The massive use of privacy proxies, the corporatization of large amounts of the internet, to my mind, that looks like a minor issue. The burning conflagration, the elephant in this room is actually somewhere else. If I can see your DNS queries in real time for any value of you, you have no secrets because everything you do, everything, even the ads you get delivered to your screen, starts with a call to the DNS. And so if I know what questions you’re asking, when you’re asking it, then you have no secrets from me. And you go, well, okay, that’s pretty bad. But unfortunately, it gets worse because the applications that use the DNS that run on your computer or on your phone are not just naive. They are almost criminally negligent in terms of their naivety because they believe the first answer they get. Not the answer. Any answer that is first that reflects the information in the query, that’s the truth. So if I can see your queries and I can jump in first with the wrong answer, you’re mine, I own you. And you can’t even see that it happened because although the queries and answers are in the clear, the DNS innards are incredibly opaque. No one knows where the answer came from. It just comes. It’s like magic. It’s lightning fast, but you can’t check it. You just believe it. Now, you might say, well, so what? But the issue is that this property of the DNS has been used and abused by many over the years. It’s no surprise that the internet’s capitalism is basically based around surveillance and advertising. The more knowledge that advertisers have about me as a user, then the more valuable the ads that can be sort of splashed in front of my eyeballs, the more money the advertiser makes, the more money everyone else makes about me. So knowing about me is critical. And seeing my DNS is a sure path to actually obtain that phenomenal knowledge. Now, it’s not just advertisers, it’s not just commercialism, it’s public entities. Various public bodies have been caught with their fingers in the DNS till looking hard. Malware, all kinds of criminal activity have also focused around the incredible naivety of the DNS. From the technical perspective, the reality came to the answer that enough was enough. It was time to actually arm the DNS with some level of protection against casual eavesdropping and intervention. And there have been three areas in the last five years that have been radical steps forward in making the DNS more private. And they’re quite effective. The first is stopping the DNS being gratuitously noisy. When I want to resolve a.very.long.name that may.have.bad components, then literally everyone gets to see that’s the name I’m trying to resolve. From the root service to the top levels to the second domain and so on. I’m telling the world of my interest in that particular domain. I shouldn’t be doing that. And as it turned out, there was a protocol error way back from 1983. It seemed like a good thing to do at the time. It’s been a disaster. And so we’re doing now a practice called query name minimization. And little by little, we’re clearing up that particularly important leak. But that’s not the heart of what we’ve changed. You may have noticed recently that almost every web page is now HTTPS, not just HTTP. And if you’re using a number of popular browsers, if you go to something that doesn’t have that magic S, that doesn’t use a secure and authenticated channel, the browser goes, hang on a second, this doesn’t look very good. Are you really, really sure? And more recently, some browsers are going, I’m not going there. It’s not protected. I’m not gonna help you in being silly here. It’s not gonna happen. We’re doing the same in the DNS. And little by little, we’re taking this open, very insecure protocol and transforming it. with the same technology we’ve used to protect the web. We’re using PLS is the name of the protocol, but we’re putting the DNS transactions behind a wall of incredibly good encryption. It’s no longer possible to casually eavesdrop. And we’re going even one step further, because if you think about it, a web page, a DNS query, they all look the same. So why don’t we just put the DNS into HTTP? Why don’t we put it into this new protocol called QUIC and wrap the whole thing up with some pretty heavy, heavy duty encryption? So now there is no possibility to be a casual network eavesdropper. But now we’re thinking about more than this, because the real problem is that I, Jeff, am making the query. Do I really have to? Because in the HTTP world, to make the web even faster, there’s a technology called server push. It says, I know you’re going to go to that web page. I really do. And even if you don’t, bandwidth’s available. Here’s some answers. Here’s some objects in advance. So if you touch, you know, if you click, bingo, instant answer. We can do the same for the DNS. We can pre-provision answers. Here’s the results of your search page. And by the way, all those URLs, here’s the DNS. I never make a query. I don’t get caught asking. It’s not me anymore. I’ve gone dark. So with a little help from DNS security, DNSSEC, and chain validation, we’re within a hair’s breadth of actually taking the user out of the picture and making the entire DNS go dark. Now, that means there’s only a few places that know you. And one of them is what we call an open DNS resolver. Normally, your ISP knows that. But there are a few folk like Google and Cloudflare who are very big in this game as well. And it might be very good to have privacy. But if you’re sharing all your secrets with Google, is that really private? Or is that really the veneer of privacy without the substance? And so we’re now working on even better forms of security and privacy, where who I am and what I’m asking for is split apart. And no one knows the two in conjunction. Apple are playing with this with their Apple private relay systems. We’re now no single party knows what the user is asking for. Nobody. That information is only available to the end user. The interior of the system knows nothing. So over the last few years, we’ve seen astonishing leaps in making the DNS more private to stop this kind of tampering and observation of the DNS. It’s not quite the end of the story, because we’re now starting to use the DNS for things other than simply resolving names. We’re using it for content steering. It’s the new routing protocol. When you actually go to a web page, the answer that you get will be different to the answer that I get. You’re in Japan. I’m in Australia. The answers necessarily might well be different. So the DNS has this tension of to give you good answers, you need to expose a little bit about who you are and where you are. But if you really want privacy, you don’t want to expose anything. And fighting that tension between an efficient and fast network and a private network is actually where the substance of the DNS privacy debate is today. So to my mind, registration is a small fire down in the corner of the roof. And I appreciate there is a bit of a fire, and it’s a problem. But the raging problem is the fact that the DNS kind of makes the internet an incredibly exposing experience to folks that you’ve never met, never will meet, but know all about you. And that is a deeply discomforting view that I think from a technical perspective, there’s a lot of energy going into trying to fix that. Thank you.

David Huberman:
Thank you so much, Jeff. If I may make an aside real quick, I’ve been listening to Jeff talk to us as a community for about 24 years. And most of the time, Jeff is yelling at us. Jeff is very unhappy with us, because Jeff has seen everything that’s broken, and he’s telling us we need to fix it. And what was really nice about the last 10 minutes is Jeff shared with us some of these astonishing leaps that we’re making, and actually achieving some of the goals and fixing some of the brokenness that we’ve had for 40 years. There’s one more piece to this. Jeff gave us some really good input about some of the technical considerations to improving this on the DNS side. But next to me, we are very honored to have Yuko Yokoyama. And Yuko is going to talk to us about the next steps that ICANN is taking in helping advance this conversation. If you would please put presentation to slides, thank you. Yuko, I would like to first introduce you to everybody. Yuko Yokoyama is ICANN’s Program Director for Strategic Initiatives. And Yuko is currently leading two programs at ICANN, the Data Protection and Privacy Program and the DNS Abuse Program. Yuko is fluent in English and Japanese and currently resides in Los Angeles, California. So, Yuko, please, if you would, take the microphone and talk to us about ICANN’s Registration Data Request Service. Thank you, David. Konnichiwa. Yuko Yokoyama desu.

Yuko Yokoyama:
Kidding. Just kidding. My name is Yuko. I’m from ICANN. Thank you for the introduction. Today, I’m going to talk about the tool that ICANN is making. And this tool is going to make it slightly easier for data requester and data holder in exchanging information for the request for non-public registration data in the GTLD space. That would be me. Okay. So what is a registration data? Maybe you guys don’t need to be lectured about what it is, but simply put, it’s a contact information, identifying information of the domain name holder, such as names, addresses, and phone numbers. This information is used in a variety of reasons, right? It could be a law enforcement trying to do the criminal investigation or the IP lawyers trying to hunt down the IP infringement, or maybe it’s just trying to resolve technical issues related to the network within that domain name. So as Becky and Manal has talked about, these domain name registration data, such as we used to call it, who is information we’re trying to now call it a registration data within ICANN, it used to be public to anybody and everybody who wanted that data. But with GDPR and other emerging privacy laws around the world, it is now largely redacted. And if you want that data, you have to jump through the hoop to get that. So how are those people who have legitimate interest to want that information, getting that information, such as law enforcement or IP lawyers or cybersecurity professionals, how are they getting this information? Not easily. They would have to first figure out who owns that domain name, which registrars managing that domain name, and then they would have to find the contact information of that registrar, call them up, figure out their own process and procedures on how they accept the data requests. It may be web form, it may be email, it may be just a simple phone call, who knows. But they’re trying to have to figure out the individual registrar’s method to try to submit their redacted data information requests. So obviously it is not ideal. So as Manal mentioned, through ICANN’s various multi-stakeholder policy development process, they have come up with this thing called System for Standardized Access and Disclosure. This is shortened as SSAD. There was a policy recommendation, 18 policy recommendations related to SSAD, and this SSAD envisioned to have pretty great features. It connects data holders and requesters in a standardized manner. Requesters’ identity is verified and the system accredits them. And there were service level agreements specified and other processing requirements. And lastly, it envisioned a paper use model, so requesters who want the data through this SSAD needed to pay for the usage of the system. That said, when ICANN conducted an analysis of these policy recommendations, it turned out to be very complex and possibly very much cost prohibitive. So we needed to figure out first what the demand is out there in terms of such a centralized system, and if there were enough user pools to sustain this system and the paper use model. So here comes the RDRS, the registration data, yes, registration data request service. So RDRS is a proof of concept service that will be operated for a period of up to two years. It is much simpler than SSAD, where there’s no identity verification or accreditation. It is also free. It can be used by anybody in the world who wants to use the service. They can simply sign up and submit their data requests. As the RDRS is not a result of the consensus policy through ICANN’s process, this is currently a voluntary system, meaning that not every data holder, meaning in this case registrars, are needing to participate. So ICANN accredited registrars can choose to participate to receive the request through the other side of the RDRS, or they can choose not to participate. Another thing to note is that there is no service level agreement. Again, this is because it’s a voluntary system. So why are we building this? As mentioned, we first need to figure out if there’s really a demand for such a centralized system, and if so, what kind of volume and what kind of demand, what kind of user pools there may be. And the data that we can collect through this proof of concept two-year operation, this will inform the future of what we can do about this non-public registration data. If there’s demand, great. If not, also, that’s good to know. And you know, through this exercise, we can potentially get some idea in terms of what kind of tools would really be beneficial to the world. Part of this, as you may all know, ICANN is very much about transparency. So once this service launches, we will be publishing the monthly metric report so that you can all sort of figure out what we’re seeing in terms of usage. So how does RDRS work? So it is a centralized platform, just like SDAD, and it allows submission and receiving of non-public GTLD registration data requests. There’s a standardized form and the ability to upload any sort of attachment to make your case as a requester. This means that you don’t have to make a phone call or you don’t have to figure out who owns this, who manages this domain name. You don’t have to cater to individual registrars’ process. Sounds pretty good. But one thing to know is that registrars will be the one who’s making the determination of whether the requester has legitimate interest and decide whether to disclose the data or not. So let’s talk about data disclosure. It is a heavy microphone. So it is a simplified system. Therefore, all communications between the requester and registrars will be taking place outside of the system, including the data disclosure. Disclosure methods will be based on registrars’ choosing, and system does not and cannot guarantee the disclosure of the data. A disclosure decision is solely lying within the data holder. In this case, it is the registrars. I want to stress this point that ICANN cannot, through contract or any sort of policy, obligate registrars to disclose data in any particular case because the law requires registrars the data holder to do the balancing test, as Becky mentioned earlier. So who can use this service? So obviously, data holder side, this would be the ICANN-accredited registrar who choose to participate. And from the requester side, anybody who wants a non-public GTLD registration data. So it could be, as mentioned, law enforcement agencies, IP attorneys, government agencies, cybersecurity professionals, anybody who may hold a legitimate interest. So it could be beyond those people that I’ve mentioned. Since this is a proof-of-concept service, there are some limitations or restrictions. For example, the data holder side, we are not considering registry operators to be part of this. We’re also not envisioning to utilize this system for CCTLD-related registration data. So that’s something important to note. This is only for GTLD domain names. So I’m not going to go through all these next two slides. It talks about benefits for registrars and requesters. As mentioned, on both sides, it will be a streamlined process, you know, standardized form and centralized platform. And you don’t have to figure out who manages the domain. The system will automatically do that for you. And from the requester side, again the same thing, and there’s also a template feature so that you don’t have to fill out the same form over and over if you are submitting more requests than just once. So both registrars and requesters benefit from this standardized form. It’s easier, less pain, I would say, and it acts like a ticketing system. So you can review your past request, your pending request, and what you may about to submit. So when is this exciting tool becoming available? So the system created with Privacy by Design, it’s nearly completed in terms of development work. The launch date is expected to be later this year, probably late November. In fact, we have already opened up the service to ICANN accredited registrars for their early onboarding so that they can become familiarized with this new tool. And then when the service launches to the general public, the requester pool, they will be ready to receive requests already. So I want to conclude this presentation with this. As you all know, the landscape of the internet privacy has been quickly changing, and it will obviously continue to evolve. And balancing the rights of the data subjects and timely access to domain name registration information is crucial more than ever. ICANN is striving to seek ways to evolve with the ever-changing environment and landscape through our multi-stakeholder bottom-up consensus building model. I’d like to encourage all of you, if you are part of the requester pool. If you ever need registration data within the GTLD domain name ecosystem, then this system is for you. As mentioned, this is a proof of concept service. Therefore, more people utilizing it, more accurate and useful data we can produce, which would lead to a better tool in the future. So please spread the word and be ready to use this system in November. Thank you so much for your time.

David Huberman:
Okay, thank you very much, Yuko. That was a very clear and very succinct explanation of this new tool available to everybody. Okay, you’ve all been very patient. Thank you. While we’ve set the table here, it is now time for questions and answers. We have quite a lot of people online who are watching. And online, if you have questions, you may raise your hand. You may type questions in the chat and our online moderator, Patrick Jones, will read them to us. I am going to start in the room. There are microphones on either end. There are microphones at the table. The first person who has gotten my attention is Farzaneh. So please go ahead and take a microphone and talk to us.

Audience:
Thank you, David. My name is Farzaneh Badi. For 20 years, we published domain name registrants’ personal sensitive data, their mailing address, their phone number, their email for everyone on the internet to have access to. This could lead to doxxing in dictatorships and where LGBTQI is illegal. Could actually lead to persecution. And website owners most of the time don’t know that their private sensitive information was being published. Then the privacy proxy came along and there was some kind of improvement. But I just want to give people, I see a few people who have not been involved with ICANN. But I just want to show the gravity of the issue. But I want to also congratulate ICANN. This workshop is one of the first workshops that ICANN actually titles it as DNS privacy and focuses on privacy and not just access. So this is a major improvement and I’m very thankful for that. But then when we don’t have, then we are now talking again about the issue of access and I have several questions. One is that when we talk about the metrics for the requesters, what sort of metrics are we talking about? Are we going to say how many from law enforcement requested access? And if this is globally accessible to everyone, since it’s free, is it also accessible to law enforcement in some authoritarian country? How can you actually verify that? The other thing that I have seen that the government ask for is the request to have confidential logs. And this is very dangerous. We need the governments and law enforcement to be transparent and I know how ICANN has responded to that request. But we need transparency in law enforcement’s request for access to people’s data, personal, private data and they are people. I don’t know where Manal got the stats about that, like the major part of the registrants or organizations and they are legal, but also there are personal information in legal, in even when they are legal entities, there might be their personal information. It might be their name and family name and that’s a personal information. Anyway, I’m not gonna give you more speech, but I think that there are many aspects that we need to think about and this session has been very, very, and thank you, Becky, for that fabulous presentation. It was very, very inclusive of all the aspects of privacy. Thanks.

David Huberman:
Thank you. Please, sir, gentlemen.

Audience:
Good afternoon. My name is John Sihar Simanjuntak from the ID Registry Indonesia. So my question is, so that the only accredited register that can access the data, it’s just my clarification, I think, actually, and then the question is actually how you can grant it to other requests? Maybe, I mean, this is something that we have to define really carefully because the really big question is, do really I can understand how can be granted the request? I mean, because in each country, maybe such different entity can be different situation. That’s my question, actually. I think the first one is about the clarification about who can access that and how you can grant it. I think you have to definitely define exactly what the meaning to be granted of the access. Thank you.

Yuko Yokoyama:
Thank you for your question. So I’m going to answer your first question, which was the ICANN accredited registrars being the only one who’s using the system. So they’re the ones who hold the data. They’re not the requester side. So requesters come to the system and request the registration data for certain domain names. And if that domain name is managed by the ICANN accredited registrars who use and who participate in this RDRS, then the request gets routed to that registrar and that registrar will conduct the balancing test and determine whether to disclose the requested data or not based on the local laws and other applicable laws. I don’t know, Becky, if you want to add something else.

Becky Burr:
No, I think the second part of your question was sort of what are the circumstances under which somebody would have access to the data. And as I said, first of all, the registrar who has the data and has to make the decision to give it out is going to apply the law that they’re subject to, the law, the regulations and the policies from their company that reflect the law and the policy that are relevant to them. Depending on a huge variety of circumstances that are relevant, they’re going to decide what kind of information they need to make a determination about whether they think the person who is requesting the information has a legitimate interest in that information and whether that legitimate interest is overridden by the fundamental privacy rights of the individual. So they’ll conduct a balancing test. They’ll decide if they have the information they need to make that determination and that decision will be based on and informed by the law that they’re subject to.

David Huberman:
Patrick.

Audience:
Thanks, David. It’s Patrick Jones from ICANN. Wanted to also mention, since we don’t have any remote questions yet in the chat, that one of the other elements that’s changing is that we’re moving to a new, more secure, more standardized protocol called the Registration Data Access Protocol. So in the past and historically, all of this registration data has been delivered through a protocol called WHOIS. And many of the registries are already delivering this registration data through the RDAP protocol. My point to Jeff to see if you might be able to touch on this a bit more as well. I believe all GTLB registries are already doing this. We’ve been going through a contract change process with the generic top-level domain registries to enable them to use the RDAP protocol and many country code registry operators are also using it. So with that, I’ll turn it back to the panel to note that RDAP is something new and we’ll be using this with the system. Okay, did we want to have a quick follow-up here, sir? Please. Yeah, following the explanation actually. So Indonesia, we have already the same similar GDPR actually last year, since last year. And the question is since you have the database can access through the accredited registrar, meanwhile the registrar maybe it’s not the native data. I mean, not the owner of the data. How can the registrar can provide the data while the registrar is not accountable to that data because it’s data maybe crossed globally from the ICANN database. So I mean, in our law, of course, this is not allowed to give data. Even the legitimate interest is the police, let’s say, but since the registrar is not the owner of the data, I think it’s still not allowed. Thank you.

Becky Burr:
So the question of data ownership is so fundamental to the discussion of data protection and privacy that it would take us the rest of our natural lives to discuss it here. So I think we’ll just skip that part of it. If your information is with a registrar in Malaysia, that registrar is certainly subject to Malaysian law. It’s possible that a registrar in another country also has obligations under Malaysian law with respect to your data as well because the way modern data protection laws work is it tends to apply to processing of information about a resident of the country. And it doesn’t only apply to processing within the country. So even if a registrar is outside of the country, they may have obligations under Malaysian law. But, and I am not an expert on the Malaysian data protection law, I can tell you that there are circumstances, the balancing test that we talked about where it would be appropriate or it would be okay for a registrar to disclose that data. And then there are gonna be circumstances where it wouldn’t be okay for a registrar to disclose that data. Just in terms of the issue, when you sign up for, when you register a domain name with a registrar, you will be asked to agree to their privacy policy. Their ICANN contract requires them to make certain disclosures as well. And so there are some contractual provisions that flow from you to the registrar. But the point is, the bottom line is that the registrar has to comply with the law that applies to the processing of that data. And if it’s Malaysian law that governs that processing, then they have to comply with Malaysian law. And if it’s Irish law, that or European Union regulation that applies, they will apply that law to it.

Audience:
Steve. Thanks, Steve Del Bianco. I work with NetChoice, a trade association in Washington, but also very active at ICANN for the last 20 years and in the business constituency. And I am most eager to hear more about Jeff Houston’s elephant. Namely, what would ICANN, IETF and IANA have to do? How would you be involved? I can’t be involved in that element of DNS privacy on the development dissemination of those protocols and standards and what policies would be developed to address it. And then allowing the community to suggest costs and benefits of some of the tools that Jeff has talked about. But I think that elephant is not going anywhere. He’ll wait a little bit. What’s more immediate is within a few weeks, we’ll start the RDRS, turn it on and offer it. And I was part of the group that did the EPDP as well as the small team in RDS and RDRS. And I’d always believed that it would be a false promise to think that a system like that would be an adequate measure of demand. Because the demand that we’re talking about is the demand to solve a problem, a requester like a commercial organization is trying to stop fraud that’s harassing their own consumers and undermining their businesses reputation across a wide variety of an audience. There might be IP attorneys looking to protect their IP, but it’s usually to protect consumers that are getting defrauded. That’s the character of that. We also have security researchers as well as security professionals trying to stop a current attack that’s going on. And then you have law enforcement, which Manal talked a little bit about. Now, historically, WHOIS helped to decrease the time it took and decrease the cost it took to start that investigation of solving the problem. It was only part of, a small part of solving the problem. You’re probably well aware that even before GDPR, we had an increasing proportion of registrations that would go privacy proxy. That was of concern, because it meant that ICANN needs to embrace the privacy proxy providers to accredit and hold them accountable to the standards of performance. And that got interrupted, of course, by the effective date of GDPR fines in 2018. And ICANN’s reaction to that led to a dramatic reduction in the value of using WHOIS to begin to solve problems that often are maybe not rise to the level of urgency that Manal gave us, imminent threat to life, right? Or critical infrastructure. But it’s quite urgent if your customers are being defrauded at the rate of thousands a day, because they’re being directed to another website or a fraudulent Red Cross donation site to take advantage of a new natural crisis. So the demand for RDRS may not be indicative of the demand for an SSAD that achieved some of the benefits. I mean, it’s not a replication of what value SSAD would provide. So there shouldn’t be an assumption that the demand value will transfer. Let me explain why. That the value of a requester submitting a request won’t be sufficient with RDRS to motivate a lot of use. So we’re having to find other ways to motivate the use of RDRS. And that’s a real challenge, because the promised value of RDS, as well as experience value is low. So I’ll reiterate something that I’d like you to consider. There’s still time. There’s still time. before you deploy, to do a few things that will increase the likelihood of value and increase the use. Not only the use in terms of the monthly metrics, but increase the use in a way that gives us the data we need to determine whether asset is worth doing, or determine whether new policies are necessary. Yuko, you’re well familiar with this, but one is to allow a request or to load a bulk, but a batch of requests for multiple domains that might be in use right now with a threat to my customers. And ICANN said no, didn’t want to do that, thought it would delay the release date. And I’m a programmer, so if that’s true and it’s a problem, why not still work on it? Put it on the queue for something that could be announced within a few weeks or months of the release. Make it the second thing that comes out, so it doesn’t jeopardize the release date. And then finally, I would say that retain in detail all of the data that a requester submits even if it turns out that the registrar is not participating. That data is essential to do analysis at any point before we conclude whether there’s demand. Because that analysis would show the quality and the quantity of who’s requesting, why they’re requesting, what evidence they presented, what reason or legitimate reason they’ve offered. And then on the other flip side, were the registrars who did participate, how fast did they respond and how well did they apply the balancing test? Because you can look at the evidence if you retain it. Now, if there’s a concern that you don’t want me to see all that data, that’s fine. Let’s hire a privacy lawyer that ICANN lets look at the data and comes back with a more qualitative analysis as opposed to just a handful of metrics. So there are things that ICANN can do in the four weeks remaining. Start to work on bulk uploads, right? And don’t throw the data on the floor. Don’t throw the data away. If it turns out that I put all the work into formulating requests and I provide all this evidence and screenshots, oh, but the registrar isn’t participating. So we lose the ability to understand what the demand was because that is the measure of demand. The measure of demand is the requests I put in, and if you throw most of them on the floor, you’re not going to get a good answer. Thank you.

Becky Burr:
So as we discussed, I do think there is some value in doing analytics on the data. But I’m a little confused about one thing that you just said, which is I think you’re saying that people are only going to use it if they, they’re not going to, in other words, they’re not going to use it to make requests. They’re going to use it to create the data. I mean, okay, so then why, well, then I’m confused because I guess I don’t understand what you’re saying, what the value, the value that you’re seeing, that you’re talking about is not the return of the data or the ease of the submission. It’s the creation of information about requests.

Audience:
If I could just clarify, Becky. We can make promises about what RDRS will do when it turns on, but none of us know how to effectually deliver on the promises because we have no idea how many registrars, registrars whose domain names are the subject of requests, will be participating on day one. We’re not going to be very clear about who the nature of that is, nor can we make promises about the fairness that’s done in the evaluation of the balancing test. So you make promises, but ultimately it’s the first experience, the first taste the requesters get when they submit their first several requests. And if it turns out that over half of the first batch of requests I put in were for non-participating registrars, you’ve just really diminished the interest of that requester to bother to do any more. So once they get a bad taste, or they get participating registrars that take four days to come back and say, nope, you don’t pass the balancing test, if the first taste is bad, then that requester community, I would like them to stay engaged, Becky. I want them to stay there to provide evidence of demand, but they have to have some assurance that having been disappointed at the actual experience and taste, is there a reason to do another set of requests? You know, I put 10 in, five were non-participating registrars, and the rest took three days to get back, and the balancing test said take a hike. I’m not going to come back to you unless there’s some other reason. So think of it as a two-step reason. First is, maybe I’ll get a good taste back, maybe it’ll actually help me stop an existential attack. But if it doesn’t, for reasons that are outside of your control, if it doesn’t, retain the data necessary to analyze the nature of demand that was there, and that will provide an additional incentive for people to continue to try the requests.

Becky Burr:
Okay, so I mean, I just want to confirm that what you’re saying is that the data, the analysis that, the retention of data for downstream analytics is an incentive for participation. Okay, I get that. I think we have to acknowledge here that the analysis that we just talked about in terms of is there a less intrusive way to accomplish your goal, stopping crime, protecting intellectual property, whatever it is, the only source of information that we have at this point is who’s going to submit requests, who submits requests. What we hear anecdotally is that registrars are not getting very many requests. And the consequence, which I think is a logical conclusion from that, is that requesters are getting, they are attacking the problem in a different way that doesn’t use the data. And that is the fundamental essence of the balancing test. So all I’m saying, and by the way, ESSAD isn’t going to change that outcome at all. So we are very much encouraging all registrars to participate. As you know, the board did suggest that the JNSO Council consider policy development to make participation mandatory, because we know just how important that is. But I do think for this collective data gathering, we have to ask requesters to make their needs known through the system.

Audience:
Edwin, did you want to add to that, please? Edwin Chung here. I just wanted to respond to Steve’s other question. So just a note, Edwin from DotAsia, also serving on the ICANN board, but I’m not speaking in my capacity of board, but as a general participant. But on the first item that you mentioned, the elephant or the burning question that Jeff has, ICANN is, and both the ICANN community and ICANN itself is actively participating in discussing those issues. And I think Jeff can add to that. At the ICANN meetings, actually those were discussed a few years back. You might remember DOA, DOH discussions. That’s part of what I think Jeff mentioned, and Jeff, please add to it. And follow from that, what is called OARC. I don’t know whether you know OARC, but I don’t really know the long version. It’s Operational Research Analysis Coalition, something like that. But that, I think, is also part of the multi-stakeholder model in the work, because I want to emphasize one thing, and the reason why this session is here at the IGF and not at ICANN is because of that broader sense. And this is an issue that is not just an ICANN issue, but an issue that we need to involve other stakeholders for which ICANN is one of them. The Who Is Matter has a slightly smaller element to that, but the other part has a bigger element to that, and it’s closer to things that we talk about, such as DNS abuse. ICANN can do one part of it, but there is a much larger DNS community that needs to do further work on those type of things. So I don’t know whether Jeff wants to add to it, but just a quick answer is that ICANN and the ICANN community are working on that other elephant as well. And hopefully, we’ll shrink or start walking away, but Jeff, you definitely have much more

Geoff Huston:
to say. I have some bad news. I have some very bad news for you. The issue is that once abused, there’s no coming back. And the response from the technical community is heading down a path that, quite frankly, touches upon an addiction in this industry. We are addicted to open DNS data. What if the DNS and its use generated no data whatsoever, nothing, could not see it, nobody, no matter how good their tool? What then? What names am I going to look up for registration if I don’t know what names are being used in the first place? Once you get a totally opaque system, then this entire conversation heads down an entirely different path that very few people are actually prepared to think about right now. But the response from the technical community is to create precisely that picture, that there is no attribution in the use of names whatsoever if we head down this area of abuse, obfuscation and encryption. This is nothing left. So everything that we’ve been thinking about, yes, we know how the DNS works. We understand what DNS abuse is and so on. Once you go down this privacy path to its destination, all the lights go out. It’s dark. And at that point, it’s an entirely different world. And exactly how we’re going to respond as law enforcement, as engineers, as network operators, when the network has all the lights turned off, is a question I don’t think anyone’s actually able to answer. Now, what’s ICANN’s role in all this? I’m not sure ICANN has a role other than be another onlooker into what is either going to be a phenomenal success for privacy or a phenomenal tragedy. I don’t know which either at this point. But I do know the path is inexorable and the answers are certain. We are going to turn the lights off. And that’s just one of those things that’s going to happen. It’s an interesting area to contemplate.

David Huberman:
Thank you, Geoff. We have three minutes left. Andrew?

Audience:
Fantastic. You may as well stay there, Jeff. Because I thought he was looking bored. So I wanted to bring him in. Anyway, two things. The picture you painted, Jeff, before when you touched on encrypted DNS and DNSSEC and so on was all very positive. You didn’t mention, unusually for you, the lack of take-up of many of those. So designing the protocol is interesting, but that’s the start of the solution. It’s a long way short of the end. And I would suggest part of the problem for the lack of take-up is the – so ITF, when it develops standards, there’s little, in reality, no involvement of the end-user community. So maybe we will get better take-up of standards if we bother to involve the end-users in the design process. Because we’re designing things that are either too hard to implement or they’re not interested in implementing. So ticking the box because we’ve got the protocol is not really that interesting in solving this. And then just briefly and finally, to your point on when we get to that destination or everything going dark, if we have a diverse standards community, which includes CISOs, I can tell you from personal experience of talking to them, they will be horrified at that because we kill enterprise cybersecurity when we go dark. And then if we think we’ve got privacy, we’re deluded because at that point, we’ve got no privacy at all because we’ve got no security. So I think the privacy purists, I think, are kidding themselves if they think they get privacy by removing all the data. That’s when they really have a problem. They’d be far worse than it ever was before.

Geoff Huston:
Andrew, just think for a second, and I’ll respond very, very quickly. The biggest tension in the internet is between applications and infrastructure, and the applications have won the game hands down. QUIC is not a transport protocol. QUIC is an attribute of the application. The application designers, and particularly the browser engines, have lost patience with the rest of us. Privacy in the DNS is not a DNS infrastructure problem anymore. It’s what browsers are doing and where applications are heading. They have the money, the agility, the update factory and infrastructure. And so the DNS is being taken away from traditional DNS operators because they’re basically too slow and the job they’re doing is not good enough from the perspective of the application. And that battle for control, round one happened in Firefox, round two will happen in Chrome and Safari. In fact, Apple is probably there already with its own relay, Apple privacy relays. So Andrew, the fight is happening further up the protocol stack, and the application folk who have the money, the agility, and the motive appear to be winning hands down at this particular point in time. The infrastructure folk are being left behind. It’s interesting to think about. Thank you.

David Huberman:
Manal, you have your hand up.

Manal Ismail:
Yes, it’s a more of a general comment and I feel obliged because I’ve been mentioned twice so quickly to agree with Steve on the importance of the data collected during the proof of concept and also to agree with Farzi that there are many aspects to this discussion. And it’s very interesting to see that despite the diverse views, we are all talking from a public interest perspective. So on one side, it’s privacy, on the other side, it’s safety. And I hope we can utilize ICANN’s bottom-up multi-stakeholder model to continue a constructive and inclusive discussion to be able to strike a right balance in that respect. Thank you.

David Huberman:
Well, thank you so much, Manal. That is actually a wonderful way to end it because unfortunately, my friends, we are out of time, even though there are more questions. Thank you very much for coming. I’d like to thank Becky Burr, Yuko Yokoyama, Goeff Houston, Manal Ismail, Patrick. Thank you for getting up so early and being our online moderator. And thank you all for coming. This concludes that session. Thank you. Thank you. Thank you. Thank you.