This is now a legacy site and could be not up to date. Please move to the new IGF Website at

You are here

IGF 2020 - Day 8 - WS 73 DNS over HTTPS (DoH): Human Rights, Markets, and Governance

The following are the outputs of the real-time captioning taken during the virtual Fifteenth Annual Meeting of the Internet Governance Forum (IGF), from 2 to 17 November 2020. Although it is largely accurate, in some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the event, but should not be treated as an authoritative record. 




     >>  And the U.N. rules of regulations. Thank you. The moderator, can you take over?


     >> BRENDEN KUERBIS: Thank you, secretariat. Welcome, everybody, to workshop number 73 at DNS over HTTPS, Human Rights, Markets and governance. My name is Brenden Kuerbis. We have a long record of fostering dialogue among stakeholders at the IGF and elsewhere on important emerging internet governance topics.

This workshop brings together a panel to discuss the implications of a fairly new protocol, DNS over secure hypertext transfer protocol which is a modification intended to improve the integrity and confidentiality of DNS queries. Encrypted DNS presents a challenging tech policy issue that's institutionally complex and involves numerous economic and political interests and has the potential to be governed in multiple ways.

Many parties have written extensively on the issue, but to date the dialogue about implementing it has largely been centered on potential impacts on ISPs, network and enterprise security and government legal policy regimes in western countries.

Less explored is the trans national context and the role of markets and users in other countries. For example, the confidentiality of DNS query, data and availability of information can be especially important to individuals in countries where a government or a state‑controlled ISP might conduct surveillance or censor websites or information. We see a negative relationship between countries that score lower on freedom of expression indices and higher use of open DNS resolvers.

While correlation is not causation that relationship has strengthened.

It is an indicator of growing demand for less restrictive DNS resolution. There are legitimate concerns about the centralization of data and DNS services in the lands of big global platforms and questions about how users, networks and applications will discover and select resolvers. We need to distinguish concerns of technology centralization and the risks it can present from a broader understanding of the risks of market concentration which incorporates the notion of firms competing to provide DNS resolution as well as complementary products and services

DoH and how it is implemented is a means of extracting part of the market which until now has been captured by local ISPs. From a governance perspective as DNS data becomes encrypted and shifts to different actors impacts on domestic regulatory compliance and extraterritorial effects of policies. Encrypted DNS brings into view differences of how stakeholders may view censorship, data retention and access as well as other areas. The decisions made about how the protocol is deployed will have dramatic impacts on stakeholders.

To better understand all of these issues our discussion today brings together experts and regional perspectives to discuss and hopefully interact with the audience on broader human rights, market and governance impacts of DoH development and deployment.

I will now briefly introduce our panelists and we will hear from each of them. Then we will follow this by panelist reactions and interactions prompted by questions from myself.

We'll follow it with Q&A from the audience.

I encourage the audience to use the chat to discuss as we move along. Please put questions you may have in the Q&A box we are monitoring. First up, I would like to introduce Barry Leiba the IETF director for the area groups that developed DoH and a member of the security and stability advisory committee at ICAN. Barry, take it away.

>> BARRY LEIBA: Hi. While I'm getting my screen shared, my first slide is going to show where I'm coming from. I'm the area director responsible for the working groups that worked on DoH and are working on follow‑on protocols such as discovering, supporting, resolvers and that sort of thing.

I'm also the security and stability advisory member who chaired the work on the document that SSAC did giving an analysis of DoH. You might be interested in reading that.

On the screen you should be seeing a link to that report. What I'm going to say are my personal thoughts not as representative of the IETF or S‑SAC or anything like that.

Let's start with basics. I want to look at how things used to work, how things work very briefly and talk about what changed. So DNS resolution without DoH, browser, for example, and it could be any application, but we'll talk about a browser here. Wants to go to the intgovforum web page and needs the IP address.

The request goes to a service on the user's computer which we call a stub resolver, usually part of the operating system. But it doesn't have to be. It's always been the case that the application could do this itself. Most didn't. Most used the stub resolver.

That service contacts something called a recursive resolver that runs around the internet, collects the information and returns the result, what the IP address is. The recursive resolver is usually configured in the user's computer by the internet service provider or the enterprise that the user is within. But it doesn't have to be.

The user can change the configuration and applications have always been able to make a choice of recursive resolvers. They generally haven't. Usually this is the ISP's resolver.

The recursive resolver does its work. There is a defined protocol for how that works and it returns the internet protocol address for It should be spelled correctly, but it is not.

The communication between the user's computer and the recursive resolver is over UDP or TCP which have existed for years and that's not encrypted.

When we go to DoH, same thing. The browser wants, needs the IP address. It goes to the service on the user's computer which can be a stub resolver or built into the browser.

That service contacts a known recursive resolver. The recursive resolver finds the IP address. There is no change in any of that.

The communication between the user's computer and the recursive resolver is over HTTPS, encrypted HTTP encrypted by TLS and it is encrypted. So it is immune to being sniffed, snooped on by somebody that's monitoring internet traffic.

So what's changed? What hasn't changed? The underlying DNS request and response doesn't change. The protocol is the same. The mechanism for doing the resolution is the same. It is the data transfer protocol, the pipe changes. The pipe over which the data is sent is now encrypted. The stub resolver is still there and it can support DoH.

Over time, we are going to see more stub resolvers supporting DoH in the different operating systems. The browser can still use the stub resolver. The browser could have always done this itself without using the stub resolver even before DoH. None of that has changed. The only change that the protocol does is gives us encryption.

If not much has changed why are we here and discussing this? It's a question of implementation and deployment rather than protocol.

Browsers and other apps have generally not done their own DNS resolution. They have used the stub because that was the convenient way to do it.

DoH makes roll your own more attractive for the browsers because DoH uses HTTPS. The browsers already know how to use HTTPS, so they can build it into their programs where they already have support for that. They might want to because DoH is new and many of the recursive resolvers that the stub is going to connect to lack support for it.

