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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
