On 12 Mar 2019, at 20:05, Raymond Burkholder wrote:
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
[removing d...@ietf.org from cc: list, as this message is on operational
implementation only]
Agreed with what Raymond has said above, and most of what Paul Vixie has
said previously on this topic. We see no significant improvement that
DoH brings to security or privacy that DoT does not already offer, and
also believe DOH’s stated goal of obscurity via port and origin source
IP conjoining is dangerous and ultimately misguided in respect to the
goals of increasing privacy and permitting content access. Keep control
and content channels separate, even if it allows blocking to be easily
effective. If there is the thought that clever obfuscation will prevent
blocking, then that is vastly underestimating the legal, administrative,
and commercial force which will be applied to prevent the DoH model one
widely adopted, and then the subsequent privacy wreckage that force will
cause.
We expect to see the “block everything and force national/enterprise
certs” model expanding in the near future, which we believe to be
++bad. DoH throws gasoline on that fire if content and DNS are
indistinguishable and commonly bundled. Maybe always-proxied connections
are an inevitable condition for some large portion of Internet users,
but we would prefer not to see the angle of the growth slope increase so
quickly as it might if DoH is implemented in ways that aggressively and
intentionally oppose local network policy enforcement.
Quad9 supports DoH currently, but recommends DoT. We are not opposed to
DoH as a protocol, but we fear the political results of deployment
models by others which take Internet content as hostage in front of DoH
services. The optimistic hope by DNS operators that websites can be used
as a “shield” against blocking will end badly for the people who
need security the most, since those users are typically on networks or
within nation-states which have the highest incentives to react strongly
and in a privacy-negative way to perceived or real policy circumvention
at scale. Mainland China’s example of network filtering is a template
to control-oriented operators as one such response result.
We will not serve non-Quad9 HTTPS content on the same IP addresses as
our public resolvers. We will keep the number of DNS-serving endpoints
we operate to a relatively small list of anycast netblocks that can be
identified as being “DNS-only” in nature. We hope that organizations
that offer content and open DNS recursive resolution will not try to
combine DNS and HTTPS in a way that is impossible to “cheaply” block
by local network operators. Otherwise we see a condition where those
operators in the hopes of regaining control will choose to block/proxy
all traffic to all destinations, and not just block DNS. If that type of
deny-all (or “intercept-all”) filter is implemented as it has been
in existing examples then this appears to us to be a worse outcome that
we would want to try to avoid.
JT
--
John Todd - jt...@quad9.net - +1-415-831-3123
Executive Director - Quad9 Recursive Resolver
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
