View source for DNS over HTTPS – What is it, and why should you care? – WS 06 2019

20 June 2019 | 11:00-12:30  | YANGTZE 1 | [[image:Icons_live_20px.png | Video stream will follow shortly | link=DNS over HTTPS – What is it, and why should you care? – WS 06 2019]] | [[image:Icon_transcript_20px.png | Transcription | link=#Transcript]]<br />
[[Consolidated programme 2019|'''Consolidated programme 2019 overview''']]<br /><br />
[[File:Invitation to EuroDIG DoH workshop.jpg|thumb|right]]
Proposals assigned to this session: ID 123, 175 – [https://www.eurodig.org/fileadmin/user_upload/eurodig_The-Hague/statistik_proposals_all/proposals_for_2019_2018-12-04__01_final_web_IDs_ver1.pdf list of all proposals as pdf]<br /><br />

== <span class="dateline">Get involved!</span> == 
You are invited to become a member of the session Org Team! By joining an Org Team you agree to that your name and affiliation will be published at the respective wiki page of the session for transparency reasons. Please subscribe to the session [https://list.eurodig.org/mailman/listinfo/WS06_2019 '''mailing list'''] and answer the email that will be send to you requesting your confirmation of subscription.

== Session teaser ==

DNS-over-HTTPS is a new protocol that could fundamentally change the way DNS works today, providing less or more privacy depending on how it is used, disrupting censorship but also law-mandated content blocks and network security measures, shifting jurisdiction and Internet content control away from Europe, and fostering further centralization of the Internet. It affects almost any stakeholder – users, governments, civil society, ISPs, network administrators and more. Come and participate in an open discussion on what could be done to foster the positive effects while preventing the negative ones.

== Session description == 

As part of its efforts to encrypt all communications, the IETF has recently released two protocols to encrypt the flow of DNS queries between user devices and their "name servers" (resolvers): DNS-over-TLS and DNS-over-HTTPS. The latter has spurred quite some controversy, as the deployment model chosen by the first major browser to embrace it, Mozilla's Firefox, would radically change the way consumer DNS services work today, giving to browser makers significant control over the choice of the resolver, and promoting the use of centralized global resolvers in place of the local ones traditionally supplied by Internet access providers.

The set of DNS queries performed by a user allows an observer to track almost any connection to any Internet service; it thus constitutes sensitive personal information. Encrypting the communication provides users with increased privacy, preventing ISPs from tracking or mangling their DNS queries, but centralizing all user queries on a few resolvers run by the big Internet operators, many of which have "surveillance capitalism" as their business model, can create an even bigger privacy and control problem.

Moreover, ISPs monitor and alter DNS queries for network security reasons, blocking access to malware and phishing websites, detecting infections and stopping botnets from working and propagating; corporate networks build their security over DNS-based mechanisms such as local names and "split horizon" configurations; all of this would stop working with DNS-over-HTTPS.

In terms of performance, global resolvers run by the big players could offer quicker responses, especially in countries where the local infrastructure is poor; the current public resolver usage patterns show this, with high penetration rates concentrated in Africa and the Middle East. However, local resolvers, in conjunction with content delivery networks, can tailor their replies to direct local users to the fastest source of the content, while global resolvers cannot do this without knowing the originating IP subnet in detail, again creating a privacy issue.

But DNS-over-HTTPS also affects human rights and national sovereignty; if browsers lead their users towards a resolver located in a foreign country, the user's country loses jurisdiction on DNS queries, while the resolver's country gains it. If the user's country censors the Internet heavily, switching to another jurisdiction will defeat censorship and increase the user's freedom of access and expression; however, the resolver's country will now be able to apply its own censorship to foreign citizens as well. The few private global resolver operators will also acquire the possibility to prevent access to content and to determine the policies for the DNS namespace.

Moreover, there are cases in which countries use DNS regulation to protect other people's rights, by barring access to content such as hate speech, totalitarian propaganda, illegal gambling; and there are cases in which Internet users voluntarily request their ISP to block access to content, such as with parental controls for families. All these mechanisms will stop working if remote resolvers connected via DNS-over-HTTPS are adopted by browsers as the new standard, while the use of DNS-over-TLS connections to the ISP's resolver would not create the same problems.

This discussion is particularly relevant to Europe, in view of the lack of European browsers and Internet platforms, of the less effective privacy regulations that American services are subject to, of the abundance of DNS-based content control mechanisms, and of the widespread concerns about the ongoing process of centralization of the Internet, of which this case is yet another instance.

The session will explain these and other issues, document the various views and provide a venue for discussion and collective brainstorming on possible solutions from a European viewpoint.

== Format == 

The session will start with an introductory presentation to ensure that all participants are on a level field. The presentation (20-25 minutes) will cover:
* Basic technicalities of encrypted DNS protocols for a non-technical audience
* History and current deployment plans
* Description of the policy issues that derive from the adoption of these protocols (DoH especially)

After the presentation, we will devote the rest of the workshop to an open brainstorm among participants, trying to extract commonalities and possible ways forward. We will start with a "diverging" phase (20-25 minutes) in which we will ask for stakeholder views by people in the room that already have confidence with the topic, and encourage them and all participants to make proposals for future steps. We will then work in a “converging” phase (35-40 minutes) in which we will try to refine and ascertain support for the various proposals.

At the end, the reporter will recap the results and ensure that everyone is happy with them (5 minutes).

== Further reading == 

See below (towards the end of the page) for the presentation given at the workshop.

===== The basics =====

As a primer to the issue, here are two documents, one providing a supportive view and one summarizing the concerns:
* Mozilla's explanation of how DNS-over-HTTPS (DoH) works and its advantages [https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/]
* Open-Xchange's policy analysis and description of the problems [https://www.open-xchange.com/fileadmin/user_upload/Blog/DoH_Public_Policy_Briefing.pdf]

If you prefer a video explanation:
* "The DoH dilemma" from FOSDEM 2019 [https://www.youtube.com/watch?v=AMk12379DQ4]

===== Implementation plans =====

Mozilla is the leader in pushing DNS-over-HTTPS as the new default for browsers, and their announced default policy will be to bypass the name server configured by the user and promote the use of remote resolvers that have signed a service agreement with them. You can read:
* The original announcement on their blog in June 2018, with a lot of community discussion in the comments [https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/]
* Their performance updates in February [https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-https-doh-update-recent-testing-results-and-next-steps/]
* Their recently published set of requirements for DoH servers to be included among Firefox's resolvers [https://wiki.mozilla.org/Security/DOH-resolver-policy]

Google is providing DoH support on their public resolver and is also implementing it in Chrome, but not by default at this time. It also tries to look for a DoH service on the local resolver first. You can read:
* The announcement of Google's public resolver plans [https://mailarchive.ietf.org/arch/msg/doh/EVomTCdmATxr19VmRu9uloxDDVg]
* Tentative plans and policies for implementation in Google Chrome [https://mailarchive.ietf.org/arch/msg/doh/JhFPKoyGU2JqKmUk3GEe5yjuSHI]

===== Technical and policy analyses =====

* Wolfgang Kleinwächter's Internet governance outlook for 2019, referring to DoH at the end [http://www.circleid.com/posts/20190108_internet_governance_2019_innovative_multilateralism_vs_neo/]
* Ungleich's analysis from August 2018 [https://ungleich.ch/en-us/cms/blog/2018/08/04/mozillas-new-dns-resolution-is-dangerous/]
* Notes from the DNS privacy debate at FOSDEM 2019 [https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem/]
* Problems caused by DoH to ISPs in the UK [https://www.ispreview.co.uk/index.php/2019/04/big-uk-broadband-isps-have-big-concerns-about-dns-over-https.html]
* An architectural analysis of pros and cons by Akamai's Erik Nygren [https://blogs.akamai.com/2018/10/architectural-paths-for-evolving-the-dns.html]
* The House of Lords discussing DoH concerns in a parliamentary session [https://hansard.parliament.uk/Lords/2019-05-14/debates/E84CBBAE-E005-46E0-B7E5-845882DB1ED8/InternetEncryption]

===== Reference and technical material =====

* The full technical specification, RFC 8484 [https://tools.ietf.org/html/rfc8484]
* A list of current publicly available DoH servers and implementations [https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers]
* Google's resolver DoH API [https://developers.google.com/speed/public-dns/docs/dns-over-https]

== People == 
Until <span class="dateline">15 May 2019</span>.

'''Please provide name and institution for all people you list here.'''

'''Focal Point''' 

*Vittorio Bertola

'''Organising Team (Org Team)''' ''List them here as they sign up.''
*Chivintar Amenty, YouthDIG 2019
*Wolfgang Kleinwächter
*Peter Koch
*Collin Kurre, ARTICLE 19

'''Moderator'''

*Vittorio Bertola

'''Reporter'''
*Ilona Stadnik, Geneva Internet Platform

The Reporter takes notes during the session and formulates 3 (max. 5) bullet points at the end of each session that: 
*are summarised on a slide and  presented to the audience at the end of each session 
*relate to the particular session and to European Internet governance policy
*are forward looking and propose goals and activities that can be initiated after EuroDIG (recommendations)
*are in (rough) consensus with the audience

== Current discussion, conference calls, schedules and minutes ==

== Presentation ==

You can download the presentation on [https://bertola.eu/file/ig/The%20DoH%20dilemma%20-%20EuroDIG%202019.pdf DNS-over-HTTPS and its policy issues] that was given during the workshop. 

== Messages ==  
A short summary of the session will be provided by the Reporter.

== Video record ==
Will be provided here after the event.

== Transcript ==
Provided by: Caption First, Inc., P.O. Box 3066, Monument, CO 80132, Phone: +001-800-825-5234, www.captionfirst.com


''This text, document, or file is based on live transcription. Communication Access Realtime Translation (CART), captioning, and/or live transcription are provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings. This text, document, or file is not to be distributed or used in any way that may violate copyright law.''


>> MODERATOR: Welcome, everyone. While we wait for a few more people, can I ask at least some of the people in the back to sit at the table, at least if you plan to take the microphone or make questions, it would be better if it we had more people sitting at the table because it will make the circulation of microphones easier.

>> VITTORIO BERTOLA: Okay, so I think we can start and thank you for coming. This will be the workshop on DNS-over-HTTPS. My name is Vittorio Bertola, the focal point for the workshop. Before we start and put the presentation on the screen, well this workshop is meant to be an open discussion, but since we realize that this is a new issue and also pretty technical issue and it's not immediate to understand all the consequences, so you will have to go through like 20 or 25 minutes at the most, initial presentation which we will try to explain in a very clear way, and also for non-technical people, I assume there are several in the audience, what this is, how it works, and why is it creating so many policy issues as well.

Then after that, we will have questions for the audience and open the discussion. And if there is anyone in the room that already thought about this, worked on this, and wants to give perspectives, you're welcome to do so after the presentation and everyone is free to chime in and say what they think.

We have Ilona who will be taking notes and at the end she will present our messages and we will have to say if we are okay with them and they will be reported as a result of the session.

If I can get the presentation on the screen. Okay. Thank you.

So, I mean, well first of all, I'm going to explain exactly what this is. I don't know how many people here already heard about DNS or HTTPS. I think several heard about it but not everyone knows what it is about.

So the first thing is that I want to start with is a general framing because this really depends on where your DNS is being provided, so who is providing you the service of DNS or namely the solution for using the Internet, because if you don't need names you can just connect by IP address. So typical case of a user that sits on a home network. They usually buy Internet access from an ISP, and then through the network of the ISP they get to the Internet, and if you have the IP address, you just go directly and get all the way to your destination.

But then, of course, people don't want to use IP addresses, and this is why the names came in so the DNS was invented because people want to use names to connect to places, so there is basically hierarchical set of resolutions and resolution is the converting a name into IP address and authoritative DNS server and ask for the IP address that corresponds to the name.

So, the point, however, is how do you do this? So, you could in theory, just do this yourself, so your own device, your own computer could do the DNS resolution on their own so they could have a full DNS resolver in the operating system, and this piece of software basically would connect directly to the authoritative DNS service of the domain names you want to reach and you wouldn't need anyone doing DNS resolutions for you.

But unfortunately, this is not how it works. For a number of reasons, which mostly have to do with the complexity of the DNS resolver and also some optimizations that you can get if you have something in the middle of a server that does the resolution for you, and so this is how it usually happens.

So this is the traditional architecture for resolving names over the Internet. Whatever you do over the Internet, as long as you use a name, so connecting to a website, connecting to email server, whatever do you goes through DNS resolution, and usually what happens is that when you configure your device to access the Internet or when you connect to the network, you enter a name server, usually called in DNS speak more precisely usually a server provided for your ISP, so by the local network that you use to go through to go to the Internet.

And so this is what we will call a local DNS resolution because it's done on the local network, on the immediate network connecting your device to the Internet. So your device has established to a piece of software that just connects to the other -- to the resolver and then the resolver will do everything and send you back the reply.

And established resolver is in the operating system, so the same piece of software for all the applications in your device. So this is local, and this is local because it's, I mean, it's the nearest piece of the Internet that you have with respect to your home, but it's also local and culture and social and business, so the ISP through which you get your Internet connection is usually in your same country or even in the same city, they speak your language, you have a contract with them, so you know how to reach them, they can provide the service for you and if something doesn't work you can call them so they can fix the Internet access for you.

While this is the newer way of resolving names newer but still in place for 10-15 years, so this is remote DNS resolution model, and it means that the name server that you are using is not on your -- not provided by ISP and not on your local network anymore, so it's still a name server, it's similar to the other one, but it's somewhere over the Internet provided by a third party, so what happens is that you establish server will now connect through the network of the ISP, I mean to the router, to the Internet, and so it will take to the resolver on the Internet and then the resolver will do the resolution for you and send back the results.

So this is remote, and this remote DNS resolution model has quite some difference because the server now is in another country and there is no relation to the local network and so the network and the provider that is giving you Internet access and the people that are resolving the names for you, so it could be typically, it's a resolver, the most is .8, provided freely by Google and these are people you don't have a contract with, you don't have a service, you don't have conditions of a service, you just configure a name server and that's it.

In some cases, there is even a paid premium service so you want to get a better DNS service for whatever reason or different one so you buy service from for example Open DNS which is a provider of similar services.

So the difference between local and remote is really important to understand that the issues we'll be discussing, and so in terms of usage, this is where the latest statistics will represented like one month ago at the DNS Symposium organized by ICANN and remote resolution is really gaining ground they showed, and they said up to 40% but it's really depending by country, I'm pretty sure in Europe it's less than that, it could be 20-25%, parts of the world, many developing countries where the local infrastructure is bad and everyone is using Google, so it really depends on where you are.

And but I mean still the local resolution model is by the far the most common way of resolving names over the Internet, especially for the average non-technical consumer.

So, then weapon get to the DoH what is that? Short form of DNS-over-HTTPS, it was a new standard released one year ago spearheaded by web people and not from DNS or ISP or teleco community, but conceived by the web people and public resolve operators, and what it does is transmits the DNS queries, so requests for converting names to addresses over an HTTPS connection so they are encrypted because they're basically encapsulated within an HTTPS request, and so any application that is able to send and receive HTTPS requests, now can very easily send DNS queries to wherever they want, and up can completely bypass the operating system and the name server that has been configured in the operating system by the user or by the local network when you connect to it.

Of course, this is a different protocol, so it requires you to upgrade the DNS server or the web server, so it's not immediate, there needs to be an action by the industry to deploy this, but it's still -- I mean, it's already under deployment and we'll see this.

And so, I mean, maybe you're wondering isn't DNS encrypted already? Because you know we're in the middle of trying to encrypt everything, which is connected to privacy and security reasons, and DNS is still one of the protocols that are not encrypted. It was not conceived as encrypted protocol, first of all, because it's a very basic protocol invented in the 80s when encryption was military weapon and restricted and so on, but anyway the effort for in terms of CPU load would be, at the time it would be impossible to bear.

The recent Cryptography, DNS sec uses cryptography, so encrypted and basically seen over any one of piece of the network that your connection is having but they are basically assigned so they cannot be modified, so it's a different things and often there is some confusion but I mean it is a different purpose and --

There are some other protocols to encrypt the DNS connection like DNS-over-TLS or DNS Crypt but not widely used so by far the most common way is to send stuff unencrypted. So DNS introduces three main changes to the process. The first one is the encryption part so the connection is now encrypted so no one in the middle can actually read your queries, but it's also hidden inside of web traffic, and so since it uses HTTPS, it's the same protocol used by your browser to connect to websites, and actually one of the design features of this protocol they say for example Google could run the DNS resolver under www.google.com, same address, so the traffic you send is mixed with the rest of the web traffic you send to Google for search, for example, and this makes it impossible to even know you're using this kind of DNS resolution, and so it hides completely your DNS traffic to the ISP and to I mean all the network in between.

The second change is that now each application can use a different resolver, so DNS until now has been a network service, so something you get as part of the network service and it's the same for all the applications that run on your device.

With DoH, it becomes very easy for each application to do their own DNS query so if they want, they cannot use the operating system level, DNS resolver, and they can just send queries to some other place, and so different applications can resolve queries through different places.

And the third parties that now since it's the application that is doing the DNS resolution, the application maker gains some control in the choice of the resolver, of the DNS server used for the resolution, and in some cases, there is actually remote resolvers list, so the application maker decides which name service you are allowed to use and if you want to use a different one, you're out of luck.

So the first one is the only one that is common from the previous protocols and so DNS-over-TLS encryption protocols, but the other ones are protocol -- I mean, are new. The first two are protocol design choices, so they are embedded in the way the protocol is made, and they are unavoidable given the way that the protocol is made. The third one is a deployment choice, and so it can happen or cannot happen, depending on what each application maker wants to do.

And this is where there is a lot of discussion now which is related exactly to the deployment policies that have been chosen by several application makers, and especially browser makers since now the web is basically most of what you do over the Internet.

So, I hope everything is clear, unless you have -- so the consequences of deploying DoH in policy terms are far reaching. The first one, the encryption, I think it is not problematic, so there is really not a lot of argument about encrypting the connection.

So what they are trying to do is that they are trying to protect the connection, especially for people that are already using remote resolvers, because if you use a remote resolver, your DNS query goes unencrypted throughout a good stretch of the Internet because the resolver can be very far from you. So if you have someone in the middle of the Internet that can put a server near traffic, intercept your traffic like some agency, for example, a governmental agency are known for doing, then they can really see all your traffic and see basically everything you do over the Internet, and so this is clearly bad.

And so this is the scenario that the encryption part is going to prevent. While, I mean, if you're using a local resolver, this is not really so important for you because the local resolver is really near to you in topological terms just a couple of networks from your device, so unless the attacker is inside your ISP network, the fact that this connection is encrypted doesn't really change a lot because it's anyway very, almost impossible, very hard unless you're the ISP to actually intercept the connection.

The other scenario that this connection is trying to prevent is this one. These are increasingly common scenario in several country, including in Europe, in which you actually configure remote resolver in your device, so you want to use Google, for example, to resolve your names, but the ISP has -- I'm sorry, this is moving on its own. The ISP has transferring proxy, so a server in the middle of the connections, and since the data are unencrypted they can just intercept your attempts to connect with Google, for example, and they can see the traffic and they can actually block what they don't like, can filter it out, can apply policies, national laws, or whatever, and this, of course, this is not like the by the browser makers and people that operate the remote resolvers so they want to make it impossible for ISPs to apply any policy to the traffic that it not directed at them.

And so, I mean this encryption, is it a good or bad thing? I think it really depends on the use case and you will see this a lot, so it's basically impossible to say this new technology is good or bad in general. It really depends on who you are and what you want to do and what is it for the use case. If you are a user of remote resolver, this is definitely a good thing for you and helps you reach the resolver without anyone blocking your traffic.

And also, if you don't trust your ISP it's good for you because it shuts your ISP out of your traffic, and if you're a lot or move across different networks or don't trust the local network if it's hostile or whatever, on the other hand if you're a user of local resolver or like the ISP, this is indifferent or even bad for you, so this is preventing your ISP from checking traffic, usually done for good reasons, protecting from infections and malware and so on so we do see that, so it's really a matter of who you are and which DNS resolver you want to use.

The second change that we saw is that now each application can use a different resolver, and this is instead opening a can of worms, so it's actually good if the application is -- Mozilla who is championing the technology says maybe we can choose a better resolver than the user because the use certificate not technical and we can choose, private, secure, good resolver for them, and this is true if you have an application maker that you can trust, or if you don't trust your operating system or the settings of your operating system or whatever.

But, I mean, it's bad if on the other hand you have an application maker that is dishonest, not really doing you interest, and so if you have someone that does an application and wants to track you, they could just direct the DNS queries somewhere else and get all of your data and surfing or whatever activities you do.

If you are a smart user and really want to control your queries, then again, you're out of luck if the application decides to send them somewhere else.

And there are but several more, I mean, troubling situations, so for example, in the policy space what is potentially problematic is that you could start getting different IP addresses for the same name because if different applications start sending you DNS queries to different servers, then they could get different replies depending on the local policies, on blocking, not blocking, but also on for example content delivery network optimizations that would send you to different places for the same name.

And so I mean, this is creating a mess in which maybe in some implications you can reach a certain destination and the same name in another application doesn't work, it's worse if you think of the name space and policies surrounding name space like ICANN policies and so on because each application in theory can now control the name space and say we are going to add our own TLD to resolution and resolve it ourselves or so on. Or on the other hand we're going to block on TLDs that we don't like.

Then there is the third one, the third one is the fact that the application maker now controls the resolver choice, and this is really the core of the discussion, and so this was -- I mean, this started when Mozilla one year ago announced that they wanted to enable this new technology in Fire Fox and they wanted to do this by default, and so not really, I mean, asking users to do it but just saying are you okay if we turn on this as better DNS way, more private, more secure.

And so and the point is that they also made a deal with Cloud, a big global provider to run the DNS server that would then be used by this new technology, and so basically this, again, meant that when they would turn this on, all the DNS queries would start from all Fire Fox users around the world would go to Cloud, no matter what DNS server was configured in the operating system. They haven't actually done this yet. There has been a lot of discussion, they're still working it out, now they say they will do it, but maybe just in certain parts of the world, and what they came up with is a resolver policy, so they also said that they now want to have more than one resolver choice, so they actually said if other people want to run DNS or HTTPS servers that can be used by Fire Fox users, they have to go through this accreditation process, so we are going to see if we accept them, and we will accept them if they meet a number of requirements in terms of privacy.

And so some are actually pretty good ones like not storing the data, not giving it out to third parties, and so on. But what's happening, also in the initial implementation, on the on the right you see the configuration scheme, the relative of Google Chrome a browser focused on privacy and what they do is basically they don't let you choose your server, and so they give you, I mean, the option to disable DNS or HTTPS or just pick when it's Google, CloudFlare or Quad9, so three big public resolvers, so if you wanted a different one, you're out of luck again.

And so this is the real change, and so in the current traditional model, still local resolution made by the local ISP is the default, so it's what you get if you just connect to a local WiFi network or whatever. You get a resolver and you can set the resolver in your operating system, so if you want a different one, you can go there and change it and it will apply to all your applications.

So in the new version under this deployment model, the remote resolution will be the default so the default will be to send all your requests to a global resolver somewhere over the Internet, which is decided basically by the application maker, and if I want to change this, you have to change this once per every application so you have 50 apps and you have to set the DNS server in 50 place, unless we can come up with ideas or examples or policies to make it so the user can set it just once, which is part of this discussion.

So this is a lot of policy impacts on a lot of different things and some of them are not really immediate, and so but the most immediate one and which is currently being discussed at the ITF as well is concentration, and so what happens now is that, I mean, DNS traffic is really spread across hundreds of thousands of servers, basically every ISP has one or more, and I mean there is some mild concentration, but again recent data shows that to get to 95% of the DNS traffic of the world, you have to put together the top 1,000 resolvers, so it's still a pretty good distribution, and of course we saw that Google has one-third of that but the other ones are really small. They are all around the planet, so in different countries, different places, and you can pick whatever.

In this modeling which the application controls the DNS resolution, then for browsers, the situation is dire because there are four browser makers that control over 90% of the world's web traffic, and so they're all in a single country and single jurisdiction, and so this is really creating a concentration and potential control point, and it's very hard to imagine that this is going to be different in the future, so there have always been very few browsers dominating the market, and maybe the dominating one changes, but there is always one that is dominating the market.

And then there is the discussion about privacy, so this technology was proposed to have more privacy, and indeed it does in terms of transport, and so your queries cannot be intercepted anymore and this is definitely one of the advantages and we should definitely make good use of this.

The problem is if you are changing the place where the query is resolved, you're changing the jurisdiction, so now if you're in Europe and using your local ISP server, you're covered by GDPR, basically, if your data starts to be sent outside of the European Union, then different laws apply and they might not cover you that well.

And also, the ISPs are companies that don't leave usually target advertising, I mean, you're buying Internet access, paying them to get access, including the DNS server, and that's mostly what they do and also in Europe they cannot really have this data, it's forbidden by law.

While the global platforms in a good part of companies that live off of tracking people, and so they say of course they commit not to use this data for user tracking, but in the long term, I mean, this doesn't look likely, honestly, so it looks likely this will be yet another way for the big Internet platforms to have more data about the browsing amp aptitudes of people.

In terms of censorship, this is a very good technology especially if you live in a country because this is basically going to bypass the DNS-based content filters in place in your country. If the country uses DNS to block some destination, then this is going away, and this is good especially if you don't like filtering. Of course, the ITF mindset is no filter is good, not just the authoritarian ones but even the ones in Europe on pornography and illegal content or this kind of counterfeit medicines and illegal gambling, a lot of stuff that is filtered in different European countries depending on the local laws, and so this is going to disrupt all of this as long as it's based on the DNS.

On the other hand, you now get any DNS-based content filters in the resolver's country, so if the resolver's country, say the U.S. Government passes a law that says that certain companies have to be blocked and unreachable, then now you will be subject to the resolver's countries censorship, and on the other hand the fear is also that this will create pressure, even in Europe, for other ways of filtering the Internet access and so if -- I mean, DNS filtering is a mild way of filtering things that is easily bypassable by smart users and still is not over-invasive and precise in what it filters, and so it's a good compromise between not filtering and being heavily filtering. If this goes away the ISPs will be forced to apply firewalls or inspection, or other ways of doing this that is going to be much more invasive in the end and problematic for the users.

Same for network neutrality, again, there are ISPs breaking network neutrality and this is bad, and so this can prevent ISPs from breaking the network neutrality but now the resolver can break network neutrality so depends on the jurisdiction where this happens and whether network neutrality is protected or not.

And then there is some discussion about performance, and performance really depends if you have a local service which is very well performing, maybe it's better because it's near, but in some several cases, the remote resolvers are actually weaker and perform better. There is a problem with CDNs, content delivery network, because if your resolver is local, it can give you the nearest server from the content delivery network without actually having to follow with information about you, and so your ISP will get a localized content-delivery server and they don't need to tell who you are.

While remote resolver has to forward information to the CDN on who you are and where you come from otherwise the CDN cannot choose the proper server and if they decide not to do this to protect your privacy, then you're going to get a slow connection to the content delivery networks.

So security, well, security is one of the biggest issues now because this DNS monitoring of queries is increasingly used by ISPs for network security issues, both to secure the local network and to secure the user, so many ISPs now have, I mean, check the DNS queries that you send to the local resolver, they have a list of current bot nets command control centers, mobile websites, phishing websites and so if they see you're trying to connect to one of these websites they'll stop the connection and prevent you from connecting to one more or more website or fishy website.

And they can also use this monitoring as one of the ways to check what's happening on the network, and this is especially important in the IoT world because in the traditional computer mobile world, you can install antivirus software or whatever on your mobile, and so that's an alternative, but with IoT you cannot install on smart board or smart fridge or whatever so you have to rely on network to check what's happening and detecting network problems and this is going to be a way, and so the ISP is going to become completely blind on where the users are going, and so -- and also there are several security devices, especially for corporate networks like so called split horizons or names that only work locally, or local Internet names, these are also going not to work anymore if the application of the browser connects to a different DNS server, and so I mean, there is still some analysis going on in some studies, but there is a lot of concern about security, cybersecurity effects of this technology.

Finally, there is the discussion about user empowerment, and so the discussion is basically who should choose the DNS server, and so I mean today the user can basically choose their server, you need to be a little technical but most users over time have learned not to at least change the DNS server if they want and there are also several DNS-based services that people choose and opt in and so parental control, for example, is often done this way and so people that want to block certain, let's say websites from their home network because they have kids, this he do this by acquiring or setting special DNS servers and acquiring the servers or the service.

And this is stopping to work, so in the future if the kid just downloads it and turns it on and uses different DNS server then all the other webs will be visible, and so there is some discussion whether this is actually empowering the user or not.

And in general, this is also not very well understood yet, so there is I mean outside of the technical community, there is not a lot of discussion on this and users don't really know what's happening.

So the key points that I want to make is that the discussion is about privacy, but it's not really just about privacy of the transport of the queries or encryption but privacy in general, and that's the approach that should be discussed. There is a potential risk that if you create some concentration and you reduce the opportunities for the users to control the DNS queries, you will actually be creating a point or single point of failure and so on.

And the other point is that this is potentially a technology that creates more freedom for the user, especially users that are in a very heavily-censored part of the world, but in the end you're just changing the charge, it's not like you're creating freedom by this kind of stuff, but you're just putting other people and other companies in charge of controlling the traffic and the DNS resolution, so you have to hope, you can hope that they can give you more freedom, but it's not like freedom-making technology.

So in the end, is this good or bad? It really depends who you are. So it possibly, if you are an authoritarian country this is better, if you don't trust the ISP, which is the case by the way often in the U.S. itself, so if you trust the big Internet platforms more than your ISP then this is good because it's a shifting of the control of the connection, and if you like the idea of all of this happening in the U.S., this is good.

On the other hand, if you trust your ISP more, if you trust your local jurisdiction more, if you are worried about centralization of the net, this is not good news.

But the point that I really want to make is that in good part it just depends on the policies, so this is why now the discussion has to move from the ITF into the policy realm because, I mean, for example if you had policies that the applications still have to use the local resolver, then many of these concerns would go away, and so I mean, the discussion really has to be on, can we do policies and how can we convince everyone to sit at the table and make good ones.

So, I would like to now open the discussion, and I would like to leave you with three questions and then if more people want to have more questions, of course, they are welcome. But the first question for discussion is, who has control over the device resolver? So is it the user in the end? So should the user always do this? Because there are some other people, both in the network community and especially in the browser community that say that the user is not technical enough, so the application has the duty of choosing the resolver on behalf of the user because the application makers are better informed.

The second question is, who should be entitled to apply policies? Policies means anything from filtering out malware to filtering out websites that are not likely or illegal or considered inappropriate, and so is there the right of any of these parties to apply policies? So should the government have a way, I mean your government, or citizen of the country or as a citizen, is there a way to impose policies or filtering policies to your DNS and even if this is maybe done at the global level by a public resolver platform? Or is the resolver itself, I mean, should they be able to apply policies, for example, for network security and same for the network administrator? If they decide they want to make some content inaccessible, should they be allowed to do so at the DNS level?

The third question is, where do we have the discussion? Because the discussion now, it has mostly happened at the ITF, so it's been a very technical discussion and it's been very informed by values of the ITF which are specific West Coast libertarian values and other parts of the world this is just starting to happen, and I think in other parts of the world there are different view, and so where do we put all the stakeholders together and where do we have the discussion?

So thank you. This is -- these are my contacts if you want.

(Applause)

So, sorry. Yeah. This is moving on its own. So this is, yeah, I'm sorry if it took some time, but I thought this is really a new for many people and so, first of all, of course, if there is anything that you didn't understand you're free to make questions, otherwise I would like to open the floor for people that either have an opinion on this technology or want to try addressing some of these issues. Don't be shy. Go ahead. Can we get the microphone there?

>> AUDIENCE MEMBER: I'm Simon Hicks, work for the UK Government Department for Culture and Support. Over the last month there are more parliamentary questions on this than I normally get on standards in a long time, so it's certainly something on my radar, and it is of concern to, certainly to Ministers in the UK. Personally, I'm -- I'm the digital standards lead in the department, and our main concern has been that we seek to use in the immediate future the DNS queries or DNS system, essentially, to provide for the blocking of undesirable content, and we've attempted to put that role on the ISPs.

Of course, with DoH, that blows a bit of a hole in the middle of it, so our main wish at the moment is to see a rollout of DoH in an agreed way that would make -- continue to make local content control within a country possible. We recognize, of course, that we're still in a very embryonic stage and we've only got an IETS standard that described DoH as a technology and this is no generally agreed rollout pattern yet.

So, our principal wish at the moment is to try to get industry engagement to come together with a generally agreed, generally held plan as to how DoH will be used so that from a legal perspective, we could then see how a Nation State, such as ours, could implement content control around it.

So I would like, for example, to see a default option for DoH resolution within the country you're in, and also to see the ability as we want to be able to have parental control as well so that parents can control what DoH services are being used.

And also, of course from a user perspective, it would be fairly simple, we heard that any app can use any route it likes and from a user configuration, and when we're often dealing with people who are not too familiar with the technicality of the computer, it's just something that they use, saying that you've got to set these funny numbers for every single application you've gotten, delve into screens of screens, well you know, it's just going to be pretty daunting for your average user. And so again, we'd like to see some sort of generally understood, generally agreed way of handling this for the main operating systems and how it could be used.

So I'm afraid I came here with a lot of questions. I'm a technical person so I understand the implications of it all, or some of them at least, but of course we're trying to get something here that works for a Nation State and works for an average user, and I think DoH, where it currently is, it's a perfectly good standard, it's been adopted by the ITF, but actually trying to understand and work out the deployment and sort of get traction across industry to make all of this happen, seems to us to be the big question at the moment. We're trying to stimulate it in the UK and engage with industry at various levels, but of course, you know, we can't just agree some single thing in the UK, and even if we could, would it work for the rest of the world. The Internet is a global phenomenon, as we're hearing very much, you know, so we've got to have something applicable more or less across the globe. That's probably enough. Thank you.

>> VITTORIO BERTOLA: Thank you. Here?

>> AUDIENCE MEMBER: Hello. Can you hear me? Okay. My name is Collin Kurre with Article 19, and I just wanted to kind of zoom out a little bit and focus on a more societal approach to this because I think a lot of times -- well in the past 5 to 10 years there has been a proliferation of DNS blocking and filtering across Europe, and I sometimes think it's a hammer looking for a nail, and that this isn't the appropriate solution for the social problems that we're often trying to address, so instead of increasing -- or instead of trying to approach this from a way of how can we make this compatible with our current legal frameworks, that may or may not be appropriate in addressing and changing the or in affecting the impacts that we want to see, I think it's good to say what are the social problems that we're trying to address.

And that's why I really appreciated your presentation and how you laid out the pros and cons and different aspects because I think as a community, these are the kinds of thoughts, and this is the line of thinking that we need to be pursuing, and so if from a legal perspective, if it is how can we enable -- how can we enable, you know, law enforcement to be able to look at, whatever -- I'm not going to go into this example because I don't want to get into kind of access to user data debates here, but I think it's worth zooming out a bit.

And I thought it was interesting you were talking a little about the local resolver, and I'm not sure if that -- I'm not sure if that would be a good solution in terms of changing the way that society approaches this. I think that it would be more of a stop-gap solution because it would allow us to kind of shoe horn this current problem into the past solutions.

I know that within Sweden, actually the Crown Princess has started a new initiative to try to reduce the dependence on DNS blocking and filtering by encouraging parents to talk to their children, and so that you would have less dependence on this for parental filters specifically, and so that might be an interesting way of approaching this, and I'm not saying it's an either/or situation, but I think it's useful to begin teasing out so if DoH as an Internet standard, in my opinion it's very innocuous and it's a standard, it's a way of doing things, it's something that has been demonstrated to work and that's great in terms of innovation and creative thinking and problem solving, but as a multistakeholder community, we kind of need to be saying, okay, so what is the problem here? Is it maintaining the rule of law, is it giving network administrators control over their networks and legitimate situations? And then we can try to reverse engineer the solutions that we want to begin seeing.

>> AUDIENCE MEMBER: Hi, my name is Adam Kinsliy and work for an ISP in the UK, Sky. We can continue the conversation we started last night on the way home from the beach. It's an interesting question about what society demands, and in part the UK ISP community has responded to what society has asked of us, which is to have simple-to-use parental controls that apply across the network, that's something that the British Society has wanted and so it's not -- it's not blocking but it's offering customers filtering which they've taken up in high numbers, and that's done at the local level. And UK Society has gone a step further and our government has responded with a white paper on online harms because they want more to happen in this space, and that's recognizing UK Society, and I think that Vittorio made is that this moves it away to another society, to standards that might be in the U.S. to apply to UK citizen, so I think that does cause some problems.

I think there are two ways of trying to solve this. One is trying to work with implementing the standard in a way in which is compatible across all operating systems and app providers, which is quite a challenge. The other one that the UK has got in the white paper, it's calling for a duty of care to be cast on some players, and maybe it needs to cast it on a wider set of players when they are providing services in the country of destination, if you like.

So there is more than one way, I think, that you can deal with this.

>> AUDIENCE MEMBER: My name is Peter Koch. I work for the Top-Level Domain Registry for Germany so we do a bit of DNS, and I think we might want to zoom out again a bit and look at the spectrum of problems that was raised in Vittorio's presentation and maybe some even in addition to that. Much of the discussion of DNS is poisoned by the long-standing discussion of whether the DNS is the appropriate place for content control, and of course having been in the DNS business for almost three decades almost, we know it isn't. It is not possible to do this against the desire of the consumer because there are so many ways to get around the blocks or filters and so on and so forth.

There are scenarios, where with the consent of the user, of course, that can be taken as a warning sign and so on and so forth, but asking now for something that the DoH should deliver that doesn't work in today's environment is probably a bit much to ask. The whole filtering is only one aspect, and as I said it doesn't work efficiently, and there is no efficacy, and lots of circumvention and so we've had these discussions for two or three decades, and this is a new aspect or angle, but the protocol itself is kind of innocent. The protocol itself, saying that first of all, the DNS traffic is going to be encrypted, that's one aspect of this. That is in response, by the way, to if anybody remembers a person named James Snowden, actually it was Edward Snowden, right? Nobody objected, you're not awake. If anybody remembers Snowden, there were some revelations that showed that Nation States, in that case, were intercepting or ease dropping on DNS traffic to get some intelligence and so on and so forth and that led to an initiative in the IETF to respond to this kind of threat first, to declare this a threat, and then respond to it by what was called persuasive encryption to counter pervasive monitoring and encrypting DNS traffic is now a piece in the puzzle of this overall response. This did not come out of the blue and it did not root in the intent to support online harm, just the opposite, depending on who your enemy is and what the threat is.

If we zoom out from this content debate, we see a kind of power shift, and that is something that Vittorio mentioned, I think, this DNS resolution is something that nobody really noticed, unless you were a system administrator or professional and you're looking under the hood in your laptop or smartphone.

Over time and pre-dating DoH, this has become kind of a business. We've seen a couple of centralized resolution providers, even without this encryption technology, so there was a concentration already going on. What happens here now is that again we have a system or a situation where parties are in control of both sides of the spectrum, as in if I have browser software and I'm able to deploy new software, again with the snap of my finger, to a large part of the population, the users, and I can encode changes of behavior there, and then of course I can shift the swarm and the direction of the swarm quite easily.

If then that power is combined with, or that ability I should say, to be a bit more neutral. If that ability is combined with a situation where there is already a concentrated, and I'm hesitant to say market because for markets we should be able to actually explain where the market, the value, and the gain is, but if there is a collective of resolution providers, that concentration is accelerated even more, and now everybody is faced with a situation where some deliberately distributed function in the Internet, namely, name resolution, is seeing a concentration, and parties that haven't been at the table as a -- yeah, we could say stakeholders or as a participant or whatever, now get millions or tens of millions and users behind them so that might shift where things are going, and also what Vittorio mentioned in passing or explicitly actually, what does that mean for the shape of the name space is something to think about, because if there are only a dozen or so resolution providers and not everybody is forced or willing to use them, but it's the vast majority, then it would be easy for them -- same way as it is easy for the certification authorities to kind of agree on how certificates work and so on and so forth, to sit together and decide whether or not dot Amazon is something they would really like to see added to the name space. I'm not saying the route. I'm saying the name space. Or whether or not onion, which is an example that was dealt with slightly differently one or two years ago, or some other random piece of a name space should be added because it enhances the name space for given values, and where is the governance there?

And another governance question that I would like to highlight here is, there has been discussion about, okay, so there should be a choice of resolution providers. There was an agreement kind of -- or a response that well maybe in a monopoly or browser vendor deciding who is going to provide this shouldn't be the thing, but the browser vendors or a particular browser vendor would like to have a say in what conditions these resolution providers should meet, as in what should their policy be, as in privacy terms, as in what the strength of the encryption is, what the opportunity or the regulatory regime might be, or what additional services, and somebody at the end of the table mentioned parental controls, which I already say the services.

And then the question again, of course, is that something that the browser vendor should suggest or dictate or a collective to avoid cartel of browser vendors should do, or where is the governance for this, for the policies of the resolution providers? So I think that's -- for a venue like this, this is a bit more big picture than repeating the debate about content control, and apologies for the co-presentation.

>> VITTORIO BERTOLA: Thank you, by the way. Before giving the floor, I just would like to point out that the risk is that we keep discussing whether the content filtering of the DNS server or any other level is good or bad, but the real point of this discussion is who should decide whether it's good or bad? So who has sovereignty of deciding if it's a national question or global question or is it the IETF or browser makers or national governments that have to decide that for a given community there should be or should not be some kind of filtering, and this is really the core of the discussion, in my opinion.

>> AUDIENCE MEMBER: Testing. Yeah. So, thank you, first of all your presentation was far better than I've ever seen on anything about this topic because too many times I see this very one-sided, transport-only treatment of this issue, so this was really, really good. Thanks for that.

I do want to agree with people who say that we should abstract the way a little bit from these specific issues. I think the specific issues will, you know, change over time and our opinions may change, depending on what side of a particular issue we are and what particular legal issue we're dealing with in a particular country, and rather go back to first, principles of why are we doing some things and what's good and what's bad.

I think, first of all, this is probably bigger than the particular protocol, and I agree that the protocol is actually innocent and good protocol and it's more about the deployment patterns and type of arrangement than the encryption, perhaps, in some ways and so I think we should look at that.

And on the principles that we could defer to in a situation like this, I think the first one is, you know, is this about like having to trust the particular entity or not? And again, that's also like a variable thing. Can you trust somebody maybe now but maybe not tomorrow because the people changed, and some of that -- actually I know personally that some of the people that run this and they have the highest possible integrity that one can imagine, I trust them fully, but they're only human. Here not immune to governments sending various kinds of letters to them and telling them to disclose data.

I think we have to ask with all the data that is currently sent to this and services in a country is actually being used for surveillance and I think that's actually wrong, we should not do that.

The other thing is, is there the ability of control, and so I think the principle should be, you know, retain control as much on the user side as possible, and also as Peter was saying, you know, concentration of information that used to be distributed or function that used to be distributed into a few places is bad. The architectural principle is that if you have something that's distributed, it's very difficult for anybody to control it from outside, let's say of a particular government or commercial entity, but if you put it in a few hands, then it's very, very easy and we should simply not do that, and I think that that is what we should actually demand as users, that we want privacy, for instance, we want reasonable amount of control for ourselves, for our corporations maybe if you're working a corporate network environment, and we should be able to ask the browsers to, like if they actually want to provide something that's not just transport secure but also secure in other ways, then please implement something where we have user control and where we have a reasonable set of default choices where we could go to because if it's three big entities in the Internet, that's not enough. But if you have 100 or 500 to choose from different parts of the world and different entities, it would be far more workable and I would be happy to use such a thing. Currently I think it looks more like an attempt to collect data. Thank you.

>> AUDIENCE MEMBER: From ML net and one aspect which people which I didn't hear yet, but which I want to put on to the pile as well, and that's a couple of securities analysts are worried about this because if you really have a data stream which is very private, it's also very nice channel to distribute malware and which actually -- that has some people worried about how this happens so that's yet another problem to the pile, I just want to mention it.

>> AUDIENCE MEMBER: Okay. So as my neighbor just said, indeed, it makes a large difference whether you have five to choose from or hundreds of options to choose from. The list you show are not only global players but there are American-based players and not many European initiatives yet, and I hear that in the UK there might be the idea of at least having a couple of resolvers in the UK, but I think it will be vital to have those choices also really in the European space, for example, provided by European telecom providers, each provide the DoH for themselves, at least provide some choice in that respect.

>> VITTORIO BERTOLA: I agree. I think part of the discussion is also how to turn this sort of quarterly negative arguments into positive one. Also, one of the objectives of having discussions in places like this one is maybe we can put really together a multistakeholder effort to make good use of this technology, so and provide choice to the users. At the same time, I think everyone is concerned with the browser makers going their way too quickly in a way without consulting with all the other stakeholders on the issue, and the more you get into the issue you see more stakeholders and more problems.

Okay, I let Peter and then I give --

>> AUDIENCE MEMBER: Good morning, everyone. My name is Peter from Center. We started this conversation a couple months ago in our community, and Vittorio contributed with the presentation and it's good to see that this has evolved and plenty of new stuff, and this brings me to my point, we have been watching clear and improving trends in what we've seen from the communication in the browser community in particular, addressing the main concern. If you look back to the situation in October, it was hard coded, there was no choice, that was it. It was full of naivety and not looking at the potential treads that were quickly identified by the community.

I think through the healthy discussions, we've been able to improve the situation and I think we're moving forward to a healthier goal. With Mozilla did for clear requirements for DoH resolvers is that they would accept this as possible options in their browser, default still to be decided as far as I understand, is taken up at a center community and so ccTLDs will start building if they haven't already done so, so .lu and .cz is already operating DoH resolvers and that fit those requirements, so I think there is a positive side to the story and it's seen as an opportunity to encourage improvement. Thanks.

>> AUDIENCE MEMBER: Collin Kurre again. I completely agree with that and I just kind of wanted to pick up a little bit. It seems like we've been thinking a lot about agency or choices being made on behalf of others, for example, with Mozilla's decision to implement a DoH.

I do see this as being not dissimilar to network, for example mobile operators decision to deploy 5G or UK government decision to put out the Harm's paper there is similarly kind of opaque decision-making processes that result in an outcome that affects people.

So I think that when we -- when we're considering this, obviously one huge component of being able to have and exercise agency is having choice, having options, so having more than just you either accept this or, you know, you don't use the Internet.

But it's also you need to have informed -- the other half of agency in this scenario would be informed consent, right, and this also comes in with data protection, legal requirements, GDPR and things like that. But in order to have informed consent, you have to know what's going on to a certain extent, and so another kind of zoomed out societal issue is that we need to help people, including communities that might not be as integrated such as the elderly or people like that, to be able to have this kind of informed consent and be aware of the choices.

Then another thing that I don't think we touched on yet is the ability to, yes, revoke consent or if you had decided to trust an entity to be able to change this and the ability to be able to claim redress in some way if there has been a breach or violation or otherwise, you need to be able to have this kind of follow-through in terms of due process and remedy.

>> AUDIENCE MEMBER: My name is Roloph -- I work for SIN, and Peter, I think you were a bit humble and the Center has just -- this was a balanced, comprehensive presentation and Center has just publish a very balanced and comprehensive document on this subject, and as far as I know, it's downloadable from the website and definitely worth reading if you're interested in this subject.

>> VITTORIO BERTOLA: Okay, so I don't see other people that want to take the floor. And so maybe the question that we could focus upon is what do we do now? I guess there is more or less some consent that we should try to work out how to use this technology in a user-centric and positive way and so put the user -- I mean I guess I heard several people say we should put the user in charge at the end. I didn't hear anyone say, no, the user should not be in charge of what happens with their data.

And if you start with that assumption, then the next step is what each stakeholder needs to ensure that the user in the end is in charge.

I mean, part of the discussion in the beginning is that it was relatively hard to engage people deploying this, and by the way I invited Mozilla here and they had no one physically participating in this conference so no one could come, but they are in the loop so this is not meant to be everyone except them, and but I think that there should be a place where the people that are concerned about this start meeting, even in an informal way, and discussing what could be done to use this positively and deploy this positively and addressing the concerns while also meeting the objectives of privacy and security of the protocol.

So, I mean, I know there are some efforts to build this kind of informal coalition, mostly now coming from the UK because the UK is the country where the debate has been more advanced for a number of reasons, and I'm happy to hear now people from the Netherlands and other parts of the Europe that all the European countries should start thinking of this and maybe discussing locally what are their plans, and whether these plans, for example, include encouraging the ISPs or national community as a whole to deploy the resolver or DoH resolver, and part of the discussion also that I think we need to have is how can we build a fair the list of for the browsers, not that Mozilla is doing is not fair, but several people expressed the idea of having some kind of third-party process so it's not the browser maker that decides which operators can end on the list, a bit like the infrastructures that are built around the certification authorities around certificates, so to have an independent or shared process that can ensure that every applicant can be fairly treated and end up on the list if they meet the basic conditions, and also the basic conditions are widely shared and not unilaterally shared by application makers.

I don't think we have anyone from the other -- from the other application makers because, by the way, Mozilla has been insisting on this, and Google's position until now is sort of more cautious, so they are experimenting with this and released apps and they are doing things, but they have not announced that they will do the same that Mozilla is doing, and so but still of course they need to be part of the discussion. Go ahead.

>> AUDIENCE MEMBER: Thank you. From Frontier Finland, and while it would be better to have 500 to choose from rather than 3, I see no obvious reason -- actually I see no views that you shouldn't be able to enter your own whatever IP you like, for example in the Internet, local host names you would want to have your own resolver anyway and issues should be known issues and why would we have to choose from whatever the makers decide to trust? Is there some reason why there would be an open box for IP aware that you want to run your own DoH resolver?

>> AUDIENCE MEMBER: To react on the last bit. Mozilla is the only one that has said that they will change the default behavior of the browser, so they will do default and choose for you DoH on whatever they choose for the resolver.

I have a good source that the competitor, Google, big marketplace than Mozilla, will not change the default behavior at least on this moment, but will build in the possibility to choose as well, so there are different ways in the implementation of this stuff and more added at what other people say that have been so many of these -- so that's --

>> AUDIENCE MEMBER: Is this on? Yep, so I think the question of what shall we do concretely is a good one. I think there is actually multiple different steps and there is no single answer or single solution. Obviously, we need infrastructure in the world to answer inquires in the future and not just some company in some country and that's it. So it sounds like there is a lot of progress and I don't see why operators or ISPs wouldn't be basically all of them running their own also, and I mean that's a place to sort of fastest respond, and so latency would be reused and that's good.

Then we have the question of the list, I think people are very focused on the list as a current issue, but that's not the only issue. In order for the list to make sense, we have to have some things to point to, and so you actually need both of that.

And then finally to follow up on the points, of course, you should be able to add your own thing also, but I would actually go a little bit further and say there is probably some technology to be thought up that would around going through different things or send one part of a question somewhere and another part somewhere else so that nobody would have the full picture of what this user is asking for or which user it is that wants the answer.

So there is like this technical component to work further and develop more solutions, work with the browser vendors on how the lists are managed, and then create this infrastructure. Those three things. And also, maybe fourth, continued education on this topic.

>> VITTORIO BERTOLA: Yeah, definitely, even if, for example, the kind of solution of spreading out the queries works for general browsing, but if you want to use a specific server because you have a specific policy like parental control or whatever, so it's really a matter of server use cases that conflict with each other and maybe part of the problem, I think that during the creation only a subset of all the use cases were really considered or were in the minds of the people thinking of them, so there are a number of situations that haven't really been thought out very, very well.

But I think this is why we're having the discussion and trying to bring more people in and more stakeholders in and have multiple views, so okay. I'll let you --

>> AUDIENCE MEMBER: Yeah, I understand that the next IETF in July, a new group will be starting to look at how DoH can be used and deployed, so maybe that's the embryo of the discussion as to sort of how -- how it actually gets used.

I'm not sure though that the IETF is quite the be all end all for deployment in a sense that it's a largely technical community, and it's probably not overly well attended by wider society, and is probably not a total reflection of all the concerns of wider Civil Society, and so we probably need something else alongside that, I would suggest, and I'm not quite sure where they would live, to sort of try to bring it all together and discuss the overall deployment scenario.

>> VITTORIO BERTOLA: Yeah. If I may, to the best, in month reel in the IETF there will be a meeting but not the start of the working group, so in the end this will still be for discussion at the next IETF meeting in Singapore, but I think personally what I sense is that this will happen but it will be focused on very other technical issues such as do we make the operations work and do we need protocol extensions and whatever, but not on the more policy-oriented issues, especially this one of being content control, which is of course the most hidden one, and I think it will not be the subject of an IETF group because I see it hard for them to ever agree on anything on that.

Which means we should have the discussion on where that could instead happen, and this is why multistakeholders settings like this one are actually I think one of the best options. Honestly, I'm a bit surprised this hasn't come up yet, or correct me if I'm wrong at ICANN GAC, the Governmental Advisory Committee or at the High Level Group on Internet Governance, so in these kind of places, I would expect governments to work out a solution, but then of course this is the governmental view and there should be the other stakeholders, and maybe at EuroDIG, the IGF could also be a place to have meetings or maybe some more existing organizations could host a series of meetings and I mean this is open for discussion and action. Colleagues?

>> AUDIENCE MEMBER: Collin Kurre again. I have just an idea that we might be able to take forward. It's along the lines of the resolver accreditation policy that I think Mozilla is working on, but I was having a look at the codes of conduct under GDPR in the European Data Protection Board has some interesting and thorough guidance on how those can be established, and so in the eventuality that we have a bunch of different resolvers running their own DoH servers, then it might be interesting to explore potentially creating a code of conduct for these kinds of services because this would be a way that we might be able to standardize a certain level of trustworthiness in terms of data protection and might have a boomerang effect in terms of the widespread blocking and filtering because one of the issues with DNS blocks and filters is that we don't have very much visibilities on how, when, or how often they're deployed and so within the specifications for GDPR codes of conduct, there is a level of transparency and accountability that is required for monitoring by the supervisory authorities, so in order to qualify for, you know, for to be entered into this code of conduct, it would shed light on the number of data requests, for example, that were being validated, which would in turn kind of potentially create a positive accountability feedback loop by giving and shedding more light on the requests made by governments and allowing them more opportunities for scrutiny and oversight by civilians.

>> AUDIENCE MEMBER: Hi. Jim with the Galway Strategy Group. To pick up, there is a session at no time ICANN meeting next week in Morocco dedicated toward this, it's one of the high-interest topic sessions that I believe is led by the GAC, Stability Advisory Committee and CCNSO, so just go to ICANN.org and there is remote participation for those that can't make it.

>> VITTORIO BERTOLA: I guess several people here will be, so of course everyone is invited to join the session. So do we have anyone? I think this has been a pretty good discussion. I mean, best past discussions and meetings have been much more controversial, I would say, and this has been much better, I would say.

>> AUDIENCE MEMBER: Minor observation. What is exactly the reason that makes DoH different here from DNS because a browser maker could just as easily force hard code with regular DNS in it. So it seems to be a part, of course encryption is one thing, but large part of it is that it is deliberately being used as a way to concentrate this, that the browser makers take advantage of the monopoly but policy situation for a few of them, so it gives them a chance to do as a pretext of getting more security, they get the ability to collect more data from users in a few hands, so this is kind of a really the protocol could be treated just like the DNS, and everybody has their own server and so forth, but this is not encouraged and kind of hidden as an option even, so seems to be there is something of a hidden agenda somewhere here.

>> VITTORIO BERTOLA: Yeah, and of course we don't know. It's through that, I mean, in the past the browsers could have already used whatever, I mean, implemented something like this but I think so that this is why it's the deployment model that is creating waves and not just protocol in itself.

>> AUDIENCE MEMBER: Yeah, Peter again, and so while I like conspiracy theories, I think there are some details or some facts that have been mentioned or should be added to this. There are alternative mechanisms to do DNS traffic encryption. One is called DNS-over-TLS and Vittorio had that on the slides, and one of the problems is that, and that's probably in relation to the concentration and consolidation that was talked about and web is easy and everything else is a bit harder to deploy and to get out in the field because this uses a different port that is, in comparison, a different lane on the road freshly tarred on the road and isn't going to go anywhere. And one of the promises is to be censorship free, and I don't think that was the best marketing, and that separate port could be easily blocked by whatever entity and so there is some -- while I don't really like the idea to have DNS on top of HTTPS because there is DNS underneath and on top that feels a bit weird from an engineering perspective, at least, and there were some operational reasons to go this way, but there are still efforts underway to support DNS-over-TCP that has advantages we could talk about in technical community, but it's the encryption thing that would not necessarily counterweight or prevent concentration in itself, it's the blocking opportunity, in that case, port blocking that was the driving force, I believe.

The other is if all you have is a hammer, which is if you're a web programmer, HTTPS is what is in your veins, so that is the other reason. No offense though.

>> AUDIENCE MEMBER: Yeah, a lot of rationale I've heard and that's from a content network providers, they say well we're catching all of this web information anyway, so we might just as well catch all the DNS so it shaves off two microseconds or nanoseconds from -- so it enhances the users' experience, you know, but fill in the blanks.

This -- this one aspect of which -- on this whole discussion since DLT was mentioned, there is one thing that you cannot do as a user and to validate whether the answer you get from the DNS is correct, whether it's because of DoH, because it's already been resolved. If you do DLT, which is also a channel, but you still can't do the things like validate the answer with DNS, which is something you really need -- you can do as a user yourself, it's not up to the DNS provider, and then you believe that he's actually doing the DNS properly or not, so that's a big difference in the security as well. But that's maybe too technical, but anyway it's part of -- is aspect of it itself. Even if you do DNS, if somebody else is doing the resolve, they could lie to you because you cannot do the validation.

>> VITTORIO BERTOLA: Okay. Are we going to go -- I just know we have three or four minutes left and then I will go the floor for Ilona for report, so if you want to say anything, speak now.

>> AUDIENCE MEMBER: Just a quick response to that, and the thing is in my opinion, this is basically a mislabeled discussion. It's not about -- it's about a number of different things happening at the same time, and always just convenient acronym that happens to be around that people attach to, and so it's really about deployment at centralization, it's about encryption which comes with DOE, it's about whether software like the browser or applications should get to set their own policies or inherent them from Os and whether the users should have control of these things at all. It's about the latency -- so it's lower latency, which you know, it makes the web people cache more things like even the DNS queries, and it's about the desire of the web people to use the tools that they're familiar with, like HTTPS, and it's very easy to go forward with that, it's very powerful, I mean I use it every day also, and so it's understandable and it's also about the browser's ability to do things -- you know, they can go faster ahead than the rest of the community, so all of those things together.

>> AUDIENCE MEMBER: Can still change the terminology into DNS in the Cloud which is actually better description of what it is, what the problems is, and what IETF, just in case people also discuss with this as well, these are called DNS in applications because it's really defined by the application of what's happening there and that's where part of this discussion takes place.

>> VITTORIO BERTOLA: Yeah. I agree. By the way, this terminology is also being described. DNS in the Cloud makes it seem like it's a part of architecture, so this being service, Cloud service, distributer, it's really about having any kind of server, even just a single one but remotely irrespective of where you are, but the part of the world we also maybe need to standardize the terminology.

So I don't see any other person that wants to speak, so if there is no one else, I will give the floor to Ilona. Yeah. She needs the mic, so please.

>> ILONA STADNIK: Thank you. Just a small disclaimer. Everybody can have the opportunity to comment on the messages afterwards, so you just have to contact the EuroDIG Secretariat and they will reach out to me.

So, I will try to summarize very briefly the overall discussion, so the first point is that DoH protocol offers a particular level of freedom for users in choosing the way DNS will be resolved for them, as well as provide more privacy by encrypting DNS queries.

Any way there are significant drawbacks like concentration of DNS traffic enhance of relatively small amount of remote DNS providers, as well as possible pre-determination of at least DNS resolvers in applications and this is the first one.

The second is another problem with DoH that leads to policy debates is how to ensure that the local content is still under reasonable control. We should keep in mind that what works on the scale of the whole state is not working for a particular user, so we need to think about balanced policy with alternative options available, who we prefer to test in resolving the DNS for us.

The final is about the involvement of stakeholders, so all stakeholders should participate in discussion about DoH deployment and policies, creation of a particular code of conduct for resolving services with standardized requirements for it and data protection might be a good starting point.

Any objections?

>> AUDIENCE MEMBER: I'm sorry, on the first one I think you said --

>> ILONA STADNIK: Provides users with a particular level of freedom for choosing the DNS resolver.

>> AUDIENCE MEMBER: (Speaking off mic)

>> ILONA STADNIK: That's why it's a particular level of freedom. If you have a better wording, I'm ready to fix it.

>> AUDIENCE MEMBER: (Speaking off mic) I would suggest that we say it can or it could, but not that it will.

>> ILONA STADNIK: It can or could.

>> AUDIENCE MEMBER: Yeah, because it depends entirely on how the application, as we heard earlier, chooses to roll out the DoH within their application and it could be totally -- it could be totally lack of choice or it could be anything you want or anything in the middle.

>> ILONA STADNIK: Okay. So it could provide a particular level of choice. Okay. Any other?

>> AUDIENCE MEMBER: Yeah, I don't know maybe which list anyway?

>> AUDIENCE MEMBER: (Speaking off mic)

>> VITTORIO BERTOLA: Yeah. So if you want to send the list to the workshop organizing list, we at least the people on the list, more people can join it, it's public so there was a main list which was just for organizing this panel, so it's like five or six people like Peter and others, and so maybe she can send it to the list and we can have a look.

>> ILONA STADNIK: Anyway, it will be on the EuroDIG Wiki so it will be public for everybody.

>> VITTORIO BERTOLA: Okay. Thank you for doing this because this is also not an easy matter and very hard to understand.

>> AUDIENCE MEMBER: Vittorio, one organizational question, what's the deadline for comments on the messages?

>> ILONA STADNIK: I'm not sure about the particular date, but this message will be online like in a couple of hours so until the end of the week, I suppose.

>> AUDIENCE MEMBER: Okay. Thank you.

>> VITTORIO BERTOLA: Thank you. Thank you all for coming. I think we can go to lunch.

(Applause)

(Session completed at 12:28 PM Local Time)


''This text, document, or file is based on live transcription. Communication Access Realtime Translation (CART), captioning, and/or live transcription are provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings. This text, document, or file is not to be distributed or used in any way that may violate copyright law.

''[[Category:2019]][[Category:Sessions 2019]][[Category:Sessions]][[Category:Technical and operational issues 2019]]