3 ms·

There's a tension between using private, semi-public (ISP-run), and public resolvers. The more clients a resolver has, the better the privacy protection it off

There's a tension between using private, semi-public (ISP-run), and public resolvers. The more clients a resolver has, the better the privacy protection it offers vis-a-vis authoritative servers, so there's some reason to want to use one's ISP's resolver, or even a public resolver. On the other hand, you may not want your ISP to know about some of the sites you visit, or you may not want a public resolver operator to know. After all, both will have a huge incentive to monetize that data. Regardless, ISPs need to adopt support for DoT and DoH. Lastly, it'd be nice if we could get authoritative servers to support DoT/DoH, but that will take a long time. It'd have been nice to have settled on DNSCurve for confidentiality a decade ago... Even assuming Curve25519's eventual obsolescence, it would have served us well while waiting for a better solution.

zrm 7y ago
It'd be nice if we could settle on DNSCurve for authoritative servers even now. It's significantly simpler and more efficient than DoH and the only real advantage DoH has over it (less interference from quarrelsome middleboxes) isn't nearly the problem between recursive and authoritative resolvers as it is between clients and recursive resolvers, because recursive resolvers are almost always operated from networks that are responsive to their administrators.
- bluejekyll 7y ago
  Why do you say DNSCurve is simpler? Having implemented DoH and DoT, it's pretty much as simple as adding TLS to the connection...
  - zrm 7y ago
    It's simple if you pull in a dependency on a library that does it for you, but that's just putting the complexity in the library. HTTP is a complex protocol, TLS is a complex protocol, even just using TCP isn't exactly simple or advantageous to response latency.
    - tptacek 7y ago
      TLS is a complex protocol with trusted mainstream implementations (even OpenSSL, at this point, is a fine option).
      - zrm 7y ago
        Trusted mainstream implementations come from use. You might get the same number of vulnerabilities from a green new DNSCurve library as from old battered OpenSSL because you're trading off the protocol complexity against the years of grinding away at all the bugs, but that only gets you to parity. Which itself only lasts until the DNSCurve library is trusted and mainstream and claims the advantage because the younger code matures but the protocol stays simpler. In the meantime DoH still has worse latency because of the extra round trips. Especially in the authoritative case where you're typically making few queries each to many authoritative servers instead of making many queries to one recursive resolver and you can't reuse the one handshake for all your queries.
      - josteink 7y ago
        > TLS is a complex protocol with trusted mainstream implementations (even OpenSSL, at this point, is a fine option). Trusted for now. How long until the next heartbleed? Do you want that vulnerability embedded in billions of unupdatable IoT-devices?
bluejekyll 7y ago
> On the other hand, you may not want your ISP to know about some of the sites you visit, or you may not want a public resolver operator to know. After all, both will have a huge incentive to monetize that data. To be clear here, your ISP will still know what sites you visit, unless you are using a VPN. There are two vectors for them to gather this information: 1) the IPs are generally pretty stable for most sites (yes that could host many web sites, but still), 2) The SNI is will be sent in the clear for the website to be able to choose the correct certificate for the connection. That's not to say that there isn't value in DoH/DoT, there still is, but your ISP is still going to be able to follow you around the web pretty easily.
- cryptonector 7y ago
  They'll know the IP addresses, but unless the DPI the SNIs, they may not know the domainnames, especially when an IP serves multiple domains.
  - viraptor 7y ago
    I disagree with the usage of DPI here like it's a significant barrier. Your ISP has access to both the IPs and the SNIs. They can dedicate resources to log them or not to. SNI requires only a little bit more processing power, but otherwise they "know" both.
    - tialaramex 7y ago
      This work is landing in parallel with development of eSNI, encrypted SNI. If you have a Firefox with this stuff switched on (so it uses TLS 1.3, eSNI and uses CloudFlare's DoH server), and you go to a site that's proxied by CloudFlare, only CloudFlare [and the site] know which site that was, an ISP sees only that you connected to CloudFlare (duh) and did some HTTPS transactions. There will be SNI in the ClientHello, but it's generic, it doesn't say which CloudFlare service you wanted so it doesn't help an ISP to log that. The IP belongs to CloudFlare so they learn that, but the rest is a mystery. All the stuff that makes this go lives in DNS. For privacy you should use DoH to go fetch it. For authenticity you should use DNSSEC to verify it. Proposals are under development for how to land the final DNS changes with HTTP/3 in there as well, so that a single query protected by DoH + DNSSEC can tell a browser "For HTTPS speak QUIC on this IP address and send this fake SNI, then use this eSNI encryption key to hide the real hostname". But already the prototype with boring TLS 1.3 and HTTP/2 works just fine in Firefox builds with it enabled.
belorn 7y ago
Personally I trust much more the authoritative root servers than public resolver. The root servers economic model is being the backbone of the Internet, they are not advertisement companies, they have a long history of working as an infrastructure, and there is very little incentive to monetize that data. The risk of a fork in the DNS system has always been the sword that kept the authoritative root servers honest. If authoritative root servers started to support DoT/DoH/DNSCurve then clients could do secure end-to-end communication with simple two hops in the vast majority of cases. In the case of news.ycombinator.com it would ask .com for ycombinator without informing the TLD server of the remaining parts of the domain, and then ask ycombinator.com for news. Simple end-to-end communication without giving out unnecessary information to any party.
- bluejekyll 7y ago
  I’ve always heard that the root servers are not capable of handling that amount of load. Is this no longer a major concern?
  - belorn 7y ago
    I have asked that question a few times in conferences. Capacity wise they can handle it as they already need it to defend against the massive DDoS threat that they face. Relative recently they also added anycast, which further increases the capacity. DNS queries is also generally quite small and has not significant changed, and the modern resolver software is pretty efficient. DNS is also designed for redundancy so in combination with anycast is quite simply to scale up. Because of the persistent DDoS threat the question of capacity is constantly discussed. I don't remember the exact numbers but the current overhead is quite large compared to actual usage. It is also constantly being increased based on the threat rather than usage.

zrm 7y ago

It'd be nice if we could settle on DNSCurve for authoritative servers even now. It's significantly simpler and more efficient than DoH and the only real advantage DoH has over it (less interference from quarrelsome middleboxes) isn't nearly the problem between recursive and authoritative resolvers as it is between clients and recursive resolvers, because recursive resolvers are almost always operated from networks that are responsive to their administrators.

bluejekyll 7y ago
Why do you say DNSCurve is simpler? Having implemented DoH and DoT, it's pretty much as simple as adding TLS to the connection...
- zrm 7y ago
  It's simple if you pull in a dependency on a library that does it for you, but that's just putting the complexity in the library. HTTP is a complex protocol, TLS is a complex protocol, even just using TCP isn't exactly simple or advantageous to response latency.
  - tptacek 7y ago
    TLS is a complex protocol with trusted mainstream implementations (even OpenSSL, at this point, is a fine option).
    - zrm 7y ago
      Trusted mainstream implementations come from use. You might get the same number of vulnerabilities from a green new DNSCurve library as from old battered OpenSSL because you're trading off the protocol complexity against the years of grinding away at all the bugs, but that only gets you to parity. Which itself only lasts until the DNSCurve library is trusted and mainstream and claims the advantage because the younger code matures but the protocol stays simpler. In the meantime DoH still has worse latency because of the extra round trips. Especially in the authoritative case where you're typically making few queries each to many authoritative servers instead of making many queries to one recursive resolver and you can't reuse the one handshake for all your queries.
    - josteink 7y ago
      > TLS is a complex protocol with trusted mainstream implementations (even OpenSSL, at this point, is a fine option). Trusted for now. How long until the next heartbleed? Do you want that vulnerability embedded in billions of unupdatable IoT-devices?

bluejekyll 7y ago

> On the other hand, you may not want your ISP to know about some of the sites you visit, or you may not want a public resolver operator to know. After all, both will have a huge incentive to monetize that data. To be clear here, your ISP will still know what sites you visit, unless you are using a VPN. There are two vectors for them to gather this information: 1) the IPs are generally pretty stable for most sites (yes that could host many web sites, but still), 2) The SNI is will be sent in the clear for the website to be able to choose the correct certificate for the connection. That's not to say that there isn't value in DoH/DoT, there still is, but your ISP is still going to be able to follow you around the web pretty easily.

