IGF 2023 – Day 2 – WS #402 Current Developments in DNS Privacy – RAW

>> DAVID HUBERMAN: Okay, I think we are now ready to start. Thank 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 Makipetris 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 about being able to know what all of 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 ‑‑ oh, 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 was where someone was ‑‑ [email protected] ‑‑ and then on the left side, all you needed to know is my address, David.Huberman, for the local routing of that email.

Okay, so, why 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 was a problem because DNS queries have a lot of information about who we are and what we're doing.

This 2023 ‑‑ or back then, 2017, 2016, and this is 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 honoured, 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 con temporarily. On the panel today, Becky Burr. Online, we have Manal Ismail, we have Geoff Huston, 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 honour to introduce Becky Burr. Becky Burr is a member of the ICANN Board. She is 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 1, if we could please put those slides up. Becky, to you.

>> BECKY BURR: Great. 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 ‑‑ oh, I can do it myself. Great!

>> DAVID HUBERMAN: Yes. The green one.

>> BECKY BURR: The green one. We're going to talk about two aspects of DNS privacy. So, I'll bet some of you are here because you heard "DNS privacy," and you thought, "Okay, this is about IP addresses and queries and things."  And 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 wayback 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.

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, that people who make decisions about what data is collected, how it's processed, what it's used for, under fair information, 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, a balancing test, 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.

A 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, you know, 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 is a way of making users more accountable. Because, before, nobody knew who was doing, 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 we haven't ‑‑ it's useful to focus on this for just a minute, because remember, we said we were 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 the 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 usage ‑‑ 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 Geoff Huston, 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 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 data and the differentiation between legal and natural persons. Second, access to non‑public registration data and the timeline 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 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 GTRD 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 Temp Spec, 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 temp spec allowed registries and registrars to get registration information unless provided with registrant's consent and required registries and registrars to provide reasonable access to non‑public registration data, only based on legitimate interests 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, SSAD 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 voluntary proof of concept, the Registration Data Request Service, which is expected to inform future consideration of the SSAD in terms of demand, and I believe Yuko 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 mechanism for review of disclosure decisions, and what is 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 requestor 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 could 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 time frame 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 scenarios 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 date of record clearly indicates whether the data is protected by a proxy privacy service or not, particularly that a study by (?) consulting group, the use of privacy 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 GTND, who services issued in March 2007, the governments stressed the importance of accuracy of WHOIS data and WHOIS services, and that the WHOIS services must comply with applicable national laws. Also, ICANN bylaws recognise that ICANN shall work with supporting organizations and advisory committees to improve accuracy and access to GTND registration data, as well as considered, 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 WHOIS 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 WHOIS accuracy reporting system, which has stopped publishing reports because it relied on collecting publicly available data.

And in 2021, an accuracy spoken team was formed, however, its work was suspended given concerns over 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 ten minutes, and I'll turn it back to you, David, please.

>> DAVID HUBERMAN: 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 heard, but bear with us for just a few more minutes, please, because I want to finish ‑‑ we want to 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 Huston. Geoff, are you with us?

>> GEOFF HUSTON: Yes, I am. Thank you.

>> DAVID HUBERMAN: Great! Thanks, Geoff. It's good to hear your voice. He probably doesn't need and introduction, but he is the chief scientist of APNIC, the Internet registry in the Asia‑Pacific region. Geoff embodies the concept of a thought leader. He 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 Manal have laid out for us in a technical context, Geoff, 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 configuration, the elephant in this room is actually somewhere else. If I can see your DNS queries in realtime, 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, okay, that's pretty bad, but unfortunately, it gets worse.  Because the applications that use the DNS that run on your computer, on your phone, are not just naive, they are almost criminally negligent in terms of their naivete, because they believe the first answer they get. Not "the" answer. Any answer that is first reflects the information in the query, and it comes back, 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 innerds are incredibly opaque.

No one knows where the answer came from. It just comes. It's magic.

It's lightning fast. But you can't check it. You just believe it.

Now, you might say, "So what?" But the issue is that this property of the DNS has been used and abused by many over the years. Now, 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 attain that phenomenal knowledge.

Now, it's not just advertisements; 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 forms of criminal activity have also focused around the incredible naivete of the DNS.

From the technical perspective, the technical community 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 dot, very, dot, long, dot, name, that may, dot, have, dot, bad, dot, components, then literally everyone gets to see that's the name I want to resolve, from the root servers to the top levels to the second ‑‑ 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 going to help you in being silly here. It's not going to 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's name and 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 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, Geoff, 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. 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, if you click, bingo! Instant answer. We can do the same for the DNS. We can preprovision 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, DNS Sec and change validation, we're within a hair's breath 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 folks, 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. When 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 room. Now, I appreciate there is a bit of a fire, and it is 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 is a lot of energy going in to try and fix that. Thank you.

