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

61–67 of 67 posts

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

#61

Post by zrm »

tptacek wrote: post #60
zrm wrote: post #59

Earlier quoted context omitted.

Aren't you the one usually telling everyone that DNSSEC is useless even though it solves the same problem, e.g. because the server can be verified with TLS instead? If the DNS attack is nothing more than a denial of service then it seems completely reasonable to wait until the attack is actually observed before applying a mitigation (third party DNS) that can have problematic side effects. Especially when the mitigat…

DNSSEC doesn't solve any practical problem, but does have the effect of escrowing TLS keys to world governments. DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem. You don't have to use Cloud Flare for DoH, and I wouldn't.

> DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem.

That's assuming the DoH provider isn't monitoring queries either. Doesn't Cloudflare have a deal with APNIC to do exactly that?

> You don't have to use Cloud Flare for DoH, and I wouldn't.

That's the point -- the problem isn't that DoH exists, it's when an application changes your DNS provider to Cloudflare by default instead of using the one you have in your system configuration.

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

#62

Post by pdkl95 »

tptacek wrote: post #58
pdkl95 wrote: post #56

Earlier quoted context omitted.

> making your DNS lookups even more attributable That's missing the point. I don't care what a nameserver learns from my DNS request when I'm almost always going to follow that request by opening s socket to the referenced server. The delegated nameserver and the referenced (e.g. HTTP{,S}) server are controlled by the same entity, which is compartmentalized from other unrelated DNS requests when you perform the recur…

DoH is the improved protocol. There's nothing "centralized" about it; you can run a DoH cache server anywhere you want. The only reason anyone advocates DoT is because network operators can block it, forcing people to use plaintext DNS. Somehow, the meme has been created that DoT is somehow better or more privacy-respecting than DoH, but that's obviously false.

> DoH is the improved protocol.

That doesn't appear to be true, according to RFC 8484. DoH cannot be used for encrypting communication to domain-delegated nameservers. Running your own DoH server just moves the problem to a different host. If I run a DoH server locally as a recursive resolver, the encryption between the browser and the DoH server is useless. The DoH server still sends the requests to domain-delegated nameservers in plaintext.

The protocol is explicitly[1] focused:

    on communication between DNS clients (such as operating
    system stub resolvers) and recursive resolvers.
The RFC doesn't provide any method to discover the "URI Template" of a domain's authoritative DoH server. The existing NS records only[2] include a domain name. This omitted feature appears to be intentional; RFC 8484 only says[3] that configuration of the "URI Template":

    might be manual (such as a user typing URI Templates in
    a user interface for "options") or automatic (such as
    URI Templates being supplied in responses from DHCP or
    similar protocols).
Even worse, the protocol seems to require[3] aggregating all requests through a single DoH server:

    A DoH client MUST NOT use a different URI simply because
    it was discovered outside of the client's configuration
That seems to forbid the fundamental idea of discovering delegated nameservers. Why would a core feature of DNS be forbidden? Apparently from a concern[3] that allowing unrecognized URIs:

    may create additional operational, tracking, and security
    hazards that require limitations for safe usage.
This is a strange concern. If the user wants to perform a DNS request, that's their business. How would this become a "tracking [or] security hazard"? This concern seems to be a consequence of a design goal for DoH:

    Two primary use cases were considered during this protocol's
    development.  These use cases are [...] allowing web applications
    to access DNS information via existing browser APIs in a safe way
    consistent with Cross Origin Resource Sharing (CORS)
DoH is designed to enable performing DNS requests in a web app (which will probably be yet another API I will need to disable). If I'm mistaken and it is possible to use DoH in a recursive resolver, how would that work?

> There's nothing "centralized" about it

Requiring that a client "MUST NOT use a different URI" is the very definition of a "centralized" protocol. Moving to DoH from my existing local recursive resolver would be a huge loss of privacy. If there a way DoH can compartmentalize DNS requests to the domain specific nameservers, I would like to know how.

[1] https://tools.ietf.org/html/rfc8484#section-1

[2] https://tools.ietf.org/html/rfc1035#section-3.3.11

[3] https://tools.ietf.org/html/rfc8484#section-3

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

#63

Post by tptacek »

zrm wrote: post #61
tptacek wrote: post #60

Earlier quoted context omitted.

DNSSEC doesn't solve any practical problem, but does have the effect of escrowing TLS keys to world governments. DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem. You don't have to use Cloud Flare for DoH, and I wouldn't.

> DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem. That's assuming the DoH provider isn't monitoring queries either. Doesn't Cloudflare have a deal with APNIC to do exactly that? > You don't have to use Cloud Flare for DoH, and I wouldn't. That's the point -- the problem isn't that D…

You can trivially boot up your own DoH provider if you don't trust any of the existing ones. It's hard to imagine a protocol that would improve this situation: "supported by major vendors, and free to use for everyone".

I won't use Firefox to begin with (I'll reconsider when it's mostly Rust!), and so don't care so much about how Mozilla is handling this. Personally, I wouldn't touch Cloud Flare with a 10 foot pole. But that's not what I'm commenting about; I'm talking about DoH itself, which is an unalloyed good thing, which you can tell in part by the fact that the knives are out for it.

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

#64

Post by shreyasonline »

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."

Same argument can be done for firewall that filters traffic using IP addresses. In the same words, it can be said that, if your firewall security policy can be defeated by using VPN, its evidently not very hard to bypass.

Just like firewall is useful for security, so is DNS based policies.

Cloudflare is doing good job but, the concern is centralization. Its not going to be good to have most internet resources being resolved via Cloudflare DoH, then accessed via Cloudflare CDN.

ESNI will take a lot of time to gain meaningful market share. There are people still arguing that their website does not need to use HTTPS since they are just a static website or do not have login/user data. Such people completely fail to understand that HTTPS is not to protect them but to their end users from MiTM script injection attacks.

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

#65

Post by shreyasonline »

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…

"The major criticism of DoH is Firefox enabling it by default and overriding the existing system DNS configuration, requiring manual reconfiguration of arbitrarily many client devices to change it back to the way it was. There can obviously be no legitimate objection to it if it is disabled by default and only used when explicitly enabled by the user."

+1 Firefox should also consider that such network settings are only accessible to root or administrators such that organizations can maintain network policies for the devices they own in their network.

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

#66

Post by shreyasonline »

Santosh83 wrote: post #3

The claim that DoH will interfere with internal DNS of enterprises can be solved with a local deployment of a recursive DoH server right? That also addresses the concern of centralisation. Imagine every ISP offering a DoH sever... so now Cloudflare will not be in a position to scoop up the entire DNS data of the Internet. I'm still waiting to see a genuinely technical disadvantage of DoH. All that I've read so far ar…

Why DoH and not DoT? DoT be much more suitable and provides same set of guarantees since both are essentially using TLS. DoH provides only one extra thing that is to make it difficult to block. If you run DoT over port 443 then it essentially becomes same as DoH in terms of difficult to block.

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

#67

Post by shreyasonline »

shawnz wrote: post #22

> DNS is one important control planes in a network. It essentially allows network administrators to block content based on domain names making it quite useful tool in the arsenal. It is being widely used to provide content filtering services, parental controls, and to block known malware command and control. Its so popular that a lot of people install a locally running DNS server on their home networks to block Inter…

Same can be said about IP-based blocking that firewalls employ. IP-based blocking can also be bypassed by using various tunneling techniques but that does not make it useless. Having DNS based control in addition to IP-based control is much useful for most scenarios.
Post reply on HN