Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

[Paul Vixie <[e-mail]>]

On Tuesday, 12 March 2019 19:15:16 UTC Ted Hardie wrote:
> ...
> > that's precisely the goal, because very few network operators can
> > preordain the users and apps that will connect through their networks.
> 
> I do not believe this goal is met by what you describe, since an
> application can use a proprietary resolution service in its flows.

rogue flows have their own accounting. my problem isn't with one-off's, 
because traditional security is anomaly-based. DoH, by folding control plane 
data into previously non-anomalous flows, presents a new problem. if CF and G 
and IBM and Cisco decide to offer DoH on the same IP address that they offer 
API's and services i actually do need or want to permit, i'm going to have to 
increase my investment.

this equation, where something is created which is a danger to me, which 
blends in with the crowd of things that are not dangerous to me, is the method 
by which DoH achieves its stated aim, "prevent on-path interference in DNS 
operations." all war is economics. they are increasing my costs, deliberately.

i am on-path and i intend to interfere. at whatever cost that may be. i also 
reserve the right to re-externalize some or all of those new imposed costs.

> Imagine for a moment an application on a smart TV that wants to provide
> content from the closest server which contains that content.  ... Blocking
> destinations for which you have seen no resolution events will work for a
> subset of these cases, but it won't work when the resolution points to a
> common CDN destination.  That approach will, of course, also have a wide
> variety of failure modes when the resolution event data is incomplete for
> timing or other reasons; it will also block all of the flows which MUD
> would handle. 

generally speaking, security policies break down into two categories. allow 
all except some, or deny all except some. which one an operator chooses will 
depend on their goals, budgets, and in particular, the cost of anomaly 
detection. it's the change in cost of anomaly detection, deliberately intended 
by the authors of RFC 8484, which is at the root of some very expensive policy 
choices that the rest of us must now make.

your smart-tv example is not involved in that causalality path. noting also, i 
have a TV which offers the kind of feature you describe, but only if i accept 
its software license. (something to do with GDPR, i suspect.) so i did not 
accept that license, and as a result, i have a disconnected device whose 
flaws, both now known and not yet known, will pose no threats here. my TV, my 
rules.

> > to the extent that monitoring ('dnstap') and controlling (DNS RPZ) dns
> > lookups by connected users and apps is considered a vital local security
> > policy, attempts at such "pass through" must be made to fail.

> Those are security mechanisms, rather than policy, and it may be worth
> teasing apart what the actual desired security policy is.  You may find
> that it is more easily implemented at the routing layer than the resolution
> system in the light of proprietary resolution systems and DoH.

to be clear, the policy is, "allow all, except some". i implement as much of 
this policy as possible at the routing layer, and i do my research on 
proprietary resolution systems to decide whether i can tolerate the risks of 
devices which use such things. (so, no nest thermostats here, the TV's are not 
smart, and the apple home pods are in their not-logged-in state.)

it is the standards nature of DoH that amplifies its imposed costs. i could 
simply outlaw by IP or port# a proprietary or otherwise bespoke protocol. 
(working out with my kids what online games require what permissions, has been 
burdensome on both me and them.) DoH, by _intending to bypass_ network 
operator policy DNS, and my seamlessly hiding in the crowd of TCP/443 
transactions now made indiscernible  by TLS 1.3 and ESNI, is an act of 
economic warfare against all RDNS control plane owners. (deliberately.)

vixie