> On 27 Nov 2019, at 14:22, Konda, Tirumaleswar Reddy > <[email protected]> wrote: > >> >> Resolver discovery schemes allow a client to ask the local resolver to >> provide >> information about the resolver, such as DoH info, as well as potentially >> other >> information about the resolver. I don’t see why they’re broken by design; >> yes they add no security properties on top of the (insecure) DHCP >> mechanism used to contact the resolver in the first place, but how clients >> use >> that information is up to them. They may or may not decide to trust that >> resolver, > > The problem with DHCP is the client has no way to know whether the DoT/DoH > server is indeed hosted by the local network or by an attacker. For example, > consider a network using Quad9/OpenDNS to perform malware filtering but > attacker spoofs the DHCP response to convey the network is using CloudFlare > DNS server. Chrome would establish DoH with CloudFlare, and the attack is > successful. It is also easy for the attacker to get a domain name, and get > the certificate signed by the CA (domain validate certificate). >
I’m not arguing that DHCP is secure, I’m arguing that discovery isn’t worthless., The client is free to use other mechanisms to decide whether to trust the DoH server returned as part of the discovery mechanism. For example if the resolver discovery returns the DoH server for that resolver as “myisp.net”, then the client can verify not only that the certificate matches myisp.net <http://myisp.net/>, but also whether it trusts “myisp.net <http://myisp.net/>” for DNS resolution. This is essentially the approach that Chrome is already taking with DoH, except that it currently lacks the discovery part. Another use-case for discovery would be the case where I have manually entered a DNS server (e.g. 1.1.1.1). By default I can use DNS53 or DoT to that server, but not DoH. However with discovery I could ask (using either DNS53 or DoH) the 1.1.1.1 resolver if it supports DoH and if so on what URL. Neil
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
