 Welcome again, this is Stéphane Bortmaier from Avniq. He's going to update you or if you've never heard and talked before, inform you in the state of DNS privacy. As soon as I... Yeah, exactly. So, hello. So, there have been a lot of talks at first demo everywhere about many aspects of internet privacy. For instance, on web privacy, you've read a lot of papers, a lot of talks. But DNS privacy is still today something which is typically forgotten by most people when they talk about privacy. For instance, I tried to get national data protection authority in France interested in DNS privacy and until now I failed. Part of the reason is because I'm very busy with the web privacy today. There are already a lot of work but DNS privacy seems to many people a technical detail. So, but it's not, of course, they can imagine. So, the biggest problem of DNS privacy in one slide, first is DNS protocol is unclear most of the time. Today, most of the internet traffic is encrypted. I hesitate to say most of the internet traffic because we don't really know but, for instance, Firefox telemetry reports that now typical Firefox sees around 70% of HTTPS, 30% of HTTP. And, of course, many people go through VPN, IPsec, etc. So, most people now manage their machines with SSH and not Telnet. So, you can probably say that most of the internet traffic is encrypted today which is good but DNS is still unclear most of the time. That's a problem. Also, DNS is too talkative. A typical example is that too much information is sent for instance the fully qualified domain name FQDN which is something that something that something that something else that example is sent to all the authoritative name servers starting to the root. So, if you have access to the pickup of the root name servers which is quite easy if you are, for instance, a DNS org member you will see that a lot of requests go to the root even if they are not necessary. I mean, the root knows only about the TLD so there is no need to send the complete fully qualified domain name. On speaking of that, all of the DNS tutorials for dummies that you can find on YouTube are wrong because on all DNS videos that you can see on YouTube you can see the DNS request sent to the root is only the TLD. This is not true. A real resolver today send a complete fully qualified domain name. So DNS is too talkative and some requests are very, very revealing. If you run TCP dump or similar program on your authoritative name servers or resolvers you will see for instance that there is at least this is a real example there is at least one bit torrent client which request a SRV record, so this name for the domain it is in. This is typically information that many people will regard as sensitive. I mean, I could sell this to MPA or organization like that this guy is using bit torrent, it's bad. So some people believe that most DNS requests are not sensitive for instance a request for googleanalytics.com is not really sensitive because unfortunately all the websites are using googleanalytics so it proves nothing. But other request are much more damaging and of course even some very perfectly legal domain names can be sensitive. Also an important point about the DNS is that many people forget it is that the DNS request travel outside of the normal path. For instance, if you are a French user in France and visiting a French website you may assume that all your traffic stays inside the French border and so is subject to European data protection laws etc. This is not completely true because you know that routing on the internet is something complicated traffic between a French client on a French hosting provider may go through AMSIX in the Netherlands or links in Great Britain but because of the DNS it's even worse than that because the request for the DNS will go in much more autonomous system than the typical connection between Alice and Bob. For instance, if the domain name is .com you will go to the very sign name servers which probably do not abide by the European data protection laws. There have been some surveys I think that Laura Roberts from the University of Princeton did a very good survey of how many AS autonomous systems or basically network operators how many autonomous systems are traversed by a typical DNS request and it's typically two or three times the number of AS crossed when you go from the HTTP client to the HTTP server and it can be a problem because many people forget about it and many people don't have what I could call DNS privacy sensibility another survey by the people of the University of Princeton showed that one third of Tor exit nodes are using Google public DNS as a resolver so you set up a Tor exit node because you care about privacy and then you configure Google public DNS as a resolver In one way it's normal because when you are a Tor user you cannot be sure of what the exit node is doing but it typically shows that most people are not really aware of DNS privacy issues I have to keep clicking on some key from time to time For instance, things like Schengen routing the idea that you can limit the traffic inside European countries with proper data protection laws it's very difficult in general but it's even worse in the case of the DNS So what have we done to limit the problem to tackle the problem? As far as I know the first time that DNS privacy was mentioned in an official meeting if I say was in June 2013 at the center with the association of European TLD registries and there have been a talk about DNS privacy is it important, does it matter? At this time even center members who are all professional of domain names were not aware of the issue So it was a beginning and funny enough almost the same day some American guy flown from Hawaii to Hong Kong and settled in a hotel room and then called journalists to report about that there was some organization which was actively surveying the internet So inside this revelation one of the program was not okay, battery down already Inside this revelation there was one program which was missed by most people it's called Morcobel and Morcobel is the surveillance using the DNS it has several parts in Morcobel like all the NSS slides it's quite difficult to understand what's going on but apparently they use both active reconnaissance and the DNS and also passive surveillance by watching the DNS traffic So we were not the first to notice that DNS is good for surveillance NSS noticed it before So November at the IATF meeting in Vancouver it was the beginning of a project about increasing DNS privacy it was quite informal at this time but most IATF, if you've never been to IATF meeting you have formal meetings, working group meetings which are typically quite boring and then people gather outside of the rooms and drink beers and this is where the actual work is taking place So for instance as often in the internet code comes before specification that's a usual way of working So for instance in March 2015 if I'm correct the library get DNS which was presented by Wilhelm a few minutes ago already implemented DNS over TLS allowing you to encrypt DNS traffic In August 2015 release of the first LFC about DNS privacy 7626 which is the description of the problem it's not a solution the general way of doing things at IATF now is first to describe the problem then to find out solutions In the real world it's more rewrite code then we maybe write specification and at the end we document the problem but if you want to know about DNS privacy if you want a reference which is much more detailed than this talk you should read this RFC Then in October 2015 Unbound Resolver also at DNS over TLS actually it's already added a long time ago using non-standard things but this is a time where it switched to the official port for DNS over TLS which is 853 So if you see traffic on the network directed to port 853 it's DNS over TLS Next year one way to improve actually DNS privacy was RFC 7816 which is minimization of the queue name as I said today almost all the DNS resolvers send the full DNS query to the root and then to the authoritative name servers The idea of this RFC is stop doing it send only the minimum when you talk privacy to typical engineers they have only one answer encryption that's a solution to every problem Actually encryption is a very good thing encrypt everything I agree but it does not protect against anyone for instance it does not protect against the endpoint doing HTTPS with Gmail is pointless if Gmail sends your data to the NSA they won't do it of course but if they do encryption won't protect you So when you talk about privacy you need actually to do two things minimizing the data sending less data collecting less data and also encrypting it in transit to protect against the sniffer So the idea of this RFC is stop sending to the name servers everything send only what they need to know So for instance the root name servers because they know only about the TLD they should be asked only a query for the TLD not that bitter and that something that something that example Same year specification for DNS over TLS remember that there was running code before but ok so DNS over TLS the idea is to encrypt DNS traffic of course running on a specific port and it's also standardized only for the stub to resolver link remember the talk by Wilhelm about get DNS this morning get DNS is for the stub which is the part which runs on the user's machine then the stub talks to the resolver which is typically managed by your ISP or your university and then it goes to the authoritative name server So DNS for TLS at this time is only standardized for the stub to resolver link part of the problem is that resolver to authoritative makes authentication more difficult because you one stub talks to only a few resolvers but resolvers talk to thousands of authoritative name servers and then also there is this option padding because one of the big problem of TLS is that TLS makes no attempt to disguise the size of the answer there have been many scientific papers about how you can find out what people are doing even when they use Https for instance when you visit Wikipedia with Https you can find out what page were requested because the size is not disguised so someone who wants to know about you can do the same request get the size of the files you get and then knowing what you are visiting if it is something that is public and of course the DNS is public so just using DNS over TLS may not be sufficient if you don't do some padding which means that you fill packets with useless bytes so this is the past no, not completely also in July 2017 it was a release of stubby William talk to you about stubby it's a diamond that you run on your end user machine with forward request over public or other resolvers I didn't mention system D resolves because as far as I know they did nothing for DNS privacy yet so this is the past now the present, what is the current situation on the technical standard side we are not completely done there are still things to do but we have already a consistent set of technical solutions to improve DNS privacy especially the two things I was mentioning minimizing data and encrypting it we have LFC for that so we have at least a standard now a standard of course is not sufficient you have to implement it so you need running code so we have running code we have running code in servers such as a note on unbound we have running code in libraries such as getDNS mentioned this morning or if you prefer to program in Go yesterday I was at the Go Dev Room it was completely full it was closed the morning it was closed 30 minutes before we started because Go is a very popular language and there is a very good library to do DNS in Go written by a Dutch guy most of the DNS code is ever Dutch or Cleck and Go DNS is a very good library with a lot of features and DNS over TLS among them so we have running code but sometimes this code is a bit rough if you take for instance unbound DNS resolver unbound can talk DNS over TLS to an upstream server but it creates a new TCP TCP on TLS sessions for each request which obviously doesn't scale when you have a lot of traffic it's clearly a problem so this is the sort of thing that has to be improved also this is a code TLS is used a lot of course but DNS over TLS few people are using it so probably there are many bugs still waiting to be discovered so some work on the code is necessary also as far as I know there is nothing in bind but I certainly hope that André will fix that and add all the sort of interesting privacy features in bind we have also at least one big public resolver which is using DNS over TLS it's called Quad 9 because the IP address well if you use the old IP protocol the one in the the very old IP protocol where the addresses where only 32 bits the address is 9.9.9.9 there are also an IPv6 address but it's more difficult to memorize it so Quad 9 is already working as Peter remembered this morning the DNS over TLS support is not official so Quad 9 is officially supported but DNS over TLS it's not even documented you have to discover it by Nmap but it works and also there are a few other small one for instance LDN which is not for profit ISP in the east of France they provide a public DNS resolver with DNS over TLS so we have some possibilities we have queuing minimization in at least two resolvers and bound on not in the case of not it's by default in the case of unbound it's not by default you have to edit the configuration file if you use unbound directly from upstream but most people of course don't type configure make et cetera they use a package for the operating system so if you use Debian for instance Debian package of unbound comes with default with least queuing minimization so in that case it's better measurements for instance with wipe at last probes which I mentioned this morning limiting yourself to Europe where probably people are more often using these sort of features only two percent of the probes in Europe see other resolver with queuing minimization so we can say that the deployment actual deployment is close to zero at this time ah we have a website very important we have a website actually an information portal so if you want to know about DNS privacy the standard the code the servers the papers et cetera et cetera you have only one point to visit which is dnsprivacy.org but the actual deployment is very limited so encryption is very rare queuing minimization also so we are quite late when you compare to the HTTP people for instance the future now we have several RFC which are almost done one is authentication of the DNS over TLS resolver at this time the only standard way is by key pinning remembering the key and using it which is of course quite brittle for instance quad 9 change its public key on Friday when renewing the ransomcrypt certificate and they got a new key breaking authentication so in the new RFC which will be published in the next few days we will have several methods for authentication of DNS over TLS resolver this one is almost done there is also one on padding profiles padding is great but you have to know how to pad I have seen sometimes software padding to defeat traffic analysis for instance padding with a constant length of padding every request was pad with the same amount of bytes which is obviously useless so there is an entire RFC dedicated to what are the clever ways of padding and this one is also almost done so it should be published in the next months ah time to mention GDPR nobody did yet so May is also an important moment because at the time where the GDPR comes into force at this time all the people who are walking talking panicking over the GDPR never pay any attention to the DNS so we can safely say that in if we are DNS professional we won't see lawyers in June asking to us about DNS privacy what are we doing do we really do everything what is to be done according to the GDPR but in the next months or next years maybe people will start paying attention and I suggest that it's better if we do something about DNS privacy before the lawyers came in there is also some work at the IETF unlike the two first RFC which are close to be over the next this work about encrypting the resolver to authoritative link while it's far from being done so it's not even clear if there is enough interest, esteem etc to work on this we will discuss this at the next IETF meeting in London next month speaking of running code Android as code for DNS or TLS it's already committed in the public repository of Android but it was not in Android released version yet and also there is DNS over ATTPS which is a standard IETF and unlike the encryption of resolver to authoritative link it seems there is a lot of interest for DNS over ATTPS because one it goes through firewalls unlike port 853 which may be blocked and also it allows JavaScript developers to have the full power of DNS so DNS over ATTPS seems interesting for a lot of people and at the next IETF meeting in London in March there will be a hackathon as always and probably a lot of people at the hackathon will work on DNS over ATTPS we have so as I said we have several bricks for DNS privacy one interesting point is how we put these bricks together for instance what resolver, where should we validate with DNS stack where should we encrypt which resolver should we use ordinary people today use the ISP resolver which may be a problem because most of the time they don't have DNS over TLS they don't do QNEM minimization they don't know what they do with data so you can have another solution is to have a stub running on your machine talking to a public resolver like Quad9 Quad9 has DNS over TLS but what do they do with the data that you give to them you don't know actually there is a public policy it's funny when you read the privacy policy of Google public DNS on Quad9 they are exactly the same down to every bit so someone copied the other I don't know which one and all of them promise a lot of things but it's hard to know if they stand by their published policies also you can do things locally you can buy a Raspberry Pi install openBSD unbound the stubby everything on it and do everything locally the good thing is that you control everything the bad thing is that first it's today it's a bit too difficult for the ordinary user especially the openBSD part and also it does not completely protect you because then all your request to the authoritative name servers will come from your own IP address so on a privacy point of view it may be not always the best solution but several solutions are possible for the first part the difficulty one possible solution is to have everything in a box ready as a teresomnia for instance the teresomnia comes from such a resolver also you can have a mix of several solutions a possible solution for instance to have stubby one good thing about stubby is that it can switch between several public resolvers so you still untrust these resolvers with your data but you spread it on several resolvers on the next version of stubby if I'm correct we'll be able to analyze the choice of the resolvers so today it's done in a round-rabin fashion also should we use DNS over TLS or of course should we run everything over port 443 which is allowed by DNS over HTTPS this is for them so people are supposed to know that we have to work so we need you most of the standard work is done there is still work to do but most is done but we need code so for instance now that the buying code is on the GitLab public you can send pull request to add privacy features to bind and of course code is not enough you also need deployment so do it just do it and of course we need outreach talking to people talking to data protection authority to data protection officers etc about the importance of DNS privacy on what to do so yeah it was a bit long but still maybe I have sometimes for one or two questions there yes hello Stefan thank you very much for your wonderful presentation now that we're all here first I want to say we really DNS test also has a TLS module you can put DNS test and it will gain high performance TLS for DNS but you can also use HAProxy as well but this is sort of more closer to DNS and the other thing could you go back to slide number 6 Android released with DNS over TLS client wonderful news wonderful news we must all deploy DNS over TLS ourselves Android and Google are not our friends in this way as you noted the encryption to Google is fine what happens then we don't know what we do now is that eventually they will say ah your provider has weak DNS privacy your Android phone will now connect straight to Google for DNS and they're open about it this is the plan and it's all great for privacy for everyone super wonderful and nice this brings me to the excellent Google privacy policy on DNS it is excellent, it is true the people that work there guarantee me it is true it says nothing about tomorrow the whole page says your privacy DNS or Google is fine right now until the page is tomorrow so they say nothing about we will give you a year of warning restart data mining your stuff nothing about it in there so eventually someone over there could wake up and say glories data don't use this so my call to you everyone if you work at a service provider I see a few of you here please deploy DNS over TLS as soon as you can because we do not want to have this situation where Google can legitimately say please give it more of your data so we can protect your privacy back just a word about the third party the problem of sending your DNS carries to Google or to a specific central community like the public there are actually several alternative DNS routes like OpenNIC, OpenRoad New Nations and maybe you have some opinion about this kind of alternative DNS routes OpenRoad will be fast pure scam nothing so there is nothing to say it's a pure scam for OpenNIC it's a bit more complicated they use a non-standard encryption so it's I don't like that because I prefer standard solutions where there is interoperability where you can choose your software and also it's the mixed privacy with with other things that I want to promote and typically it's alternative route which means that they also add their own TLD which may collide with other TLD so it's in my book it's not good last question you mentioned the APR in the context of that in terms of ISPs and Wi-Fi providers are they likely to I think they would be affected by this in the sense that first of all GDPR means that they can only do what's needed to revive the service so like some of the ISPs need old issues too for typo domains like adverts and stuff that wouldn't be allowed but also are they going to be likely required to for example prefer upstream internal EU servers for example RIT servers prefer using EU-based RIT servers versus US-based RIT servers either in preference or in fatality to fit in with that because the data was kept within Europe and on the other side of it whenever an ISP commons across the board that's going to present problems within countries because for example in the UK we have the government dated DNS blacklists that by law the ISPs have to enforce but if everything's encrypted and the ability of me to not use my ISP direct I can see the pushback where ISPs will be required to prevent me from not using their upstream server so then they can actually do this blacklisting before the government there are two things one is for GDPR I'm not a lawyer but my guess is that it will several years before the lawyers or the DPO or the data protection authority will really go into what's going on in the DNS at this time we are a lord and most people won't be interested in DNS before sometimes so we don't have to expect a big change in May for the DNS guys I mean still some of the provisions of the DNS privacy project are very well aligned with the DPR typically CUNY minimization is sending only what you need so it's a good idea to do it now for the risk well this the rest is more a political problem indeed one of the risks in the future will be ISP blocking port 53 or 853 because they want to monetize your data or because the government wanted to do so it's possible or even interfering with DNS resolution like it's already currently done in China for instance that's one of the motivations for the DNS over HLTPS project and there is even some reflection about how to make DNS over HLTPS indistinguishable from other HLTPS traffic precisely to address these sort of issues but it's more a political problem for instance blocking port 53 for me it's a net neutrality problem before everything before the DNS privacy problem thank you