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

[Raymond Burkholder <[e-mail]>]

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