If anyone wants the draft RFC:
https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh...
Improving DNS Privacy with Oblivious DoH
111–120 of 367 posts
Re: Improving DNS Privacy with Oblivious DoH
#112Earlier quoted context omitted.
All I see is a proxy service and a way for cloudflare to get access to the data
Do you want Google and your ISPs to see everything? Cloudflare and maybe Apple (not sure what infrastructure they’d have in this if any)? Another company like Cloudflare? I don’t know the answer but I’m curious to hear everyone’s thoughts. Personally I’d like to prevent Google and my ISPs but Cloudflare could easily become Google in many ways.
[deleted]
Re: Improving DNS Privacy with Oblivious DoH
#113REMINDER: 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.
Re: Improving DNS Privacy with Oblivious DoH
#114The 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.
Re: Improving DNS Privacy with Oblivious DoH
#115This 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…
Well, this could probably encourage the creation of privacy-oriented proxys (they just have to forward queries, so it should be relatively inexpensive compared to a full DNS server). What is the likehood of someone getting logs from Cloudflare (who promises it does not keep logs, but let's assume it does) and at the same time hacks into some random privay-oriented organization?
Of course, one might imagine a State actor using all their resources to do just that. But this would be a very complex attack. At least, it would stop all kind of ad tracking.
The worst part of this proposal is that it will further centralize the DNS infrastructure.
Re: Improving DNS Privacy with Oblivious DoH
#116Opened 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.
I would like someone to correct me if I am wrong, but I think we can never have 100% privacy because the destination IPs cannot be encrypted or hidden, so as long as the destination IP can be observed, the server that you are connecting at can be obtained (I know a server can host many web pages, but this requires the port, which cannot be encrypted either). So I don't know to what extent this protocol can be useful.
The only solution is onion routing AKA Tor and similar.
Re: Improving DNS Privacy with Oblivious DoH
#117Until 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
No! Solving the SNI problem is far from enough.
The server IP address can be easily correlated with the domain for 90% of Internet traffic.
Re: Improving DNS Privacy with Oblivious DoH
#118Preventing 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.
Valid points, but... > Preventing the target resolver from seeing client's IP address breaks GeoDNS. If the proxy and the target are in the same metro as the user, it shouldn't really matter. > This is already a problem with 1.1.1.1 which doesn't honour the EDNS client subnet extension. 1.1.1.1 runs at Cloudflare's edge. Most likely it is recursing DNS from more or less the same location as the user and so ECS isn't…
[deleted]
Re: Improving DNS Privacy with Oblivious DoH
#119The 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.
Re: Improving DNS Privacy with Oblivious DoH
#120I 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?
2 reasons I can think of. Firstly, Apple loves to act like they are always taking your privacy very seriously (of course that's not always true), so for the cost of a few engineers, they get a massive marketing point. "We take your privacy so seriously that we developed a new protocol to do so" Secondly, Apple has an awful case of NIH syndrome. If they didn't develop it themselves, they would rather develop it from s…
Secondly, Apple has an awful case of NIH syndrome. If they didn't develop it themselves, they would rather develop it from scratch themselves
Not when it comes to security and privacy. They knew DoH and DoT were good, but not good enough when it comes to privacy, which explains why they didn't just implement it like Google and Firefox did.
Instead, the worked with Cloudflare to standardize something that's better.