from Hacker News

Improving DNS Privacy with Oblivious DoH

by websirnik on 12/8/20, 12:33 PM with 349 comments

by dang on 12/8/20, 6:38 PM
All: We changed the URL from https://techcrunch.com/2020/12/08/cloudflare-and-apple-desig... to the more detailed source, but you might want to read both.
by TrueDuality on 12/8/20, 3:45 PM
The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being the sole exception). There also is no good way for enterprises to centrally manage these settings. DNS is a major source of information when doing threat hunting on a network and having that go dark is a big problem.
Enterprises aside, there has been a rise of people using solutions like pi-hole in their home networks to filter out traffic not just for ads, but known malicious domains, and telemetry trackers (which Apple does get filtered by, only calling them out specifically because they have an active interest in not being filtered like this).
Yes I think it's also a problem that ISPs are snooping and selling this information, but I think that is a less severe problem than rampant malware infections and the excessive collection of online usage data in the telemetry systems present in every webapp, OS, mobile, or IoT device. This increases privacy in one place, while making it much harder to actively protect yourself from the more aggressive and invasive sources of data collection.
by Lammy on 12/8/20, 6:28 PM
It bothers me how "privacy" has been redefined in recent years to mean "encrypted" and not "surveillance-resistant". We keep building things that make more requests I can't terminate locally, e.g. to a PiHole.
Never forget the lesson in "Using Metadata to find Paul Revere": https://kieranhealy.org/blog/archives/2013/06/09/using-metad...
by crumbshot on 12/8/20, 2:23 PM
This is a neat design, but, does this not just shift the issue of trust as to whether the proxy and the target are colluding:
> However, each of these guarantees relies on one fundamental property — that the proxy and the target servers do not collude. So long as there is no collusion, an attacker succeeds only if both the proxy and target are compromised.
I'm not sure how an end user would be expected to assess this any more than they could ascertain whether any particular DoH/DoT provider is as trustworthy as they claim.
by eh78ssxv2f on 12/8/20, 5:56 PM
What a stark difference between Google and Apple/Cloudflare.
Apple/Cloudflare are working on privacy-friendly protocols that reduce the amount of information exposed to them.
At exactly the same time, Google is working on proxying browser traffic through them without any consents [1].
[1]: https://news.ycombinator.com/item?id=25337995
by landerwust on 12/8/20, 1:08 PM
Opened this post expecting to be hating on another power grab dressed up as protocol engineering, but this one seems to actively /reduce/ the centralization of user data collection in DoH. Props to Cloudflare, I'm impressed.
by ignoramous on 12/8/20, 1:11 PM
Key bits from the Cloudflare blog https://blog.cloudflare.com/oblivious-dns/
> The target [resolver] sees only the [DNS] query and the proxy’s IP address. The proxy has no visibility into the DNS messages, with no ability to identify, read, or modify either the query being sent by the client or the answer being returned by the target. Only the intended target [resolver] can read the content of the [DNS] query and produce a [DNS] response.
> The whole process begins with clients that encrypt their query for the target using HPKE. Clients obtain the target’s public key via DNS, where it is bundled into a [SVCB/HTTPS] HTTPS resource record and protected by DNSSEC.
> Clients transmit these encrypted queries to a proxy over an HTTPS connection. Upon receipt, the proxy forwards the query to the designated target. The target then decrypts the query, produces a response by sending the query to a recursive resolver such as 1.1.1.1, and then encrypts the response to the client. The encrypted query from the client contains encapsulated keying material from which targets derive the response encryption symmetric key.
> ...50% of the time ODoH queries are resolved in fewer than 228ms.
BTW, DNSCrypt supports "oblivious" encrypted DNS queries via what it calls Anonymized Relays https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-D...
by darkwater on 12/8/20, 1:49 PM
Until we get rid of SNI[1] in HTTPS for good there will still be providers (like my ISP) that do deep packet inspection on SNI and kill the connection right away if you happen to visit a forbidden site (and this was western Europe, yesterday, on a site behind CloudFlare)
[1] https://en.m.wikipedia.org/wiki/Server_Name_Indication
by jamescun on 12/8/20, 1:35 PM
Preventing the target resolver from seeing client's IP address breaks GeoDNS. This is already a problem with 1.1.1.1 which doesn't honour the EDNS client subnet extension.
Given generally DNS is just the start of an intereaction, usually followed by the connection directly between the client and intended destination, I don't see what kind of snooping these privacy measures are there to prevent.
by ksm1717 on 12/8/20, 3:06 PM
Interesting that apple is increasing its stake in privacy. On all their billboards and advertisements of course they like to present it as a boon to the customer. More importantly, I think it’s a negative for personal data hungry competitors while being relatively unrelated to Apples business
by londons_explore on 12/8/20, 1:23 PM
When you need a log-log plot to make the performance degradation not look so severe, you have issues...
by akvadrako on 12/8/20, 3:28 PM
If anyone wants the draft RFC:
https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh...
by g42gregory on 12/8/20, 5:08 PM
Do I understand this correctly that if DoH is implemented, none of the firewalls will be able to block the web sites? Including the pi-hole firewalls, as an example. If that's the case, this situation can't stand for long. Does this meant that the DoH would need to be extended to allow firewalls to decrypt it?
If not, here is a PaloAlto Networks blog advertising capability to block all DoH traffic, presumably at work [0]. It looks like you might not be able to use DoH at work, the way it currently stands. I wonder what would be the right solution?
[0] https://live.paloaltonetworks.com/t5/blogs/protecting-organi...
by joshspankit on 12/8/20, 2:42 PM
I understand why Cloudflare wants this (marketing, as well as being able to serve their customer’s content through restrictions, thus making them more valuable to those customers),
but why does Apple want this?
My knee-jerk is that they want to further hide/make unstoppable things like the Gatekeeper network checks, but there has to be more right?
by benlivengood on 12/8/20, 6:10 PM
Metadata privacy is very hard to solve and traffic analysis of non-Tor traffic is pretty accurate, which is also applicable to CDN traffic regardless of how well DNS is protected.
http://ceur-ws.org/Vol-1158/paper2.pdf
by anonypla on 12/9/20, 10:37 AM
One should also note that, even if you use ODoH, eSNI and even Tor (or any VPN service), your ISP could still reliably fingerprint your web access activity at the source using deep learning with over 96% accuracy as shown in this study (https://distrinet.cs.kuleuven.be/software/tor-wf-dl/).
So while ODoH is a good thing (and also recommended in this study which has shown the weaknesses of DoH/DoT https://www.esat.kuleuven.be/cosic/publications/article-3153...) and is very similar to DNS over Tor with a DNS hidden service resolver (which Cloudflare also provides). It won't prevent a skilled and motivated adversary from determining your activity and possibly apply censorship.
I would guess that a solution to mitigate these would be to use an hybrid solution of VPN over Tor (or Tor over VPN) while also using DNS over Tor or ODoH and eSNI.
by jlgaddis on 12/8/20, 6:30 PM
Even better, IMO, would be if all targets were also proxies and a client could choose -- at "query time" -- any combination of (proxy, target) that they prefer.
If you wanted to go a step further, you can even allow "chaining" of proxies, such that the path a query takes might be, in an extreme example, similar to how Tor operates:
```
  Client -> Proxy 1 -> Proxy 2 -> Proxy 3 -> Target -> Resolver
```
--
Anyways, this is kinda sorta interesting, I guess, but honestly I'm more excited by and looking forward to the (hopefully!) eventual adoption and roll-out of "DNS SVCB and HTTPS RRs" [0] -- one of the other I-Ds (linked in the OP) on which ODoH is built -- and I suspect many other HN'ers will be as well (although I'd happily settle for SRV RR support in browsers).
--
[0]: https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02
by geogriffin on 12/9/20, 1:13 AM
Why encrypt the first hop? Why isn't this just plain DoH with a simple CONNECT forward proxy to 1.1.1.1, like Signal's Giphy proxy [1]?
[1] https://signal.org/blog/signal-and-giphy-update/
by clashmeifyoucan on 12/8/20, 2:03 PM
I'm wondering how they still get good performance with a proxy server in between, the plots seem quite close to each other (maybe because logarithmic?).
Also, not sure how useful the Tor comparison is, since Tor does 3 hops as opposed to their 1 so it would be a shame if it doesn't beat that.
by pcwrt on 12/9/20, 9:41 PM
Serious question, why do we need ODoH at all? Isn't a plain proxy good enough to achieve this? https://www.pcwrt.com/2020/12/oblivious-dns-over-https-vs-do...
by izacus on 12/8/20, 1:45 PM
So Google got sued by ISPs which lobbied an investigation by DOJ for trying to encrypt DNS: https://www.engadget.com/2019-09-29-congress-doj-scrutinze-g...
Will ISPs be too scared to sue Apple and Cloudflare for this? Or are they giving them an out?
by mlegner on 12/8/20, 3:35 PM
The basic idea makes sense to me and it's great to see efforts to improve DNS privacy. However, I'm not really convinced by Cloudflare's analysis of the processing overhead:
The blog post only discusses how the proxying and encryption affect latency but not the processing at the server. In contrast to plain DoH (or DoT), where only symmetric cryptography is used after the first set-up, ODoH requires asymmetric cryptography (which is several orders of magnitude slower) for each individual request. The "less than 1ms" that they claim for the 99th percentile is no problem for the client but it is a problem for the resolver. Asymmetric cryptography is also used for verifying DNSSEC responses, but this is only necessary for records that are not cached.
On the other hand, an ODoH resolver may require to set up and keep track of a lower number of TLS connections as the number of proxies is likely smaller than the number of clients.
by gwbas1c on 12/8/20, 2:27 PM
I suspect that practical matters will interfere with widespread adoption of encrypted DNS.
In my state, Comcast is going to start charging heavy bandwidth users extra. After a few people get surprise bills, I suspect that lawmakers will require that internet providers break down a bill by application.
by thrwaway2020aug on 12/8/20, 2:25 PM
I'm surprised to see Cloudflare and Apple collaborating on privacy.
What does Cloudflare think of Safari's new CNAME-cloaking detection to block cookies? https://webkit.org/blog/11338/cname-cloaking-and-bounce-trac...
The reason I ask is because Cloudflare's "orange cloud" DNS mitigates that protection because it prevents Safari from detecting the cloak. On the other hand, I haven't run into many engineers who think CNAME-cloaking actually hurts privacy in light of Safari's other efforts to partition local storage.
Does Cloudflare think it would be help privacy for Apple to know the final IPs behind orange cloud DNS?
by John_Westra on 12/8/20, 3:11 PM
I would love to see Firefox be an early adopter of this, regain market share and save us all from Chrome!
by TimWolla on 12/8/20, 1:09 PM
So, having read the blog post from Cloudflare I don't understand why the proxy (needs to terminate|terminates) TLS.
I thought HTTPS proxying (or rather: Any TCP protocol) was a solved problem by the HTTP CONNECT verb or SOCKS proxies.
What am I missing?
by karmakaze on 12/8/20, 4:44 PM
In a nutshell: client encrypts to proxy, which decrypts & removes client info, then asks resolver.
> “What ODoH is meant to do is separate the information about who is making the query and what the query is,” said Nick Sullivan, Cloudflare’s head of research.
> In other words, ODoH ensures that only the proxy knows the identity of the internet user and that the DNS resolver only knows the website being requested. Sullivan said that page loading times on ODoH are “practically indistinguishable” from DoH and shouldn’t cause any significant changes to browsing speed.
by CyberRabbi on 12/8/20, 5:11 PM
All security theatre while SNI is still universally deployed. Even then most IP blocks are static and easily correlated to source site.
A tor-like solution is the only real solution for this threat model
by MrStonedOne on 12/8/20, 1:45 PM
So I do wonder how such systems can be designed or implemented such that geoip systems can still work.
While I'm sure aws route53 and cloudflare's own routing systems can handle this properly, Cloud isn't quite the answer. Not every workload fits on the cloud (see: Discord, which runs on leased servers), and a system that breaks down if your rented datacenters aren't in alignment with Cloud operating regions doesn't make a great solution.
by ajnin on 12/8/20, 6:12 PM
At what point should we just throw out IP out of the window and figure out something new ? OK maybe not IP since all hardware infrastructure is based on it, but the whole idea of associating services to publicly open ports on the target machine. I'm thinking connections should be encrypted at the operating system level and then services would plug in at some higher level in a way that cannot be detected by outside observers.
by OJFord on 12/8/20, 7:59 PM
What's the advantage of this over specifying a DoH provider (as we do today with plain DNS)?
Unfortunately I suppose the only way to really do that is with a resolv file (adlist/blocklist) of DoH hosts (which exist) but instead of pointing to 0.0.0.0, point to <preferred DoH>.
Edit - d'oh! I see it now - that would mean DoH provider knows query and IP, whereas here the ODoH proxy knows your IP but not the query. Nice.
by nuker on 12/8/20, 1:47 PM
Why not DoT? And DoH is mum on http cookies: "Determining whether or not a DoH implementation requires HTTP cookie support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP." https://tools.ietf.org/html/rfc8484
by dj_mc_merlin on 12/8/20, 9:24 PM
Is it not still possible to do a pi-hole kind of setup for DoH or ODoH? All you have to do is setup the server as a proxy for all http(s) connections on top of DNS connections and trust its cert on the client. If we can reliably block all ad networks with uBlock origin, picking out DNS requests from other http requests should be even simpler, right?
by hkt on 12/8/20, 11:13 PM
DNS privacy for DoH effectively means we all lose the ability to control what our devices are connecting to. In particular, we can't block ads and trackers at the network level. The lack of fallback to regular DNS in the spec means we will choose between devices that track us while they work, or devices that are broken.
by tie_ on 12/9/20, 7:37 AM
No discussion of DNS privacy should go without a link to Bert Hubert's awesome talk on the subject: https://www.youtube.com/watch?v=pjin3nv8jAo
by new23d on 12/8/20, 1:37 PM
> ODoH ensures that only the proxy knows the identity of the internet user and that the DNS resolver only knows the website being requested
Who is the proxy here, and who the DNS resolver?
by phlhar on 12/8/20, 6:27 PM
The title of the article is really misleading. I though of a succesor to IPv6 and not DNS. It shouldn't say "internet protocol", thats technically not correct
by elliottinvent on 12/8/20, 11:41 PM
> Cloudflare is committed to end-user privacy.
Pretty crucial hyphen
by dylz on 12/9/20, 5:02 AM
Are ODOH resolvers by any disjoint partner available yet? The only one I see is the CF-owned and run one.
by cblconfederate on 12/8/20, 1:44 PM
> Sullivan said a few partner organizations are already running proxies, allowing for early adopters to begin using the technology through Cloudflare’s existing 1.1.1.1 DNS resolver.
In other words, in order to thwart efforts to make the internet anonymous , US companies are planning to takeover DNS for the vast majority of people.
by seek3r on 12/8/20, 1:04 PM
I’m good with the Apple’s privacy-oriented stance. But I can’t stop to think what will happen when advertisers knock on Apple’s door trying to get their hands on the users’ data that one else can access. Is Apple going to sell it out for more profits?
by exabrial on 12/9/20, 12:20 AM
Hilariously I see privacy invading advertisers loving this. No more DNS blocking ad traffic! And since it's only a matter of time before Apple removes root access on their PCs, it puts them in complete control off what you see.
by aftbit on 12/8/20, 9:41 PM
Can the proxies be (ab)used to proxy arbitrary HTTPS traffic?
by theamk on 12/8/20, 1:38 PM
This seems to require DNSSEC as a key function. @tptacek ?
by ittan on 12/9/20, 1:25 AM
This should be called DOHW, DNS over http made worse.
by nalekberov on 12/8/20, 1:35 PM
The more these big corporations involves in this process, the more we are gonna lose our privacy.
Centralization and too much power in certain amount of hands are the source of all evil.
by cannabis_sam on 12/8/20, 3:03 PM
Has Google produced any similar initiatives?
by TimWolla on 12/8/20, 1:02 PM
Probably better source, the blog post at Cloudflare: https://blog.cloudflare.com/oblivious-dns/
See also: https://news.ycombinator.com/item?id=25344220
by throwaway54235 on 12/8/20, 3:35 PM
REMINDER: Research proves that it's easy to correlate IP addresses in HTTP[S] connections with the domain you are connecting to with a very high success rate.
You can resolve the websites from the Alexa top 100k list and create a ipaddr -> website map that will successfully apply to 90% of Internet traffic without ambiguity.
A lot of research papers also show how easy it is to fingerprint and detect a TLS handshake.
Assuming the SNI problem is going to be solved, the other problems are still here.
TL;DR: use Tor.
by teddyh on 12/8/20, 1:47 PM
Sounds promising. Get back to me when it’s gotten to the RFC stage. A ready-made solution thrown over the wall like this, is rarely what is ultimately adopted.
by jaimex2 on 12/8/20, 2:07 PM
Whats the point?
Governments subpoena the information or just block the protocol outright. ( or in China, get it delivered to their door by Apple )
Commercial parties have a bag full of tricks from fingerprinting to embeds on the page itself to track you.
Privacy seeking users are already tunneling their traffic.
That leaves script kiddies at Internet cafes. TLS kind of fixed that already so... Good work?
by freebuju on 12/8/20, 1:49 PM
Misleading title. Apple devices are not anywhere near ready to utilize this dns protocol. Apart from that, yeah let's shift our dns trust to one of the biggest data resolvers! The irony...
Encrypted dns might be already in use by government or military agencies, but they know too well the effects of cascading this tech down to the masses. They will never let this reach the public.
by zero_deg_kevin on 12/8/20, 6:26 PM
No hubris here at all.
But seriously, fuck this protocol and fuck every other BigCorp-sponsored protocol to remake the Internet. We the People Who Implement Protocols are too busy keeping the lights on to chase incremental, nice-to-have improvements.
by techelite on 12/8/20, 1:13 PM
I urge people to stop repeating Apple Advertising. Claims of privacy and security are debunked weekly. You put yourself at risk if you believe it.