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

[Ted Hardie <[e-mail]>]

Hi Brian,

Some comments in-line.

On Wed, Jul 17, 2019 at 12:46 PM Brian Dickson <
[e-mail]> wrote:

>
>
> 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.)
>

If blocked, the client is dead in the water without an application or host
configuration change.

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).
>

If blocked, the client is dead in the water without an application or host
configuration change, as above.


>
> 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).
>

Note that the client is not aware in this scenario of whether the local DOT
server is or is not blocking traffic, observing traffic, or anything else.
Your premise is apparently that by agreeing to use the local resolver they
have agreed to whatever is being done.  In fact, there are existing
scenarios (coffee shop with a portal page being the most prominent) where
the local system will permit specific names to go to the local resolver to
solicit those pages, but will forbid anything else.  So some more subtle
scenarios already exist.


> 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).
>

And subject to observation or interference by on-path attackers, as has
been discussed.

Yes, network surveillance of DNS queries on DoT requires operation of a DoT
> server to facilitate that.
>

If you run a local DoH service and the client attaches to it, the
situations are parallel.


> 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".
>
> If you mean "only DoT allows this", then I continue to disagree.  If you
mean that only using DoT within this context allows this, I agree.


> 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.
>
>
The theory that would go with this draft runs something like this:

* put up a signal that hosts and applications can check to see if non-local
DNS is permitted (and possibly, provide data on where the local secure DNS
resolver is, if provided).

* link the dns resolver to the reachability management system (e.g. a
firewall) and permit traffic to exit the network only to destinations which
have been resolved via the local DNS and which have passed whatever checks
you have instituted.

A non-compliant visitor will then only be able to reach destinations which
have already been whitelisted by previous resolutions; that means that they
likely will be able to reach various CDNs, popular services, and so on, but
won't be able to reach random hosts that have not already been vetted by
the checks you instituted.

Is this new code?  Absolutely.  But it is not a host-level change, and it
permits more without host re-configuration than the pure blocking mechanism
you outlined.*


> 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.
>
>
It cannot distinguish between this policy imposition, a reachability
failure, and a service failure.  As a signal, it is pretty ambiguous.


> 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.)
>
>
I'm afraid I must continue to disagree with your premise.  I have no issue
at all with increased deployments of DoT, but I do not agree that this
rules out the use of DoH.

regards,

Ted

*For those that outsource this, it may also require a new service that
allows the topology decisions and the resolution services to be linked.
There are several ways to accomplish this by using remote configuration, by
taking traffic out of the network to a service provider quarantine via VPN,
or by some combination of the two.  Again, this is new.  But it is not
impossible, as very similar systems have been built by organization which
centralize these operations; it requires that these be made available to
new customers.


> Brian
>