Without discovery of whether DoH is supported or not there is no way to know whether it is without trying it. You make a DNS request and it fails. That wastes time. For browsers, they differentiate themselves partly based on speed. Speed is very important. Even a small number of milliseconds makes a difference in the user perception of how well the browser works.

Now, the reason this was put in was for privacy issues. You can't snoop on the requests being made. There is always the issue that DNS information is public information. There is no reason that it needs to be private.

But the question is that the pattern of queries that you make is where the privacy concerns come in. The data isn't private, but the fact that you are looking for that data is the privacy issue. The problem also is introducing that privacy issue raises a lot of other privacy issues.


I'll also point out DoH is one piece of the DNS privacy solution that's being developed in the IETF. There are other protocol changes, other operational changes that are being recommended to increase privacy as well.

So what are the issues that come up? Having applications choose the resolver changes things. Who decides which resolver to trust? Previously you used whatever your ISP came in. Some people say you can't trust your ISP but you can trust other companies who put out privacy statements and assurances and that sort of thing. That's a debate. Who gets to make that decision?

Who gets the information about the queries which can be very important information that can be monetized and used for advertising, can be used for a lot of other purposes, and that can be requested by governmental entities perhaps with warrants and the sort. So who get that information?

Where can the filtering be done? We'll get to that on the next slide. What happens when different applications choose different resolvers.

Split resolution like on a VPN and some things are resolved through the VPN and some are resolved elsewhere. If a browser is contacting the same resolver, how is that handled? We'll see some of those.

Encrypted DNS is here. It is expanding. The IETF produced a best current practice document a few years ago after the Snowden situation came out. That pervasive monitoring is an attack. It is indistinguishable from an attack on the internet, so we have to consider it one and shut it down.

One way we are shutting it down is by recommending increased encryption. We are seeing that rolled out.

So we are going to see DNS over QUIC, being a new transport protocol being developed. We have to figure out how to do what we have been doing with encrypted DNS coming.

Again, here is the SSAC document, the implications of DNS over DNS protocols published in March.

One of the things that will tie into this panel discussion is it looks at issues from the various stakeholder points of view. Some of the stakeholders it calls out are entities like parents, schools, libraries and the sort interested in using DNS‑based blocking of objectionable content, for instance, to keep pornography away from children and that sort of thing.

Corporations, municipalities and that sort of thing worried about network control and management as well as the inappropriate content for work.

ISPs are concerned about doing network management and the ability to comply with government regulations that require them to do filtering which they are currently doing through DNS. If we are not using their resolvers they have no control of that. They have to find a different way.

Protesters and activists concerned with privacy and avoidance of tracking and retaliation by government and other entities are concerned about this.

We'll hear a discussion of those issues in this panel. And I believe I'm done.

>> BRENDEN KUERBIS: Perfect. Thank you, Barry, for that helpful background information.

Next we'll turn to Andrei Robachevsky, senior director of technical programs at the Internet Society. Andrei?

>> ANDREI ROBACHEVSKY: Hello, everyone. Let me put my only slide to share and here we go.

I have to say up front that the internet society doesn't have an official position on DoH. Those opinions are my own. But we need more developments in this space and appreciate the value DoH can bring to security and privacy.

At the same time we understand in some deployments there may be operational challenges for ISPs. Before I cut to the meat of DoH let me explain a bit where we are coming from to add a bit of context.

Recently the Internet Society launched a so‑called internet impact assessment toolkit. That's what you see on the screen. A tool aimed at helping ourselves ‑‑ policy makers, internet advocates to assess various developments from regulatory proposals to technological evolution like the one we are discussing here today. When developing this framework with questions, what makes the internet the internet? What defines its success and what needs to be preserved.

There have been several technology inventions that started the successful trajectory like packet switching or the architecture of the module, building blocks that enabled innovation at the edge without the need to coordinate or ask permission from underlying networks.

Or the fact that technology is a general purpose meaning it is not tailored to a specific application but can support all of them. And the internet owes its success not only to the technology but also to the way it operates and evolves. The way independent networks interconnect and operate forming high performance resilient infrastructure without the grand plan, designed blueprint or operations center.

The way the building blocks are being designed and deployed based on wide community participation needs of users and benefits it brings.

This is what we at the Internet Society call the internet way of networking. This is the starting point of our analysis of DoH, its benefits and implications.

As I already said, DoH is a great billing block that can improve privacy of users, but as with any power tool there are case where is the benefits are not as clear or trade‑offs become significant and need to be considered.

The cases are mostly confined to particular deployment model. I have to say up front the centralized deployment of DoH especially when it is deployed by default.

Let me look at some of the facets of this issue. Take decentralized management for example. This is one of the critical properties on the slide.

The network can decide and optimize designed based on local conditions via the interconnection internal to apology, basic services it offers to users or the policy.

This is the foundation of the agility and resilience of the internet. The point is that the benefits of DoH depend on the particular risk assessment and the threat model which are not the same across the board. Protection of the channel between the trusted resolver and the client is a clear benefit especially when DNS SAC is deployed. Privacy aspects are nuanced.

For example, using the centralized DoH model brings privacy benefits with regard to the potential expense of disclosing the information to a third party or maybe in a different jurisdiction with different privacy requirements.

For an ISP on enterprise network the choice of using a proxy resolver may not be susceptible. It could be additional service or so policy requirements the ISP provides to users.

As a result, the policy imposed may be in conflict be the local policy of the user or an ISP. Jurisdiction ‑‑ this order of magnitude or corresponding policies. Centralized DoH changes the number to less than a dozen. This is a significant shift that we need to analyze further.

Ideally the user has the ultimate choice. Which internet or DNS provider to choose but if the user doesn't care maybe the ISP is the next in line. If ISP has no preference then I think centralized DoH is a viable solution.

When it comes to technology building blocks, a DoH is a great case in point because DoH is based on HTPS which is built from building blocks like HTTP, TLS, IEP, so from that point of view it's a perfect example how this critical property can manifest itself.

When it comes to the way the DoH is used, deployment model things with less clear. The centralized model may set a trend of reducing the number of cooperating players in the provisioning of DNS and therefore reducing incentive for wide collaboration.