cryptonector 7y ago
They'll know the IP addresses, but unless the DPI the SNIs, they may not know the domainnames, especially when an IP serves multiple domains.
- viraptor 7y ago
  I disagree with the usage of DPI here like it's a significant barrier. Your ISP has access to both the IPs and the SNIs. They can dedicate resources to log them or not to. SNI requires only a little bit more processing power, but otherwise they "know" both.
  - tialaramex 7y ago
    This work is landing in parallel with development of eSNI, encrypted SNI. If you have a Firefox with this stuff switched on (so it uses TLS 1.3, eSNI and uses CloudFlare's DoH server), and you go to a site that's proxied by CloudFlare, only CloudFlare [and the site] know which site that was, an ISP sees only that you connected to CloudFlare (duh) and did some HTTPS transactions. There will be SNI in the ClientHello, but it's generic, it doesn't say which CloudFlare service you wanted so it doesn't help an ISP to log that. The IP belongs to CloudFlare so they learn that, but the rest is a mystery. All the stuff that makes this go lives in DNS. For privacy you should use DoH to go fetch it. For authenticity you should use DNSSEC to verify it. Proposals are under development for how to land the final DNS changes with HTTP/3 in there as well, so that a single query protected by DoH + DNSSEC can tell a browser "For HTTPS speak QUIC on this IP address and send this fake SNI, then use this eSNI encryption key to hide the real hostname". But already the prototype with boring TLS 1.3 and HTTP/2 works just fine in Firefox builds with it enabled.

belorn 7y ago

Personally I trust much more the authoritative root servers than public resolver. The root servers economic model is being the backbone of the Internet, they are not advertisement companies, they have a long history of working as an infrastructure, and there is very little incentive to monetize that data. The risk of a fork in the DNS system has always been the sword that kept the authoritative root servers honest. If authoritative root servers started to support DoT/DoH/DNSCurve then clients could do secure end-to-end communication with simple two hops in the vast majority of cases. In the case of news.ycombinator.com it would ask .com for ycombinator without informing the TLD server of the remaining parts of the domain, and then ask ycombinator.com for news. Simple end-to-end communication without giving out unnecessary information to any party.

bluejekyll 7y ago
I’ve always heard that the root servers are not capable of handling that amount of load. Is this no longer a major concern?
- belorn 7y ago
  I have asked that question a few times in conferences. Capacity wise they can handle it as they already need it to defend against the massive DDoS threat that they face. Relative recently they also added anycast, which further increases the capacity. DNS queries is also generally quite small and has not significant changed, and the modern resolver software is pretty efficient. DNS is also designed for redundancy so in combination with anycast is quite simply to scale up. Because of the persistent DDoS threat the question of capacity is constantly discussed. I don't remember the exact numbers but the current overhead is quite large compared to actual usage. It is also constantly being increased based on the threat rather than usage.