>> DAVID HUBERMAN: Thank you so much, Geoff. If I may make an aside real quick. I've been listening to Geoff talk to us as a community for about 24 years, and most of the time, Geoff is yelling at us. Geoff is very unhappy with us, because Geoff has seen everything that's broken and he's telling us, "We need to fix it!" And what was really nice about the last ten minutes is Geoff shared with us some of these astonishing leaps that we're making in 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. Geoff 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 honoured 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. I would like, if you would please put presentation 2 slides. Thank you. Yuko, I would like to first introduce you to everybody. 

Yuko Yokoyama is ICANN's Programme Director for Strategic Initiatives. And Yuko is currently leading two programmes at ICANN, the Data Protection and Privacy Programme, and the DNS Abuse Programme. 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.

>> YUKO YOKOYAMA: Thank you, David. Konnichiwa. (Speaking in Japanese) 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 requestor and data‑holder in exchanging information for the request for non‑public registration data in the gTLD space. That would be me.

So, what is registration data? Maybe you don't need to be lectured about what it is, but simply put, it's 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 ‑‑ we used to call it WHOIS information ‑‑ we're trying now to 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 interests to gain that, to want that information, getting that information, such as, you know, 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 registrar's 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 multistakeholder policy development process, they have come up with this thing called system for standardized access and disclosure. This is shortened as SSAD. There is a policy recommendations ‑‑ 18 policy recommendations related to SSAD. And this SSAD envisioned to have pretty great features. It connects data‑holders and requesters in standardized manner. Requester's identity is verified and the system accredit them. And there were service‑level agreement specified and other processing requirements. And lastly, it envisioned paper use model, so requesters who wants 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 pulls to sustain this system in the paper use model. So, here comes the RDRS, the Registration Data Request Service. Yes.

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 is 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 needed to figure out if there is really a demand for such a centralized system, and if so, what kind of volume and what kind of demand, what kind of user pulls there may be. And the data that we can collect through this proof of concept to your operation, this will inform the future of what we can do about this non‑public registration data. If there is demand, great! If not, also that's good to know. And 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? It is a centralized platform, just like SSAD, and it allows submission and receiving of non‑public gTLD registration data requests. There is a standardized form and the ability to upload any sort of attachment to make your case as a requestor. 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 registrar's process. Sounds pretty good. But one thing to note is that registrars will be the one who's making a determination of whether the requestor 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 requestor and registrars will be taking place outside of the system, including the data disclosure. Disclosure methods will be based on registrar's choosing. And system does not and cannot guarantee the disclosure of the data. Disclosure decision is solely lying within the data‑holder, in this case 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 registrars who choose to participate. And from the requestor's 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 requestors. As mentioned, on both sides, it will be 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 requestor's 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 requestors 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 requests, your pending request, and what you may be about to submit. 

So, when is this exciting tool becoming available? So, the system, created with Privacy by Design, is 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 this 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 requestor pool, they will be ready to receive requests solely. 

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 multistakeholder bottoms‑up consensus‑building model.

I'd like to encourage all of you, if you are part of the requestor 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 question 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 Farzani. So, please, go ahead and take a microphone and talk to us.

>> AUDIENCE: Thank you, David. My name is Fardined. 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 doxing 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 mean, I don't ‑‑ I see a few people 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 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 requestors, 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, you know, law enforcement in some authoritarian country? How can you actually verify that?

The other thing that I have seen that the government asks 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. We need transparency in law enforcement requests for access to people's data, personal, private data, and there are people. I don't know where Manal got the stats about that, like the major part of the registrants or organizations, but also, there are personal information in legal, even when there are legal entities, there might be their personal information. It might be their name and family name, and you know, that's personal. Anyway, I'm not going to 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 inclusive of all the aspects of privacy. Thank you. 

>> DAVID HUBERMAN: Please, sir. Gentleman. 

>> AUDIENCE: Good afternoon. My name is John from (?) Registry Indonesia. So, my question is, so that ‑‑ the only accredited registrar that can assess the data ‑‑ just my clarification, I think, actually. And then, the question is actually how you can grant it to other requestors? I mean, maybe this is something we have to define really careful, because, really, the question is, really ICANN understand how to be granted the requestor. Because in each country maybe each entity can be a different situation. That's my question, actually.  I think the first one is about the clarification, but who can access that and how you can grant it. I think you have to define exactly what the meaning to be granted of the access. Thank you. 

>> Thank you for the question. So, I can answer the question about the ICANN registrars being the only ones accessing the system. They hold the data. They're not the requestor side. So, requestors come to the system and request the registration data for certain domain names and if that domain name is registered by the registrars who participate in the 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?

>> PATRICK JONES: Thanks, David. This is Patrick Jones from ICANN. I 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 RDAT protocol. Geoff might be able to touch on this as well. I believe all gTLD registries are already doing this. We've been going through a contract change process with the generic topical domain registries to enable them to use the protocol and many country code 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. 

>> DAVID HUBERMAN: Okay.  Did we want to have a quick follow‑up here, sir, please?