The DoH may move into application back end protocol which reuses is building blocks but is essentially proprietary. Since only agreement with a few parties is required.

We may end up in a situation of embrace and extent leading to what happened before. Finally, this trend can threaten the very DNS as a global and consistent naming system. There is a potential of erosion of the global and consistent mapping of names to addresses for the DNS into application of service provider specific world governance. The governance of the space could change dramatically putting control in the hands of vendors instead of the technical community.

Now, I appreciate there is a lot of speculation in presenting these scenarios. They are risks, not the current state of affairs. Some good is under way to put the safeguards for not allowing this to happen.

One of the examples is Mozilla that allows ISP signal whether deployment of DoH is acceptable.

Google Chrome uses a procedure that tasks the local environment suggesting using DoH. Barry explained a very important work by the ITF and working group that allows discovery and selection of DNS resolvers in a variety of environments. I think we need to monitor the space and make sure DoH continues to bring benefits and continues to be involved in the healthy way. Thank you.

>> BRENDEN KUERBIS: Thank you, Andrei. Next we'll hear from Olga Makarova. Olga?

>> OLGA MAKAROVA: Yes. Just a moment. Okay. Thank you. The main difference between carriers and providers is all carriers have to act under the system but all providers do not. DoH has a lot in common with services. DoH can be provided by either party on any level of any carrier to any users anywhere in the world.

Any new global service significantly heightens tension between the system and ‑‑ the system does not provide for the transition to cross border relations. Alas, no one in the world is ready for this system. Thus, no service but a reckless deployment of services may be the main reason why the variables can be varied under the system. The GDPR did not go beyond the Westphalian system. China for example must adopt a Chinese ‑‑ to protect Chinese users.

But it seems that DoH is not so much about the global service as about a new round in the net neutrality history. Its main goal and prize are not just protection of personal data. This looks like a great and very smart marketing ploy by both providers. In an attempt to attract ISP customers and market share for some of the internet services.

Let's remember such cases ‑‑ internet freedom. Let's pretend Netflix has become a DoH provider, for example, for customers. Will customers be able to have the reasonable network management to DoH network services under the law? The service quality if it thinks Netflix DoH service is making its network unstable.

It seems we will see a lot of very interesting new battles within DoH providers and ISPs in the U.S. soon. It is a surprise the contrast of one over the other with provider networks. This is very useful document and I like to say many thanks to all the authors.

So we are waiting for future development in the U.S. to gain the experience we need. About the DoH deployment in our region, we highlight global and local. As you know, our state is a part of the Westphalian system. As such, global DoH vendors will have to comply with local laws. Compliance with local laws means we need to agree with the state on the rules. It is not so easy.

Any attempt to enter our market bypassing the local law can lead to the blocking of service by the state in an attempt to block service even if it succeeds by half greatly reduced the chance of providers for market share.

The lack of Russian language support from global DoH providers will limit the use, potential interest in these services from a wide range of our customers. Therefore, we see no reason to get our market share by global DoH vendors in the time frame. We look forward to buying time to finally ‑‑ significant increase in the internet traffic due to the pandemic.

At the same time, we will get an opportunity to study the most interesting cases for example in the new year. We believe that we need to be more attentive to details.

For example, consumption in mobile. We tend to believe that deploying not DoH will be for us. We plan to return to this issue after the pandemic.

In August, we conducted an experiment with DoT in the European part of Russia. 5 million mobile consumers could use our dot servers at the same time. The share of dot requests was 13%. The experiment showed the request traffic doubled. The CPU load tripled. This was not a surprise. The server had to look for data and act as traffic encryption. The experiment showed we need to change the infrastructure of DNS resolvers for DoT. Now, each server works independently from each other. Requests are evenly distributed among all web.

Most likely, the main reason for doubling the request traffic and tripling the CPU load was the fact that the traffic from the devices was evenly distributed among the service and the connection was re‑established.

We need to make a separate attempt that will terminate on themselves and as far as possible hold it for some times for reuse within the customer's presence.

We understand that any attempt to stop technology is always wrong. But deployment of any service might be fatal to stable internet.

>> BRENDEN KUERBIS: Thank you, Olga. I appreciate that background on the technical challenges of DoH and some of the challenges of over‑the‑top services and the interaction with the state.

So now we are going to move on to Amod Malviya, a cofounder of the Indian company Udan.

>> AMOD MALVIYA: Thanks. Hi, everyone. I must clarify that imam speaking in an individual capacity as a person who spent his career in this space. So that's where I would be approaching the discussion from.

I feel there are two principles of the internet that I want to bring out to the forefront of this discussion.

Andrei already touched upon one of them which is decentralization. The decentralized approach to the internet's architecture has given us resiliency and longevity to the internet.

Whichever way we think about the future or the internet's governing protocols, we need to think about how we continue to maintain that spirit.

The second that I want to bring out about the internet is obstructions that have largely allowed different operating layers. You've got the network layers, the application layer and things in between.

DNS has been particularly contentious because of the fact that it's very leaky obstruction. That fact will become, you know, important in a few minutes. What that has meant is it simultaneously is something that's needed at the infrastructure layer, but it is also something that immediately reveals what the network layer is being used for.

I mean this not just from privacy concerns. I also mean this from just, you know, market operating principles perspective.

The world has changed significantly in the past 20 years. Two decades back we had the standardized desk top operating systems and everything. Those were the layers that were mediating the network layer and the application layer. The obstruction that got created here became helpful in development and that led to its own success creating a lot of economic value for countries around the world.

We need to think about technology from the perspective of as an economic value creation first which is where the neutrality of technology that Andrei talked about earlier becomes particularly important. We need to approach all of the discussion we need to be having first from the perspective of how do we structure the internet in a way that it continues to be resilient, continues to have a goal of decentralization and continues to make data obstructions.

Coming to the change that's happened in the last two decades the world has shifted to the smartphone era where the applications are in a very gated fashion by organizations that have absolutely no responsibility towards the internet principles.

Obviously today they can be great internet netizens, but from an architecture perspective we need to make decisions which help retain these principles instead of relying on the benevolence of organizations.

