Re: [Doh] Fallback to untrusted DOH servers

[Mateusz Jończyk <[e-mail]>]

W dniu 14.04.2018 o 19:34, Ted Lemon pisze:
> On Apr 14, 2018, at 9:36 AM, Mateusz Jończyk wrote:
>> It may happen that either no trustworthy DOH server has been configured, or the
>> configured DOH server is not working. In such cases a DOH client would usually
>> revert to using an untrusted DNS server on port 53, possibly one that was
>> discovered through unsecure DHCP. This DNS resolver would also be able to poison
>> DNS caches then.
>>
>> I think that in this case it would be better to use whatever DOH server is
>> available as an alternative to an even worse old-school DNS. To avoid cache
>> poisoning attacks, the client would then have to drop DNS caches after switching
>> to a more trustworthy DNS once it has been configured or is available.
> 
> What threat model do you want to address?   Two things spring to mind as things
> you might care about:
> 
>  1. "do I trust the DNS server"
>  2. "is the connection to the DNS server private?"
> 
> 
> If the resolver was configured with keying information that can be validated as
> part of making the connection to the server, then you trust the server.   What
> exactly that means is a question in itself, but let's take that for granted for now.
> 
> In the case of DOH-I-don't-know versus DNS-I-don't-know, you don't have (1), so
> it doesn't matter which one you use, except that if you use some method other
> than DHCP to get to the DOH server, potentially what you have reached is even
> _less_ trustworthy than the DNS server.   So you could as easily be worse off as
> better off.

I have been thinking exactly about discovering DOH servers via DHCP (in this or
a future RFC). I cannot think about any other sensible method of *discovering* a
DOH server (as opposed to using a preconfigured one).

A DOH server discovered via DHCP can be used for bootstrapping (a way of getting
the address of the trusted DOH resolver). For example, it may be used to query
the IP address of dns.google.com.

> 
> What you do get with DOH-I-don't-know as compared to DNS-I-don't-know is (2),
> for some value of "private."
> 
Yup. Untrusted DOH protects the content of requests against everyone other then
the DOH server operator.

> So what threats does preferring DOH protect you from?   What threats _doesn't_
> it protect you from?   What vulnerabilities does it create?   I think you need
> to answer all three of these questions if you're going to make the case that
> untrusted DOH should be preferred over untrusted DNS.

> So what threats does preferring DOH protect you from?
Preferring DOH protects against passive network attacks (packet sniffing - as
opposed to active attacks). The NSA possibly monitors and stores DNS traffic.

> What threats _doesn't_ it protect you from?
Trying to phish the user is the most dangerous thing that I can imagine. An
attacker on the local network can run their own DOH server, try to spoof the
DHCP response, and then redirect the user to a phishing site.
But I would argue that an attacker on the local network can mount an ARP
spoofing attack and redirect all network traffic through themselves anyway and
then try to phish the user this way.

The untrusted DOH server can block some domains. It can also be used to monitor
which sites the user visits.

All of this is no worse then using untrusted old-school DNS.

Here, however, we are talking about a last-resort situation, and some kind of
fallback is neccessary - to untrusted DOH or untrusted DNS.

> What vulnerabilities does it create?
I would argue that no new (in comparison to old DNS), if properly implemented
(with separate caches).

On the other hand, why untrusted DNS should be preferred over untrusted DOH, as
the current draft implicitly specifies?

We may end up with the whole Internet using few DOH servers. There are probably
few providers that would host publicly-available DOH servers: Cloudflare
(1.1.1.1), Google, OpenDNS, IBM (or the folks responsible for 9.9.9.9) and
possibly Microsoft and Apple (for use with Windows / macOS) [3]. I doubt that
OpenDNS would be happy to have their DOH server configured in applications as
default, and Microsoft and Apple as well (in products other then theirs).

This would be very different from the current situation where most people are
using the DNS server of their own ISP (discovered via DHCP).

That change may be great because it increases privacy, but could create several
points of failure for the whole Internet [1]. It would be vulnerable to DoS or
some manipulation by the NSA. It is important to have some local fallback - i.e.
DOH or DNS servers hosted by ISPs.







> Your question about the local resolver is interesting.   I think what it points
> to, though, is that what DOH does is to solve a very different problem than the
> problem you are trying to solve with it.
> 
> If you want to solve the problem you are proposing to solve, the place it needs
> to be solved is in the local stub resolver implementation.   This is something
> we've seen before, and there's even an RFC that talks about it, RFC7556.   From
> the perspective of RFC7556, your "trusted" DOH resolver represents a
> provisioning domain, and it's the domain in which you would prefer to look up
> names.   Your local DNS resolver represents another provisioning domain.   
> 
I'm not sure that RFC7556 is exactly concerned with the problem we are talking
about.

> Provisioning domain DNS caches must be separate, to avoid cache poisoning.   
Yup, DNS caches would have to be separate. I have been talking about dropping
caches when switching providers, but having separate caches is much better.

> You> might have a whitelist of domains that can be looked up using the local
> resolver, and all other domains are just not available if the trusted DOH server
> isn't present.   Or you could have a blacklist of domains that are only sent to
> the trusted DOH server, and other domains can go either way.   Or some other
> security policy.
I have been talking about sensible defaults, not maintaining whitelists /
blacklists [2].

Currently, I suppose that most of the serious DOH resolvers work this way (or
will work this way): if the DOH query returns NXDOMAIN, they check the address
with a local resolver. This way they introduce (almost) no regressions when
resolving names.

This scheme is (I would argue) secure - when a global domain name is not used,
it does not hurt much if it resolves to something when querying the local
resolver. Thus I would argue that no whitelists / blacklists are necessary.

The current DOH draft forbids using a local, discovered DOH server for
resolution of local names.


Greetings,
Mateusz Jończyk

[1] This would be much worse then the current situation with DNS root servers.
[2] The whitelists / blacklists could be simple, though: for example most
Internet domain names end with a well-known country domain name, while most
local names do not have dots in the middle or are in the subdomain ".local" or
something similar.
[3] I'm skipping providers like ClearBrowsing and hobby sites incapable of
processing much traffic.