[Add] DNS visibility, malware C&C, exfiltration, etc.

[Brian Dickson <[e-mail]>]

<meta-comment>
I'll preface this with an observation:
If you are reading this, you very likely work in the Internet industry.
If not, there's a good chance you rely on the Internet in some way for your
livelihood, or things that are important to you.
Please keep this in mind, in considerations for the impact of deployment of
DoH/DoT.
</meta-comment>

One problem with DNS over HTTPS, is that it interferes with passive DNS
monitoring by authorized parties in the DC/Enterprise use case.

A quick survey of blog posts and academic papers on identification and
response to malware command and control (C&C), shows that these
detection/mitigation systems are heavily reliant on DNS, either directly or
indirectly.

In particular, DGA (domain generation algorithms) in malware typically can
only be observed via their DNS queries, and takedown and/or interception
requires that DNS visibility.

In some cases, the visibility is local to the victim; in other cases,
victims rely on feeds of domain names or IP addresses, to thwart or contain
malware activity. The feeds ultimately can be traced back to some third
party having the visibility into a DNS monitor.

The privacy offered by DoH is a multi-pronged problem. If malware uses DoH,
it can do "validation" of the cert for the DoH server it wants to try
using, and refuse to use a spoofed replacement, preventing direct
intervention as a method of obtaining DNS queries. And if the DoH traffic
is going to an attacker-controlled server, the DNS queries are not visible.

The second prong is, that if all DNS traffic is going over DoH, there is no
way to identify legitimate query names. All HTTPS traffic looks the same,
at that point, with no ability to differentiate DoH from regular HTTPS
traffic, and no ability to detect change of DoH provider in use. If/when
SNI encryption is employed, there is no visibility into names used on HTTPS
connections, and it all looks like encrypted traffic to arbitrary IP
addresses.

Without this visibility, malware infections on user machines inside
enterprise networks may go undetected. This can lead to deeper penetration
into protected parts of such networks.

The inability to block this DoH traffic is (IMHO) the crux of the problem.
If DoT is used in its place, then enterprise networks can enforce DNS
resolver choice at the network level, including via deployment of internal
DoT resolvers which could still protect user privacy (modulo specific
enterprises' policies). DoT or Do53 service to resolvers operated by the
enterprise, enables the current visibility to be maintained, independent of
the presence or absence of TLS to protect those connections.

The existence of browsers which support DoH is the underlying problem. Even
if DoH is not enabled by default, so long as user-input resolver choice is
available, and so long as DoH can be enabled by unprivileged users, all of
the above problems continue to exist, i.e. the ability for a user, or
malware, to evade detection by DNS monitoring systems.

A reasonable compromise might look like:

   - admin-only enabling of DoH/DoT (which can be a policy pushed to
   managed systems)
   - a hardcoded TRR list for DoH/DoT
   - a default-off configuration
   - the use of DoT exclusively (instead of DoH) for any non-TRR resolver
   entry

Doing all of these may be enough to mitigate the risk posed by DoH.
Doing anything less would not be, and would pose an existential threat to
the security of enterprise and DC networks and hosts.

(I'm still opposed to DoH generally, but I realize it has valid use cases
-- it just needs to be restricted to ONLY those actual use cases to be seen
as useful and legitimate.)

Brian