DNS has moved to the control of the operating system in a way that the user is lesser in control of things. Yes, I agree that users rarely use these settings but it is less the frequent of when it is used. It is far more important to understand where the power of control lies between the network and the application layer.

Today we have technologies like web assembly coming in which essentially is making browsers almost the operating system of the internet. In this future world, bearing in mind this possibility how do we make sure DNS doesn't shift completely off the domain of the browser which is where the applications are being developed. If I as an app developer want to retain control of how my app reaches it, it actually creates centralization.

In the known area there is a default centralization that's happening. To counter it we need to make sure the infrastructure services exist in the upper layers where the application development is happening which is where something like DoH fits in very nicely. Because I strongly suspect that as things evolve over time the smartphone operating systems will be more and more controlling about the protocols that can be used and may not be used. At a minimum they would start creating warnings that if you as an application developer are using anything more than HTTPS you need to gain additional permission from the user, which is why it's very important that at the HTTPS layer we have a lot of controls of critical services even if the obstruction remains leaky in the sense that both layers, we need to make sure there is some scope for the application to play around with it. Otherwise we are essentially concluding in a very firm way that this is a network layer thing which leads to more centralization because of the increased prevalence of those systems. That's the point I wanted to talk about.

Thank you.

>> JYOTI PANDAY: Thanks, Amod. Brenden has dropped off. I think he's facing network issues. That's a really interesting perspective. Amod, we'll come back for questions on this.

Next is Joey. Joey, do you want to take this forward?

>> JOEY SALAZAR: Yes. One moment. Thank you, everybody. Representing article 19 and part of civil society, our position is that DoH is key not only to privacy and censorship circumvention but is a key issue. We think of the way different types of censorship may affect their way to express themselves but not to receive information or the other way around. That's why we believe that censorship remains a key issue concerning freedom of expression and access to information. Especially considering that the DNS was designed unencrypted in order to preserve network and system privileges and control over the DNS traffic they manage. Regulating bodies have consistently deployed different techniques over the years in order to filter, control, and regulate internet traffic through the DNS.

Although mechanisms are being developed in order to inform users when and why content is blocked through the DNS and whether this content isn't available or if it has been censored or blocked heavy oppressions are held in place through manipulation of encrypted DNS data.

That's why encryption of the DNS data not only protects users privacy and anonymity but is a technical advance necessary in order to circumvent censorship and protect user's fundamental rights of freedom of expression and rights to freedom of information.

Here's the thing. As with many new technologies and especially new technologies that pose significant changes in the control and power in the systems they represent, there are lots of concerns around the adoption of DoH particularly regarding limitations for the implementation and deployment, applications on data protection and regulatory frameworks and of course the fundamental concern of centralization and the consolidation of power it could pose.

We believe these are all valid concerns. Although we believe each of those concerns are valid and of course there are more, we also think they can be addressed by implementing DoH with considerations.

Here's where we think a multi stakeholder approach is vital in order to be able to first define clear mechanisms for implementation, for measurement and deployment and then for the access to content through strong legal protections that enabled users' freedom of expression and freedom of access to information and that protect their data across different regulatory frameworks.

We think that by working together towards this goal, we will also in turn tackle the last issue I mentioned, consolidation. Since by working together to resolve those things we'll enable providers to develop a list of services and platforms both in browsers and operating systems which, in turn, would make DoH less centralized and would help address the concern of the consolidated power.

This is pretty much our perspective. We really believe as long as there is ‑‑ similar to what Barry said at the beginning, as long as there are safeguards mechanisms to understand the points of risk under key human rights and policy considerations article 19 and myself are of opinion that DoH is an improvement over the current system and a step towards a more private and safe internet for all. Thank you.

>> BRENDEN KUERBIS: Great. Thank you, Joey. I had a few issues of connection, but I seem to be back on via my mobile device now.

Okay. So since we have had so much conversation and heard so many things about centralization concerns we have Alissa Starzak from a DoH provider.

>> ALISSA STARZAK: Thanks, Brenden. I'm head of public policy at Cloud Flare which runs a global network for reliability services online. More than 25 million domains use our services in more than 200 locations and in more than a hundred countries.

1.1.1 is a server with privacy in mind. The goal was give people an opportunity to choose control over DNS information. The things that the resolver included were things like privacy by demand including support not just for DoH and dot but query minimization and aggressive negative answers and not providing EDNS header information in queries.

We also wanted to be transparent about what we did with information which we thought was lacking in the industry. We wanted to make sure we were held accountable to standards we brought into place. We put out information about what we collected and how we used it. We brought in a third party audit firm to talk about our commitments and make sure we were standing by them.

As I mentioned, the idea for us in putting this resolver out and putting the recursive resolver out was about choice which I think was lacking in this area. This is something we should talk about a lot. One of the things that comes up in a lot of debates is the question of defaults. What is the standard that people use as the default?

I think what we often don't think about is the longstanding default has been that a lot of people have access to information about your browsing history. That's something users should have a choice to determine. Is that the right choice for them? It should be something that users have the information to evaluate and information about exactly how their information is used is relevant to it. Our sense had been that it was lacking.

As I mentioned we made commitments about our use of the resolver data and said, for example, we wouldn't share client access or other personal data. The upside is they would use only what's asked and not who is asking. We made commitments about logs which didn't include personal data that they would be purged within 25 hours.

We made a point of saying we wouldn't sell data or use it for targeting ads. The idea was really to put a resolver together with a set of standards on a bunch of issues people didn't talk about it.

I want to go back to that. If you're like me on the policy side rather than the technical side you never thought about the information that might be available to others when you browse online.

If someone were designed the internet now saying they could see what people are browsing by virtue of the DNS data would be probably a nonstarter. I think the users of the internet it was something they never thought about. There are questions of default. You have to appreciate the default we have had. It's not just a question of where we go but what we have had and what's acceptable generally. For us launching a privacy oriented resolver put light on that and helped push the conversation we are having about who has access to DNS data and who has control over it including access to user information and for what purpose. We think those are incredible conversations to be had.