>> AUDIENCE: Yeah, following the explanation, actually. So, Indonesia, we have the same, similar GDPR actually, 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 its data may be across globally from the ICANN database here. 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'm 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 going to 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. The 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 or European Union regulation that applies, they will apply that law to it.

>> DAVID HUBERMAN: Steve.

>> AUDIENCE: Thanks. Steve Del Bianco, Net Choice trade association in Washington, but very active in ICANN the last 20 years and in the business constituency. I am most eager to hear more about Geoff Huston's elephant, namely, what ICANN, IETF, and IM have to do. How would you be involved, ICANN, 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 Geoff has talked about. But I think that elephant is not going anywhere. He'll wait a little bit. What's most 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 RDRS, and I 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 requestor, like a commercial organization, is trying to stop fraud that's harassing their consumers and undermining their business's reputation across a wide variety of an audience, right? There might be IP attorneys looking to protect their IP, but it's usually to protect consumers that are getting defrauded. Right? 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 achieves 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. The value of a requestor 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 RDRS as well as experience value is low.

So, I'll reiterate something 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 SSAD is worth doing or determine whether new policies are necessary. And Yuko, you're well familiar with this, but one is to allow a requestor to load a bulk, load 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.

Last, I would say retain in detail all of the data a requestor submits, even if it turns out that the registrar's 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 flip side, where 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. And 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, let's 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 a request and I provide all this evidence, screen shots. 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 ‑‑ 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 that return of the data or the ease of the submission, it's the creation of information about requests.

>> AUDIENCE: If I could clarify, Becky. We can make promises about what RDRS will do when it turns on, but none of us know how to essentially deliver on the promises because we have no idea how many registrars ‑‑ registrars whose domain names are the subject of requests would 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 that the requestors get when they submit their first several requests. And if it turns out that over half the first batch of requests I put in were for non‑participating registrars, you've just really diminished the interest of that requestor 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 requestor 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 ten in. Five were non‑participating registrars and the rest took days to get back and the balancing test said, "Take a hike."  I'm not going to come back to you, unless there is some other reason.

So, think of it as a two‑step reason. First is, maybe I'll get a good taste back. Maybe it will 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 analyse 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, that just ‑‑ I just want to confirm that what you're saying is that the data ‑‑ the analysis, 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 requestors 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, SSAD 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 GNSO council consider consideration to make participation necessary because we know just how important that is. But I do think for this collective data gathering, we have to ask requestors to make their needs known through the system.

>> DAVID HUBERMAN: Did you want to add to that, please?

>> Edmond Chung: Edmond Chung here. I just wanted to respond to Steve's other question. So, just a note. Edmond from .Asia, also from the ICANN Board, but I'm not speaking on my capacity of the board, but as a general participant.

But on the first item that you mentioned, the elephant or the burning question that Geoff has. ICANN is, and both the ICANN community and ICANN itself is actively participating in discussing those issues. And I think Geoff 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 Geoff mentioned. And Geoff, please add to it.

And follow from that what is called OARC. I don't know if you know OARC. 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 multistakeholder 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 WHOIS 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 Geoff wants to add to it, but just 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 Geoff, you definitely have much more.

>> GEOFF HUSTON: 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 they are. 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.

The response from the technical community is to create precisely that, that there is no attribution in the use of names whatsoever if we head down this area of abuseification and encryption. There's just 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 head 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 going either 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 you know, that's just one of those things that's going to happen. It's an interesting area to contemplate. 

>> DAVID HUBERMAN: Thank you, Geoff. Okay, we have three minutes left. Andrew?

>> AUDIENCE: Fantastic. You may as well stay there, Geoff, because I thought he was looking bored, so I wanted to bring him in anyway.  Two things.  The picture you painted, Geoff, before, when you touched on the encrypted DNS and DNS Sec, you didn't mention the lack of take‑up of many of those. So, designing the protocol's interesting, but that's the start of the solution. It's a long way short of the end. And I suggest part of the problem, for the lack of take‑up, is the sort of ITF, when it developed standards, there's little, or 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 too hard to implement or that are 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 of everything going dark, if we have a diverse standards community which includes CISOs, I can tell you from firsthand 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. It'd be far worse than it ever was before.

>> GEOFF HUSTON: Andrew, just think for a second, 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 designs, 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's not good enough from the perspective of the application. And that battle for control, round one happened in Firefox, round two will happen in Safari and Chrome and Apple is almost there with the Privacy Relays. So, the Andrew, the fight is happening further up the protocol stack and the application folks who have the money, the agility, and the motive, appear to be winning hands down at this particular point in time. The infrastructure folks 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 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 multistakeholder model to continue a constructive and inclusive discussion to be able to strike a right balance in that respect. Thank you.

>> DAVID HUBERMAN: 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, Geoff Huston, Manal Ismail, Patrick. Thank you for getting up so early and being our online moderator. And thank you all for coming. This concludes the session.