Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Please see inline

From: Neil Cook <[e-mail]>
Sent: Wednesday, November 27, 2019 8:10 PM
To: Konda, Tirumaleswar Reddy <[e-mail]>
Cc: Stephane Bortzmeyer <[e-mail]>; [e-mail]; Phillip Hallam-Baker <[e-mail]>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________



On 27 Nov 2019, at 14:22, Konda, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>> 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.,

[TR] I am only saying DHCP is not right discovery technique mechanism but I am not opposing discovery.

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<http://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.

[TR] You may want to re-look into the attack I explained in the previous e-mail, client will use CloudFlare DoH server trusted by the browser (whereas the network is using Quad9/OpenDNS for malware filtering).

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.

[TR] The above discovery is more straightforward, client can query for the URI resource record type using https://tools.ietf.org/html/rfc7553

Cheers,
-Tiru

Neil