There were references to the partnership with Mozilla as well.

After we launched the public resolver we partnered with them who shared our view about the privacy of DNS data. We are now part of their trusted recursive resolver program designed to provide a minimum set of policy standards recursive resolver must satisfy. We are not the only member of that program, but we are one.

I know we are a little behind, so I'll stop there so we can turn to questions.

>> BRENDEN KUERBIS: Thank you very much for that very informative presentation. So we have reached ‑‑ we have background. Different panelist perspectives. We have reached the portion of the workshop where we'll have basically an open discussion. It was originally a roundtable. It's challenging in the online setting. But we are going to go for it and see how this turns out. We have organized questions in the three areas ‑‑ human rights, markets, and governance.

I'm going to go ahead and pose questions ‑‑ three questions. I would invite the panelists to go ahead and just jump in to the conversation. I'll have to ask for you to kind of help move the conversation along since I have a limited screen here. I can't see people's faces. I can't see everybody's face. So I'm not going to be able to tell if you want to get into the conversation.

Here we go. Human rights and the demand for privacy. Privacy is trending upward in protocols. We see the rapid adoption of HTTPS, encrypted DNS development. We see it in applications and the growth of security end to end chat, messaging and in policies with extraterritorial reach governing data privacy and access like GDPR and the cloud act one and two. The encrypted DNS genie is out of the bottle. But DNS message data is monitored extensively by network operators, network security services, and enterprises to secure infrastructure, filter malicious content and protect user.

Should DNS query data remain a lever by which organizational and public policy is implemented? Related, if actors gain or lose power to use the DNS data as a tool for security and policy enforcement are there alternatives? And is governing DoH to meet requirements of national DNS blocking regimes the least invasive method in the face of other options like laws restricting DoH entirely which we have seen or requiring technologies like exceptional access.

>> JOEY SALAZAR: I think those are very interesting questions. From my perspective mostly as an engineer we have exploited the vulnerability in the networks and particularly in the DNS, we have exploited it for too long. Think that needs to change. The concerns that come around regarding the control and the administrative privileges, it's kind of a trade‑off. But I think it will all advance together as a whole.

As the protocol matures, so does the tools and mechanisms that are used around it as well.

So there definitely needs to remain some administrative and management privileges at some point but the DNS system needs to become stronger. The real benefits of privacy and security measures should not be endangered or postponed just because of what we perceive is a basis of potential threats to how things currently are. What do you think?

>> BARRY LEIBA: This is Barry Leiba. Filtering things using DNS for what some people would call protection and others call censorship has always been fragile. You can get around it and I think it is ill advised for governments to try to legislate how software should work. We need to look at network management, policy issues, reporting issues and those sorts of things and figure out the right ways to do those things that are not so fragile and don't interfere with how the internet is deployed.

>> JOEY SALAZAR: Hopefully also bringing those considerations to the table and deployments will also help raise the bar on what has been acceptable to be controlled and blocked so far and what doesn't need to be and what shouldn't.

>> ANDREI ROBACHEVSKY: If I can jump in, Andrei here. While again these are the two things we are considering DoH as a protocol. From my perspective it's undisputed that it has a lot of value. It protects the privacy, the last mile that hasn't been protected so far between the client and the user.

But I think DoH ‑‑ and when we are discussing DoH and deployment model particularly we are actually discussing why the issue is not related to DoH, right? Centralization of DNS has happened before. Public DNS resolvers existed for years. Many ISPs are outsourcing this service to public DNS resolvers and that's a fact.

In fact, that's another trade‑off. Proper deployment of centralized DNS can make DNS better. For instance, Cloudflare, what Alissa mentioned, implements good measures like creating minimization or DNS that can push those technologies very quickly.

Now, that's the positive side. There was also a down side because Cloudflare has a policy even if the policy is not oh to have any policy.

That's a concern where local policy may clash with the policy imposed by a trusted resolver. Another thing is fragmentation. Again, fragmentation happening in DNS space not because of DoH specifically but some implementation of DNS.

I heard Netflix implements their own DNS resolution. That's not DoH. It's just DNS. That's another issue not per se done by DoH.

DoH brings all this together. It's concentrated in DoH while the issues existed and continued to exist regardless of whether DoH was deployed or not.

>> OLGA MAKAROVA: Okay. We need to decide in the system or a little outside it. If we are a little outside it, we should or could wait, for example, changes GDPR to protect the personal data of users. The Russian GDPR and others. In this case, I have some doubts.

If we are within the system we must examine the experience of each country separately.

>> ALISSA STARZAK: Some interesting questions in privacy come up in the chat. In the GDPR context we are seeing a question of who has access to data in a way that's related to sovereignty.

For example, if you are thinking about data that looks like DNS or browsing data and it is unencrypted is that, itself, a potential challenge under GDPR? I would flip the question around to some of the questions in the chat which is to say that if you have an obligation to protect information that might be private information so that it is sovereign in a way, so there is an element of sovereignty to many privacy laws what is the responsibility for entities who do not protect the information which means it can be sniffed on a wire by other entities.

It's not just whether they protect the information which is an element of privacy law but a question of what external protections they have from other people looking at the data. One of the challenges referenced in the chat, we see something we see a lot in the post Schrems world but to make sure excess parties don't have things in their possession. What does it look like in the context of DNS, for the privacy issues Olga raised. There is a set of issues that tie privacy and sovereignty together in part because often what you have are governments that want to make sure other governments don't have access to their citizens' data.

To me, the questions of sovereignty and privacy in many ways go together. What you are seeing in the GDPR or Europe context is a recognition in the post Snowden world that maybe other people shouldn't have access to their data and other governments. I would challenge those who question that the U.S. component of that. To also ask why they are not applying it to European providers who have an obligation under GDPR to make sure there isn't unauthorized access which includes from my vantage point sniffing. I think these issues are tied together in interesting ways from a privacy angle. They raise complicated questions about what laws apply to certain kinds of data and what it means.

But they are ones we can't suggest all fall on one side of the ledger.

