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

[Brian Dickson <[e-mail]>]

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

> On Wed, Jul 17, 2019 at 11:40 AM Brian Dickson <
> [e-mail]> wrote:
>
>>
>> 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.
>>
>>
> I disagree.  It forces the existence of the network policy to be visible,
> but it is entirely possible to deny network access to a system which is
> non-compliant.  It is not as simple as blocking or intercepting all port 53
> traffic, but that method never addressed the reality that cleartext traffic
> on that port was available to an observer.  To get both confidentiality and
> policy enforcement via this means, practice will need to change.  It will
> need to be visible to the system consuming the DNS (be it a browser, an OS,
> or some other application), and the enforcement mechanism will have to be
> better integrated into reachability mechanics.  That is definitely new code
> for most people, but it is not impossible.
>

So, I'd like to use a fairly simple existence proof (i.e. demonstrate a
proof-of-concept model that would scale and work) on re-implementing the
port-53 model, using DoT.

Client attempts to contact random DoT server. Network monitoring systems
see new DoT traffic between new pair of hosts (on port 853), alerts if not
blocked, or perhaps the network already blocks such random connections on
port 853 (check.)
Client attempts to contact well-known DoT server (e.g. Quad9, CloudFlare,
Google, or similar). Network policy permits this (check). Or, network
policy does not permit this (check).
Client attempts to contact local DoT server (e.g. server on IP handed out
by DHCP or equivalent, or locally configured). Network policy permits this
(check). Network surveillance of DNS queries performed on local DoT server
(check).
Client attempts to contact random DNS/53 server. (Either allowed or denied,
i.e. same as today, including monitoring elements if allowed). No change
(check).
Yes, network surveillance of DNS queries on DoT requires operation of a DoT
server to facilitate that.
Use of DoT, exclusively, allows the enforcement of that policy at a network
level (ACLs with respect to port 853). The end result is a network policy
of, "use our DNS service, or none at all, or don't use our network".

None of the above *requires* host-level changes. The above certainly plays
nice with any host-level augmentations on other explicit ways of publishing
and consuming policy.

I don't see any way of achieving the same policy enforcement result,
without implementing strict host-level validation mechanisms, which is a
change over the DoT-only scheme above.

In the DoT world, the policy is inherently visible. If you try to use a
particular DoT provider, you know immediately whether that is possible or
not.

The issue of whether a particular DoT server is or is not providing a
certain level of privacy, is perhaps something that could be signaled, but
I don't see any way of validating that signaling beyond, at best, some kind
of contractual enforcement.
I.e. if you want to be sure the party you are talking to is or is not doing
what they say they are doing, pretty much the only way to be sure requires
the involvement of law enforcement and/or lawyers.

The difference between DoT and DoH are whether host-level mechanisms are
required, to achieve any meaningful assessment of compliance.
Host-level compromise defeats host-level mechanisms, so other than secure
ways of proving host non-compromise (like TPM things), it is provably less
secure than adding network-based detection/enforcement.

(None of the above applies to malware that does its own communication to
C&C systems, but it does apply to malware that leverages browser-based DoH
capabilities to make use of DNS for any of C&C, exfiltration, payload
acquisition, etc.)

Brian