[Add] Three degrees of (administrative) separation

[Brian Dickson <[e-mail]>]

I'm putting this into a new thread, so: (a) it doesn't get mis-threaded;
(b) its distinct set of issues don't get conflated; (c) it's easy to find
in the archives.

The three degrees of (administrative) separation are:

   1. Network (including ACLs, firewall policies, RPZs, etc.)
   2. Host administration (including network configuration and resolver
   configuration -- I place DHCP use of offered DNS as host rather than
   network, although one config choice is to defer to Network)
   3. User/App administration (user preferences)

The reason I am highlighting this hierarchy (which under DoH/ADD is
potentially traditional/historical), is for the following issue:

Security policy which relies SOLELY on the host, is fatally flawed.

Security policy which replies SOLELY on the app, is doubly flawed.

Host compromise (whether at the app level or at the privileged user level)
in such a system, affects the only place where security policy is
implemented.

This in turn means a compromised host which does not have other mechanisms
for enforcing policy, is unrestricted in what it can do.

In some environments, for example (but not limited to) Enterprise networks,
a "belt and suspenders" approach is common.
E.g. hosts may be managed via automated systems, but network and/or DNS
policies may provide redundant protection, or even a greater level of
protection.

In these environments, host/app level protections are typically using
static sets of protection metadata which is updated periodically (daily or
weekly).
However, DNS level protections are frequently implemented with "live"
feeds, that are capable of updating metadata about "bad" sites at
very-near-realtime.

Given the very nature of HTTPS (on port 443), where name-based-hosting is
used and end-to-end encryption occurs prior to the HTTP headers, the
current best practice is to implement DNS-based mechanisms for handling the
network enforcement.
Here are the reasons for using DNS-based filtering for HTTPS traffic,
explained in pedantic fashion:

   - It is not possible to use IP-only filtering, since IP addresses may
   contain vast numbers of unrelated name-based hosting on web servers
   - It is cost-prohibitive and insecure to employ MITM techniques which
   require the decryption and re-encryption of traffic at a session level
   - Host connections on the basis of name, require DNS resolution before
   connections can be established
   - Thus, use of DNS-based schemes to block HTTP(s) connections are
   effective, and cost-effective
   - Enforcement of DNS resolver usage via network-level ACLs on port 53
   and/or 853 ensures DNS resolution mechanisms cannot be bypassed
   - Without the ability to bypass DNS resolver choice (and presuming the
   non-existence of DoH), a compromised app or host would need to implement
   its own DNS scheme, which:
      - would require use of an outside agent (since it cannot directly
      contact DNS authorities if port 53 is blocked
      - would require a hard-coded server (name or IP)
      - at least potentially be detected in DNS logs (if it used name-based
      connection resolution), or
      - at least potentially be detected by the absence of DNS lookups (if
      it used a hard-coded IP address).

In contrast, DoT usage at least provides the dedicated (IP, port)
combination that is detectable and filterable, allowing the continued use
of DNS-resolver selection enforcement, and the continued use of DNS-based
mechanisms.

Since DoT offers all of the same privacy protections as DoH, I am of the
opinion that implementing DoH in a way that bypasses both host
administration and network administration, is fundamentally incompatible
with enterprise usage.

On the other hand, I believe that use of DoT, either directly in the
browser, or over a system-level API/proxy, is not incompatible with the
enterprise use case. (There are other deployment considerations that need
further discussion, but DoT is the starting point for those discussions.)

Since the user population consists of a significantly non-negligible
proportion of users whose networks employ such mechanisms (including home
networks using third party DNS forwarders for filtered DNS), it may be time
to discuss ways to prevent deployment of browsers doing DoH, or to discuss
public resolver operators requiring that browsers use only DoT, possibly
with a very limited set of exception mechanisms (the "dissident" use case),
such as limiting that use case to incognito-mode, non-slit-tunnel VPN
service over HTTPS, enforced by the public resolver operator.

Brian (speaking for myself)