>> AMOD MALVIYA: Just one small comment from me. I think it is best for us to sort of read the layering separately from policy enforcement. DNS has their own layer. You know, in this stack to actually be used for policy enforcement. Obviously there are legitimate reasons for them to be doing it. But it needs to be ‑‑ if the door of DNS gets closed to enforce some of those things that data is always available. We shouldn't conclude prematurely that it is a DNS or a DoH concern for these policy enforcement pieces. Absolutely not. We should be making these decisions primarily on the merit of the technical principles. I think governments always have a ton of levers. But to solve for DNS in the correct way, there is not so many levers available. We should be solving for that first and leave the policy solutioning for a different layer in the internet stack.

>> BRENDEN KUERBIS: Others? I would just add to Amod's comment that some of the most recent research has shown that DNS‑based censorship is still possible on encrypted DNS traffic. Network operators and others that are currently ‑‑ may need to look at encrypted DNS traffic. So next in about ‑‑ yeah. I think Joey brings up a good question here. Joey?

>> JOEY SALAZAR: I didn't want to put anybody on the spot. I heard information about a Cloud Act and the Earn It act being discussed in the states. I was wondering how those interact.

>> ALISSA STARZAK: I'm not sure those are in the DoH context. The cloud act, for folks not aware of the various pieces, it is intentionally ‑‑ intended to get at the question of cross‑border access to data from a law enforcement angle. So for those who don't follow the issue, the idea is now that we have cloud services data can be stored anywhere. There is a well-known case in the U.S. that went up to the Supreme Court before getting dismissed because of the cloud act where Microsoft had information stored in Ireland and the question was whether the U.S. government could access it. The cloud act resolved that question by saying the U.S. government could access certain data but by providing rights for foreign governments.

For example, the U.S. can enter into foreign agreements with ‑‑ they have done this with the UK which is to say they can then ask for information from UK providers as well and there is reciprocity in how to access information that doesn't depend on the location of the data.

I'm not sure that's necessarily relevant to DoH. The question is if you haven't entered into one of those arrangements GDPR is a blocking statute so you have a conflict of law.

I think it does get into the question of sovereignty though which is who should be entitled to have access to the information? That is ‑‑ you were saying U.S. government. You shouldn't have access to information about Europeans unless we say it's okay. Encryption is an important part of the piece because you can't potentially restrict U.S. government from getting access if the information can be potentially sniffed.

Thinking of how the pieces fit together is interesting.

Earn it is intermediate liability, an exception to section 230 which is another conversation. I don't necessarily see how it relates to DoH. But happy to expand that conversation out.

>> BRENDEN KUERBIS: Thank you for the clarification, Alissa.

Let's move on into technological and market change questions. There are shifts occurring where DNS query response functions reside. We see the flattening of the application OS layer. We see movement of network functions like DNS management once performed by the ISP to cloud service providers in many cases. We hear concerns about concentration of DoH resolution in, I believe a dozen providers were thrown out.

Where is the market for providing DNS query response, plain or encrypted activity concentrated now? Is it in ISPs or the cloud environment? How tightly integrated is DNS in different types of networks? For instance, mobile. And for what reasons? What does the dominant role of apps on the mobile platforms mean for DoH potentially?

>> AMOD MALVIYA: Let me go first on that. It is related to the point I was raising earlier. I think it is important to understand where the computers are actually headed toward. Far more developers develop applications for smartphones than for, you know, the earlier kind of internet model we had seen.

As we get into more control of the platforms being demonstrated for the right reasons. Say for example Apple says you can't change the DNS setting as a user. So the only way to do it is by installing applications. Remember, if it requires far more user intervention. You know, than what was needed in the earlier operating system where you need to change settings, install DNS modification or VPN app. Users are less likely to actually be doing that more and more which increases the chance of centralization.

The point is as you make the world headed in this direction you will leave open some doors at least for DNS possibilities to exist outside of this tightly controlled gate of the smartphone vendors or do we want to just completely close the door and leaf no options whatsoever.

For me, it is about duty, how frequently do users change the settings? I saw one question from Mark saying that configuring settings in the operating system reduces user ‑‑ absolutely, it does. But do we want to allow this for some future form of doh ‑‑ DNS to be emerging in the browser as a complete machine that we are probably headed towards.

We need to make sure our choices today are dictated by some of the possibilities of where the world is headed than just based on what we have seen in the immediate past.

Tomorrow there is a high likelihood of the browsers actually emerging as proper independent virtual machines. There is already a lot of work happening in that direction with things like that, et cetera. We need to make sure some of the controls are available in that layer instead of closing that door completely.

>> ALISSA STARZAK: I want to jump in here as well. One of the interesting questions to me and, again, going back to the commentary I had about our recursive resolver, I think that we have to do a better job talking about exactly what happens in this space. I think what's happened often to date is that people don't have any understanding of exactly how information flows, where their DNS information is going and how it is used. To me when you get into the application space that's compounded more because imagine a normal user with a cell phone where they could have lots of different data going a lot of different directions. They don't necessarily have a way to think through what that means.

Thinking about what we can do in our world of people who can translate that information, think about how users can get more information, be more transparent about how those pieces work is important.

There's been traditionally a huge gap between the standard end user and someone who is in the technical space. One thing we can do that would assist in that part is to help bridge the technical gap, explain what's happening, where it is happening, who has access to what. There is a huge benefit potentially down the road on transparency.

I want to go back to the chat. It's not relevant to your question, Brenden, so I won't do it now. I would like to talk about some surveillance questions in the chat.

>> BRENDEN KUERBIS: Let's hit those in the governance section coming up soon. Thank you. I agree there needs to be a nuanced understanding of the market concentration question in general. In reality it consists of multiple markets. Whether it's software at the stub resolver and how many queries of different types are happening with that software and the number of firms providing that software or the number of firms operating resolver operators and services of different types and how many responses their market share.

As well as the number of firms offering can complementary services that rely on DNS query data. We need to understand the interaction between those three markets to get a better grasp on market concentration questions.

