zlacker

What's the actual meaningful difference, though? ECS is limited to a /24 anyways, so, it doesn't even reveal the exact IP address in any case.

>>cnst+(OP)
Thats a good question. How you feel about third parties knowning what endpoints you go to depends on what endpoints you're going to, and why. In some economies, its hugely informing. In many cases its explicitly what BI is -to know what you do, and when you do it.

I don't have good sense of this, but people I trust say a surprisingly small collection of information identifies you to a specific level. same /24 is only 255 people if there isn't a CGN. More to the point, if your /24 identifies your economy, you're now subject to IPR limits and can be told different things.

So some ECS objection is rooted in opposition to regional IPR. Netflix. Sub-optimal CDN delivery (to one person) is wall avoidance (to another)

>>cnst+(OP)
Disclaimer: I work on 1.1.1.1. You might not consider your /24 as personally identifying, but others might. The original RFC discusses these problems fairly well (https://tools.ietf.org/html/rfc7871, Privacy notice and privacy considerations). Frank Denis also wrote a good summary on ECS (https://00f.net/2013/08/07/edns-client-subnet/). There's a multitude of ways to fix this - use a whitelist of nameservers to send ECS to to avoid spraying the source prefix everywhere, encrypt the whitelisted connections, or aggregate the source prefix into a largest covering server scope (e.g. if the client is in /24 but nameserver serves the same answer for /16, then using any address in the /16 would do). We're evaluating all of them as there's different trade-offs (see https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-...).

>>ggm+M
What exactly do you use DNS for? Most folks use it to resolve a domain name so that they can make an HTTP and/or HTTPS requests from the very same IP address over the very same internet connection. Surprise: these subsequent HTTP/HTTPS requests would have your complete identifying information down to the very specific /32 IPv4 or /128 IPv6 address uniquely assigned to yourself.

So, in reality, the extra privacy gained from not doing ECS is hardly something with a measurable effect, because this information HAS to leak in any case. Even if make DNS encrypted, even if you employ encrypting TLSv1.3 SNI, the IP addresses will still leak, and with a much higher precision anyways. So, this we-don't-do-ECS-because-privacy is a rather pointless statement in the end.

>>cnst+W2
+1 @cnst, what privacy concerns are you all afraid of with ECS ? archive.is will get informed that someone around IP range A.B.x.x tries to reach its website, just a few seconds later to see a connection from A.B.C.D.

The main reason that Cloudflare wouldn't share this info is to prevent competitors like Akamai to operate a CDN as good as them. It looks more like sabotaging competition than increasing privacy.

>>rvnx+F5
In practice this is one of the most common techniques used to deanonymize proxy users.

>>rvnx+F5
> The main reason that Cloudflare wouldn't share this info is to prevent competitors like Akamai to operate a CDN as good as them. It looks more like sabotaging competition than increasing privacy.

Exactly. Their own answers in the threads over here at HN are basically admitting as much — they claim to be working on solutions alternative to ECS, because Google and some others have more PoPs than Cloudflare does. They're obviously using this as a competitive advantage to slow down competing CDNs. And noone's talking about!

>>FDSGSG+d6
How? If your client is leaking DNS outside of the confines of the proxy you're using, you've got bigger problems than ECS.

>>cnst+(OP)
Even if ECS only reveals your /24, immediately afterwards you're going to connect to the service with your own IP, so Eve can correlate the pair of domain name and /24 from the ECS request with the source IP from the TCP connection to match your IP with the domain name you're navigating to.

>>majews+7a
This is not the privacy concern, check out the https://tools.ietf.org/html/rfc7871#section-11.1 discussing it. Yes, if you open a connection to the target IP, then all transit networks between client and the target IP (including the target itself) know who is talking. These are on-path parties. The main (privacy) issue with ECS is not this, but that it shares client's subnet with potentially every nameserver on the referral path (including transit networks between the recursive and nameserver), for every name client looks up (even when it might not support ECS). The client is also not in control of the prefix length. /24 for IPv4 is a recommended default, but the recursive may use however much it wants and there's no way to prove to the client that it didn't. Opt-out is also difficult (afaik only getdns and Firefox clients support an opt-out).

>>vavrus+i1
What do you say to the very often heard criticism that the exact IP address will be leaked the moment the user establishes a TCP connection to the domain they just looked up?

>>breaki+ud
Hi, I answered it in another comment below.

>>vavrus+bd
> but that it shares client's subnet with potentially every nameserver on the referral path [...] for every name client looks up

Does CF DNS not use qname minimization? That would reduce the association between subnets and names looked up.

>>vavrus+i1
How about looking up the client's AS via BGP or whois and broadening the scope so that it matches its net block? Then if a CDN peering with a particular ISP wants more granular DNS load balancing they could ask the ISP to announce their routes by region or something like that.

>>vavrus+i1
I haven't really looked into EDNS, but can't you send fake the EDNS that points to a Cloudflare PoP close to the user (thus giving them a Cloudfare address)?

>>cnst+J7
I don't disagree about DNS leaks being a separate problem, that doesn't change anything about what I said though.