On 2019-03-12 1:15 p.m., 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.
but there are more than just network operators. There are security
people at all levels of organizations who are extremely interested and
who are empowered to manage/monitor what is happening inside a network.
DoH removes much of this power. I'm not sure if that is a 'good thing'.
I do not believe this goal is met by what you describe, since an
application can use a proprietary resolution service in its flows.
Imagine for a moment an application on a smart TV that wants to provide
content from the closest server which contains that content. It can use
a redirect from the original server when a new, closer server comes
online (or when a different server has that content), and it can provide
the mapping between that server and one or more addresses for that
server with the redirect, in whatever format its individual cache can
store. All of this can take place within its confidential channel,
using whatever proprietary format they find convenient. In that case,
the local network will see new flows to the new servers without having
observed the resolution event. 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.
I think that is to be expected: when a network operator (enterprise,
home, organization) is dynamically adjusting ip based rule-sets based
upon what meta-data can be derived from flow inspection. If a
proprietary resolution service is used, then it is expected that 'by
default blocks' will be performed if the traffic protection engine is
not appraised of change.
If DoH is implemented, then traffic, whether it be lookup, or otherwise,
in a 'default drop' scenario is just going to have to be, well, 'default
dropped'. Brute force I guess is the protection mechanism.
So, I think, then, this begs the question, how can the needs/desires of
those in charge of security be balanced with the needs/desires of those
who desiring to bypass inspection?
I guess the maxim 'my network, my rules' holds. But what DoH will cause
is an even increasing tightening of network rules. With current passive
DNS pass-through, DNSEC and such can remain unmolested, but at least
follow-on flows can be identified for forensic or security or policy
purposes. With DoH, this correlation can not be performed, and thus, by
default, a user's ability will be more restricted in order to prevent
unknown unknowns from happening.
The only way around this, for a security operator's perspective, will be
certificate insertion so that proxying can be performed. And we are back
to what we currently have anyway.
Would a compromise be that, if someone requires personal security, the
standard fall back would be to use a VPN?
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.
You've mentioned that 'security' is separate from 'policy' and then
mention 'security policy'. And I implicitly agree with the latter,
security and policy go hand in hand, and are difficult to separate.
Handling at the routing layer is not possible. Handling at the
interrogation/interception/transparent-evaluation intelligence layers is
where it begins. This information then feeds the interior/perimeter
protection layers. The policies implement the security.
If the interrogation/interception/transparent-evaluation layers are
unable to identify key interactions, then security is unable to be
performed.
Raymond
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