>> JOEY SALAZAR: There is a good opportunity now for increased transparency and accountability for people providing services. I think that comes together with some of the things Alissa was saying of helping inform people, helping them make informed decisions for them to know where it is happening. It presents the opportunity for transparency and accountability for people providing those services as well.

>> ANDREI ROBACHEVSKY: If I can jump in I would like to talk about what Amod said about closing the doors. For me, any restriction on the use of technology be it by sort of browser vendors dictating something by default or the government blocking some of the technology is a bad thing.

One size rarely fits all. For instance, there is a possibility with centralized deployment certain avenues will be locked and we can get locked into a browser vertical and therefore all the world by Ed working group, no one can access this. I know there is a lot of work in open software development space to enable resolvers software to support DoH but you need the discovery mechanism, the certain openness that user or operating system on application can decide and make informed decisions based on local conditions.

I would like to stress this point. I think we need to ensure especially this early phase of the deployment. Let's be honest. DoH is relatively a new, young protocol. So different deployment models can compete and be tried out.

>> BRENDEN KUERBIS: Thank you, Andrei. If there aren't any other panelists who want to chime in we could move on to our next area of focus ‑‑ the governance challenges and the interplay intentions between organizational, national, and extraterritorial policy influence.

Alissa mentioned earlier in her remarks of the contractual arrangements. One question is what kind of arrangements between DoH actors are emerging and is there variability in how they are implemented. Who benefits and why?

I want to follow up a little bit on the ADD work, adaptive DNS discovery work occurring at the ITF. How does the design work hinder user, operator or national policy choices and who potentially benefits from that?

Also, are there potential long‑term effects of the shifts ‑‑ this was mentioned by Andrei earlier ‑‑ in the production of encrypted DNS. What are they and are they risks we need to be concerned about and to what extent?

Also, I would like to circle back. Alissa wanted to get back into some of the trans national privacy issues. So maybe we'll start with Alissa and move on to the three questions.

>> ALISSA STARZAK: Since you started from the back I will start there as well ‑‑ or the last for the end. I wanted to touch on that question that came up in the chat on GDPR and section 702 and a bunch of pieces. I think it's really relevant to the DoH discussion.

So one of the questions that came up in chat is under GDPR parlance is recursive resolver a processor or a controller? I think one of the interesting questions about DoH is when the information is not encrypted the information is open for sniffing.

In that same question, I guess you can put it back to every single ‑‑ it's not a U.S. question anymore. It's not a U.S. company question anymore. If you believe that information should be private, what protections does any entity have, any telco have, for example, to make sure someone is not sniffing that information? Does it matter whether it's legal process which is the sort of authorities referenced in the chat or whether someone can get access without legal process because it is not encrypted. We don't talk about those enough when we get into the DoH. What the DoH piece means is access to the data is actually harder to get, not easier. Regardless of who the company is. There are fewer people who have access to it.

I think we sort of misconstrued some of the privacy debates. We talk about them from a U.S. company standpoint because of access to information but fail to recognize when information is encrypted it is available to any intelligence service sniffing the wire. It's not just the U.S. It's anyone who might be on the wire.

What I would say to folks in the chat is what do you do to make sure U.S. intelligence agencies don't have access to the data if you are concerned about the DNS data potentially transmitting the data not encrypted. I would pose that back.

On the contractual side one of the big pieces for us is something I referenced in my comments at the beginning which is that I think we can actually do a lot contractually with transparency and privacy. We can make comments, for example, in a contractual way that talk about exactly what we are doing with data. Is the data used for advertising sort of a core piece? How is the data kept? Is the data retained? Do you actually eliminate the personal data which is what we do on the DNS query side. Thinking of what you can put out there from a transparency side gives people insight into how the data is used.

Because it is contractual, it is something that as long as you make it trans parent is something people can use to evaluate services

To me there is a huge potential role in the contractual basis on the transparency side. It enables you to have a discussion about what's happening with the data and it is potentially enforceable. The reason the Mozilla contractual components are interesting is they had a set of minimum requirements that were then public so people knew how the data was being used and what was happening to it.

As Andrei said this is young. We are still at early deployment stage, not that far along in these discussions. I think there is an interesting opportunity on both the transparency and privacy sides in those contractual arrangements.

>> BRENDEN KUERBIS: Thank you. Can I follow up? Would you agree that there is the opportunity for a lot of variability in DoH resolver services? I bring it up given the diversity of filtering that was brought up very early on. One can see the emergence of competition in content filtering. My question is, you know, can global DoH providers support that activity?

>> ALISSA STARZAK: Absolutely. Those are questions of demand. You want to make sure there is diversity in supply of DNS providers. Sort of avoiding centralization. There are larger questions. The reality is if the demand is there the product will develop. You can have filtering with the DoH resolver. It just depends on what you are seeking to do in that space.

So we for example have filtered resolvers that are compatible with DoH.

>> BRENDEN KUERBIS: Great. The next question is how does encrypted DNS protocol design work support or hinder user operator or national policy choices. I guess I wanted to get into the ADD work in that are we ‑‑ maybe Barry wants to jump in here. Are we moving toward standardizing what they call same provider auto update as the default behavior in applications? And does that mean that ISPs and network operators and national jurisdictions will retain potentially more control over DNS resolution and data?

>> BARRY LEIBA: Hmm. I think the answer to the last question is no. I don't think the trend is to give governments more or less control. The trend is to provide more options.

The ADD working group is just getting started on adopting documents and deciding what it is going to standardize. Anything that you are seeing now is too early to say what's going to come out of the working group as a standard. So the flexibility is what we are looking for. Can you find the information you need in a flexible way? How you use it is a deployment policy. Clearly government regulations and public policy will influence provider policies.

I guess that's the best I can say on that.

>> BRENDEN KUERBIS: Thank you. That was very helpful. Anyone else want to chime in?

>> ANDREI ROBACHEVSKY: I can just repeat myself. I think that's important work. That's the building block, the founding principle of the internet. Whether the building blocks are used or not and in what circumstances.

The thing is someone said no one can design the internet. That's very true. Even the IETF can't design the internet. It can design certain building blocks but who could have thought that DNS can be used as a policy tool ‑‑ well, it wasn't designed to have policy tools at all, right?

