Re: [Add] [EXTERNAL] Re: draft-grover-add-policy-detection-00

[Brian Dickson <[e-mail]>]

On Wed, Jul 17, 2019 at 8:58 AM Ted Hardie <[e-mail]> wrote:

> Hi Neil,
>
> On Wed, Jul 17, 2019 at 8:38 AM Neil Cook <[e-mail]>
> wrote:
>
>> Hi Ted,
>>
>> But, and this is the crux of the matter, that integration requires the
>> cooperation of the endpoint or its control by an organization's system
>> administrators.  If you do not have their cooperation or the right to
>> manage them by tools like those Eric mentions, it is difficult for the
>> endpoint to distinguish a network-level interception by a mandated policy
>> engine and by an attacker.
>>
>> Rather than falling back to the state where the endpoint simple accepts
>> that its traffic is visible to all and possibly intercepted, this new work
>> is an effort to make it easier for you to gain the cooperation required.  I
>> hope you can see that this is in both the interest of policy enforcement
>> bodies and the end users.
>>
>>
>>
> So I use DNS filtering in my own house (along with millions of other
>> people as already stated on this thread), provided by my network operator
>> (but it doesn’t have to be - I used to use OpenDNS for example, and I have
>> the capability to run my own resolver if I so desired).. I have malware
>> filtering as well as parental controls enabled. I am the de-facto network
>> administrator in my house,  but I don’t have the tools or software that
>> enterprises use so I won’t benefit from the work being done to help
>> enterprises control this. I also have other people coming into my house and
>> using my network, and I also like to control what they can access when they
>> are in my home. All of this works very well for me today. It doesn’t work
>> for me when applications/endpoints start deciding that my network is an
>> attacker because it does filtering, and bypassing that filtering "in the
>> interest of end-users".
>>
>> I hope you can see that this is in both the interest of policy
>> enforcement bodies and the end users.
>>
>>
>> I’d like to ask, ask an end-user, how is this in my interests?
>>
>>
> I am sorry if I was not clear,  The point of the draft is to enable the
> network operator to signal this:
>
>    If the user agent can check for the presence of a policy, this could be
>    used as a signal that the network operator wishes its resolver to be
>    used as a condition of using the network, and that DoH or DoT should
>    be disabled.
>
> That permits your guests to know of your network policy and to abide by it
> if they choose; presumably you would not provide network access if they
> chose not to.
>
>
So, as far as I can tell, there are some minor problems with the DoH
deployment scheme proposed by various vendors (on the client in an
"applications doing DNS" manner), which this draft is fundamentally unable
to overcome.

This draft would probably work just as well, with a bit of work, and
without those fundamental issues, for DoT.

The root of the problem is visible in "if they chose not to". The nature of
DoH, is that the network operator (regardless of who they are) is unable
either detect or prevent guests (or users or BYOD or whoever) from not
complying with your network policy.

In the current unencrypted DNS world, in some specific environments
(enterprise, etc), non-compliance is enforced at a port/protocol level
(ACLs denying port 53).

A similar model that enabled both discovery and enforcement, and if
appropriate bypass of enforcements, would look roughly like:
client -> obtain policy -> (comply with visibility into compliance by
network, e.g. via DoT port/protocol) | (no-comply with visibility and
blocking -> obtain explicit information about risks and informed consent
from user -> violate/bypass e.g. via DoH)

When only DoH is used, if there is no informed consent, this short circuits
completely to client-> obtain policy -> comply or no-comply.

This breaks all of the existing detection and enforcement for network-level
tools applicable to DNS-based systems.

Given that DoT provides everything that DoH provides, from a privacy
perspective, so long as DoT isn't blocked and/or so long as any existing
DNS resolver(s) have an upgrade to DoT, and so long as relevant clients
(system or application) have the corresponding upgrade for DoT, I don't
understand the non-use of DoT.

Reminder: DoT clients have to build wire-format DNS queries, and then send
them over TLS sessions. DoH clients haveh to build wire-format DNS queries,
encode them, add HTTP headers, and send them over TLS sessions. DoH
ALREADY, by definition, has all the necessary code paths to build the
wire-format DNS queries required by DoT. Adding DoT to a resolver involves
duplicating the DoH bits, and then removing the HTTP-handling bits, i.e.
almost entirely removing code.

I think the fundamental asymmetry, where the guest can know the network's
policy but the network cannot detect or enforce its own policy, is easy to
see and understand.

And, I think the issue where this asymmetry is fundamental to DoH, but is
not an attribute of DoT, is also clear to anyone who looks.

This is why many of us are advocating for replacing DoH with DoT.

The harm that DoH does in an intractable fashion, far outweighs (by many
orders of magnitude) the benefits to an admittedly important set of users
and use cases.

I may have said it before, but I think it bears repeating: the DoH
bypassing of network policy, SHOULD be restricted via several important
safeguards (in widely distributed software systems): Disable DoH by
default; restrict enabling DoH to admin-level accounts; restrict DoH usage
to certain modes (e.g. incognito or equivalent); restrict DoH usage to the
lifespan of a browser tab; restrict DoH usage/enabling via "informed
consent" that may be very complex to implement, but which is nonetheless
needed to ensure users are informed about their specific, concrete, literal
risks (e.g. company policy violations, geopolitical environments, operator
terms/conditions, etc.).

Brian