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

[Brian Dickson <[e-mail]>]

On Wed, Jul 17, 2019 at 1:49 PM Ted Hardie <[e-mail]> wrote:

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

The "dead in the water" mode presumes a specific deployment model on both
the operator of DNS services, and on the implementer of the client.

Even the current "beta" deployments of DoH have configurations for
"fall-back" to other choices of protocol and/or server.

The "dead in the water" issue can very easily be handled via an
informational or BCP RFC, on how to deploy and/or migrate to DoT.

This very much looks like the deployment of IPv6, including the "happy
eyeballs" stuff.


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

I don't understand how you can disagree on this.

Compare two scenarios:
- client connects (or attempts to connect) to a random DoT server (on port
853).
- client connects (or attempts to connect) to a random DoH server (on port
443 at a specified URL).

Since DoT uses 853 exclusively, detecting and blocking are possible (and I
assert, trivial).

How would either detection or prevention of *just* DoH be possible, as
distinct from random HTTPS traffic?
There are plenty of scenarios where a random host standing up a DoH service
(e.g. on a shared hosting site via any feasible attack vector) becomes an
undetectable DNS vector (for anything value of "bad").

This is the poster child case, IMHO.



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

I would go further, and suggest some comments:

   - A lot of the perceived demand for DoX is in fact demand for public
   resolver availability, to handle the problem of "hotel/cafe DNS
   shenanigans".
   - Many of the common issues between "shenanigans" and DoX usage, would
   benefit from client-side DNSSEC validation.

In particular, the behavior of DNSSEC validation failure (returning
SERVFAIL) works well with the use of multiple resolver and protocol "lists"
(hierarchical structures).
E.g. try local port 53 server obtained by DHCP, with (one or more) DoT
server(s) (regardless of DoT server choice(s)) as a more-secure fall-back.
If DNSSEC is not available, fall back to something better.
If DNSSEC is available, validate.
Upon validation failures (including rewritten NXDOMAIN), fall back to
something better.
Performance on valid responses may be faster.
As long as some resolver answers with DNSSEC-valid responses, correct
responses are guaranteed.

For privacy-first, reverse the order of fallback, trying DoT first.
Possibly fail hard if no DoT answers are available.


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

I agree. By itself it is insufficient. I am not proposing *not* doing some
kind of publication of policy. I am proposing doing so via DoT, and
preferably also with DNSSEC client validation.

And perhaps DANE needs to be included in the discussion, particularly on
the secure bootstrap process.
(For DANE to work, you need DNSSEC, but you don't need privacy, and you
don't need any CAs. You need names, and signed zones for those names, and
TLSA records, but that's reasonably straightforward, IMHO.)

Brian


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