So that's one thing. Another is to Alissa's point, I think while the internet society is an advocate of encryption, encryption of traffic between the client and DNS resolver is a must.

If you deploy DNS your last mile is ‑‑ that's insane. On a wireless network you connect to a secure wireless network although it's like that's my access point. Why do I need to encrypt my traffic? That's very important. Other issues are at play. The trade‑offs are sometimes ‑‑ I think it is difficult to say a definite answer, that's the way it should go. Circumstances vary and deployment models also vary.

>> BRENDEN KUERBIS: Great. Okay. So we are at ten minutes left in the workshop. My colleague has been monitoring the Q&A. I thought maybe we'd take a couple of questions from the audience. I realize we have been taking some earlier throughout, but maybe there are a couple more.

>> BARRY LEIBA: Brenden, can I interject first? DNS sec was mentioned particularly by Andrei. We often get the question that with DoH do you need DNS SAC. The two things solve different problems.

DoH is intended to solve the privacy issue and the confidentiality of the queries. DNS sec is addressing the integrity of the response data. So, yes, it is still absolutely necessary to do DNS sec even if you have DoH.

>> BRENDEN KUERBIS: Thanks for the clarification. Do you want to provide any of the questions that have come up Jyoti?

>> JYOTI PANDAY: First is if my resolver is switched from a European service to a U.S. one using DoH my personal data shifts outside of GDPR. I guess it goes back to the point Alissa touched upon. If there is something that any other panelist would like to add to that or, Alissa, do you want to clarify more on this? It seems to be coming up in the chat as well.


>> ALISSA STARZAK: Generally GDPR follows you as a person. It is a personal selection. You still retain your privacy protections. The question is what happens if a government requests it. Forget the U.S. for a minute. Take it outside of those contexts. If it goes somewhere else can the U.S. government request it and what does the provider do? This has been a big issue in the privacy space generally. Our position as a company which I think other entities provided as well is that it is essentially a conflict of law question. Because it is a conflict of law question it is not something we would provide to law enforcement. We think we would be legally prohibited from providing it in the GDPR context. If GDPR prohibits us from providing that information to a law enforcement entity we would have to go to court and evaluate that and have a court evaluate that concept of law.

I think the outstanding questions on these conflicts which encryption gets to is the question of ‑‑ goes back to the sovereignty question. What are we trying to do with the information? What does it look like? Who has access?

The other piece I would flag in that space is, again, going back to the point that I made before. If it is not encrypted why would you think those entities don't have access? We are coming from the default world where the information has been available. We are now entering a world where there is a potential for more privacy and evaluating what that should look like. That's a conversation we need to have because they are interrelated. If you have a country for example proposing to prohibit DoH why do you think they are proposing to prohibit DoH? What are they looking for? What's that relationship? How do we get transparency on those questions in the human rights context about who has access and when they have gotten it.

>> JYOTI PANDAY: Another question that's come up which is related to this point is what is the impact of DoH on law enforcement especially when they are investigating crimes. One example that's been cited is if somebody is under investigation is it possible to remove DoH protection without the user knowing? And if this is possible would it be appropriate? Would anybody want to take that on?

>> AMOD MALVIYA: I would reply to that. DoH, we should be looking in this context as the last mile protection. Disabling, unlikely. But the more centralized the DoH providers, that much more likely that the user is more easily tracked whether they are under investigation or not, that's more of the legality to it. I won't speak to that. The more important point is that DoH certainly provides last mile protection so people can't sniff out. That's an important point Alissa was making. We shouldn't think that the actions of the DoH are a secure data. An equally important concern is the more centralized DoH providers. That much more likely trackability.

>> JYOTI PANDAY: We have less than five minutes left. That's probably all the time we have for the questions if we want to leave time for the panelists to give closing statements.

>> BRENDEN KUERBIS: Great. Thank you. I appreciate that.

With that, I'll ask our panelists if they have any quick closing remarks.

>> AMOD MALVIYA: At the risk of repeating myself I'll just sort of leave the forum on this note. I think there are different layers in the internet stacks solve for different problems. Mixing policy concerns with important decisions that determine the longevity and resiliency for the future. We should prioritize things appropriately.

The first concern in thinking about protocols, we should be thinking about longevity, resilience, principles of the internet. These sectors. Once those are nailed down we can always figure out how to enforce policy. Premature optimization is the root of all evil as they say in the software engineering world. We would do good to bear that in mind.

>> JOEY SALAZAR: I would add that I think the current landscape and evolution of this protocol is presenting good opportunities in different areas. We have already spoken about transparency and accountability. Also the enforcement of meaningful user choice that will be attained through the transparency when the user is aware of the policies they are actually requiring contracts with and this type of thing. Then their user choice will be meaningfully enforced and along with other different areas is a great opportunity we need to continue to work on together.

>> ANDREI ROBACHEVSKY: I just want to add on the general level that DoH is another elephant that different parties are touching and feeling different parts of it. I think it means different things to different entities. That just underscores the importance of the dialogue we are having here and we should continue.

>> ALISSA STARZAK: I would echo that point. This is an incredibly important dialogue to have. Bubbling it up to a nontechnical audience is a really important piece as well. So I'm really glad to have the conversation today. I hope these types of conversations continue.

>> OLGA MAKAROVA: We need to learn to live in these and adapt services.

>> BRENDEN KUERBIS: Great. Any other last remarks? No? Okay. Well, with that, I think I'll echo Andrei and say the elephant is in the room. So we will be paying attention to this topic. I want to thank my panelists for providing such a lively and engaging discussion and also the audience for providing good questions and engaging throughout the discussion, too.

With that, thanks, everybody. Enjoy the rest of your IGF.


>> JOEY SALAZAR: Thank you, Brenden, for hosting.

>> OLGA MAKAROVA: Thank you.


Contact Information

United Nations
Secretariat of the Internet Governance Forum (IGF)

Villa Le Bocage
Palais des Nations,
CH-1211 Geneva 10

igf [at] un [dot] org
+41 (0) 229 173 411