4 ms·

Agreed, SNI and DNS need to be fixed together, not separately. And definitely without centralized services, like Cloudflare. Otherwise why not just go all the w

Agreed, SNI and DNS need to be fixed together, not separately. And definitely without centralized services, like Cloudflare. Otherwise why not just go all the way with centralization and provide secure proxy for everyone in the browser.

phicoh 8y ago
They are completely independent protocols, with their own issues in this area. For the DNS, the specification for DNS over TLS is almost trivial. DNS over HTTPS is a bit more tricky because their are more possibilities, interactions with HTTPS, etc. But still not very hard from a protocol point of view. Operationally, DNS over TLS/HTTPS is mostly unknown. So it will take quite a bit of time before it is well know how to actually run that as a service at scale. Encrypting the SNI in TLS is mostly the other way around. Fixing that has significant impact on the protocol. There is no point in making very complex changes in TLS, which is already a tricky protocol without the DNS community committing to provide DNS over TLS/HTTPS at scale. At the same time, securing traffic between a DNS stub resolver and the recursive resolver prevents are lot of middle box issues (but also creates a completely new set of issues). So it is worth deploying the even if TLS still leaks the SNI.
- zzzcpan 8y ago
  They cannot be independent if actual privacy is concerned. At least sharing a threat model that touches both layers.
  - phicoh 8y ago
    They are mostly independent. Your privacy loss is by and large the sum (or max) of the privacy loss caused by DNS and TLS individually. For TLS, the threat model is relatively simple: only an on path attacker has access to a plaintext SNI. In the context of route hijacks, 'on path' is not as simple as it sounds, but route hijacks are relatively rare. For DNS the situation is much more complex. You have to consider not only traffic between stub resolver and recursive resolver, but also between recursive resolver and the various auth. resolvers. At the end of the day, you need to consider all places where information is leaked and whether you want to do something about that or not. And in that sense DNS is independent from TLS.
gnode 8y ago
Ironically, some amount of centralisation can improve privacy. Security is about confusion and diffusion; to get lost in a crowd you need to not be differentiated, and to not be the whole crowd. Encrypted SNI would mean ISPs could tell you were contacting Cloudflare servers, but not which of the many hosted websites you were requesting (assuming you also plug the DNS privacy gap too).

phicoh 8y ago

They are completely independent protocols, with their own issues in this area. For the DNS, the specification for DNS over TLS is almost trivial. DNS over HTTPS is a bit more tricky because their are more possibilities, interactions with HTTPS, etc. But still not very hard from a protocol point of view. Operationally, DNS over TLS/HTTPS is mostly unknown. So it will take quite a bit of time before it is well know how to actually run that as a service at scale. Encrypting the SNI in TLS is mostly the other way around. Fixing that has significant impact on the protocol. There is no point in making very complex changes in TLS, which is already a tricky protocol without the DNS community committing to provide DNS over TLS/HTTPS at scale. At the same time, securing traffic between a DNS stub resolver and the recursive resolver prevents are lot of middle box issues (but also creates a completely new set of issues). So it is worth deploying the even if TLS still leaks the SNI.

zzzcpan 8y ago
They cannot be independent if actual privacy is concerned. At least sharing a threat model that touches both layers.
- phicoh 8y ago
  They are mostly independent. Your privacy loss is by and large the sum (or max) of the privacy loss caused by DNS and TLS individually. For TLS, the threat model is relatively simple: only an on path attacker has access to a plaintext SNI. In the context of route hijacks, 'on path' is not as simple as it sounds, but route hijacks are relatively rare. For DNS the situation is much more complex. You have to consider not only traffic between stub resolver and recursive resolver, but also between recursive resolver and the various auth. resolvers. At the end of the day, you need to consider all places where information is leaked and whether you want to do something about that or not. And in that sense DNS is independent from TLS.

gnode 8y ago

Ironically, some amount of centralisation can improve privacy. Security is about confusion and diffusion; to get lost in a crowd you need to not be differentiated, and to not be the whole crowd. Encrypted SNI would mean ISPs could tell you were contacting Cloudflare servers, but not which of the many hosted websites you were requesting (assuming you also plug the DNS privacy gap too).