Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

blog.technitium.com

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#41

Post by tptacek »

zrm wrote: post #30
jchw wrote: post #23

Part of Paul Vixie’s argument is that DNS is part of the control plane, and that DoH will bypass security policy. Let’s at least address this with some skepticism. 1. Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass. 2. While this can be true, it’s not…

> Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass. That's assuming the clients and the network are adversarial to each other. Consider that the local DNS resolver may be blocking domains associated with malware or ads, which the client wants for it to…

Adversarial networks are the common case.

In the other cases, where DNS is being used as a legitimate policy vector, the entity enforcing that policy should also have endpoint control, which they can use either to re-establish network policy (by disabling DoH) or to enforce policy more reliably at the endpoint layer.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#42

Post by tptacek »

zzzcpan wrote: post #38
jchw wrote: post #36

Earlier quoted context omitted.

> It is. They can even install a VPN everywhere they want, that's how much control they have. DoH wants to take it away. The network control plane is not on the end user’s computer. For a home network, this is probably their ISPs modem, followed their ISPs actual edge. You could opt to set up your own DNS server or use an alternate DNS server, which is bypassing the control plane, assuming your ISP doesn’t force you…

> which is bypassing the control plane This is not bypassing the control plane, this is the control plane. Each device is essentially its own network that connects to other networks. This is how operating systems work today. > You can still configure your resolver today. Yes, because of people who pushed back Mozilla.

Do you have an argument that would be persuasive to people not in the alternate universe where resolvers weren't configurable?

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#44

Post by bjoli »

tptacek wrote: post #19
bjoli wrote: post #16

Can anyone explain why DoH was invented? To me it seems like another one of the "let's solve this using web technologies!" Whereas DoT has a great ietf process behind it.

Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS). Virtually all the opposition to DoH is rooted in two complaints: 1. It centralizes DNS at Cloudflare (obvi…

Blocking the vast majority of DoH services should be pretty easy, just like with regular DNS. I block a lot of DNS servers that aren't my own. Not all of course, but enough to not have any outgoing requests on port 53.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#45

Post by tptacek »

bjoli wrote: post #44
tptacek wrote: post #19

Earlier quoted context omitted.

Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS). Virtually all the opposition to DoH is rooted in two complaints: 1. It centralizes DNS at Cloudflare (obvi…

Blocking the vast majority of DoH services should be pretty easy, just like with regular DNS. I block a lot of DNS servers that aren't my own. Not all of course, but enough to not have any outgoing requests on port 53.

It's difficult to block in the general case, though, without reterminating TLS.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#46

Post by vetinari »

Znafon wrote: post #5
vetinari wrote: post #4

Earlier quoted context omitted.

The thing that is still being ignored is the configuration mechanism for the DoH resolver. Currently, the only way to configure it is manual and application-specific; there's no way to configure it for all apps and automatically, like DHCP for the normal, 53/udp DNS. Nobody is going to manually reconfigure their DNS every time they switch network (e.g. home -> office -> customer).

Is DHCP useful to enforce network policy? What about users who manually set their DNS servers? Wouldn't be a proxy checking the SNI of connections you open better?

Enforcement is step 2. Proxy with a blacklist of hostnames would do, but unfortunately, with encrypted SNIs on the horizon, full blown https proxy with custom CA enrolled on all machines would be necessary.

Step 1 is a mechanism for those, who do not want to fight the network policy, just want the autoconfiguration.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#47

Post by pdkl95 »

tptacek wrote: post #19
bjoli wrote: post #16

Can anyone explain why DoH was invented? To me it seems like another one of the "let's solve this using web technologies!" Whereas DoT has a great ietf process behind it.

Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS). Virtually all the opposition to DoH is rooted in two complaints: 1. It centralizes DNS at Cloudflare (obvi…

> you can point DoH elsewhere

That only fixes the "Cloudflare" problem. It still centralize all DNS traffic onto a single service. I cannot configure Firefox to send packets only to the (hypothetically DoH capable) delegated nameserver(s) for each domain.

When you run your own recursive resolver (which is easy), only the lookup of the NS delegations needs to use a centralized service. This is relatively infrequent (NS records rarely use a very short TTL), so regular (TTL-respecting) caching prevents the centralized service from learning your pattern-of-life.

The DNS traffic for the A/AAAA records[1] is very different. Short TTLs are commonly used to force a DNS check every few minutes. In practice, this means a user's aggregate DNS traffic contains a very good pattern-of-life about the services they use and when they use them. When you run your own recursive resolver, nobody can learn the entire pattern-of-life; the traffic is distributed to different servers for each domain delegation.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#48

Post by jchw »

zzzcpan wrote: post #38
jchw wrote: post #36

Earlier quoted context omitted.

> It is. They can even install a VPN everywhere they want, that's how much control they have. DoH wants to take it away. The network control plane is not on the end user’s computer. For a home network, this is probably their ISPs modem, followed their ISPs actual edge. You could opt to set up your own DNS server or use an alternate DNS server, which is bypassing the control plane, assuming your ISP doesn’t force you…

> which is bypassing the control plane This is not bypassing the control plane, this is the control plane. Each device is essentially its own network that connects to other networks. This is how operating systems work today. > You can still configure your resolver today. Yes, because of people who pushed back Mozilla.

Even if Mozilla did make Cloudflare DoH mandatory, which to be honest is ridiculous and not a real thing that was ever happening, it’s not as if you have to use Firefox.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#49

Post by zrm »

tptacek wrote: post #41
zrm wrote: post #30

Earlier quoted context omitted.

> Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass. That's assuming the clients and the network are adversarial to each other. Consider that the local DNS resolver may be blocking domains associated with malware or ads, which the client wants for it to…

Adversarial networks are the common case. In the other cases, where DNS is being used as a legitimate policy vector, the entity enforcing that policy should also have endpoint control, which they can use either to re-establish network policy (by disabling DoH) or to enforce policy more reliably at the endpoint layer.

Adversarial networks are not the common case. On the majority of networks you can send a plaintext UDP DNS query to 8.8.8.8 or 1.1.1.1 and nothing will actually interfere with it in practice.

Adversarial networks exist, which is why something like DoH or DNSCurve should be used in favor of unauthenticated DNS over the internet, but the real issue here is independent of which DNS protocol is used -- it's how the recursive resolver is chosen.

The canonical answer to that is to use DHCP or similar to distribute the resolver that should be used for the local network, and allow the user to manually configure a different one in any case where that one is untrustworthy. DHCP is the ordinary method of endpoint control for configuring the endpoint's DNS server.

The endpoint shouldn't have to be exposed to manual configuration or give up even more control over other unrelated settings by adding their device to something like a third party Active Directory domain just to be able to plug into a local network and have local name resolution work.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#50

Post by tptacek »

zrm wrote: post #49
tptacek wrote: post #41

Earlier quoted context omitted.

Adversarial networks are the common case. In the other cases, where DNS is being used as a legitimate policy vector, the entity enforcing that policy should also have endpoint control, which they can use either to re-establish network policy (by disabling DoH) or to enforce policy more reliably at the endpoint layer.

Adversarial networks are not the common case. On the majority of networks you can send a plaintext UDP DNS query to 8.8.8.8 or 1.1.1.1 and nothing will actually interfere with it in practice. Adversarial networks exist , which is why something like DoH or DNSCurve should be used in favor of unauthenticated DNS over the internet, but the real issue here is independent of which DNS protocol is used -- it's how the recu…

Your threat model isn't the set of actors currently attacking you, but rather those actors who can and might attack you in the future. Your ISP is certainly adversarial in any sane threat model.
Post reply on HN