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

[Paul Wouters <[e-mail]>]

On Sun, 24 Mar 2019, Brian Dickson wrote:

> There is one important difference, which is that DoT uses a unique port number. This is important for network
> operators in identifying encrypted DNS traffic, in order to ensure that implementation of security policies for
> DNS don’t conflict with any other network policies (regardless of what those policies are.)

The network cannot "ensure" this based on DNS. I can come on to the
network with a DNS cache already, which is the functional equivalent
of me refreshing my personal cache using a sneaky HTTPS connection.
The network can never control my DNS cache. I won't let it.

So while it was perhaps nice that network operators _could_ help in such
a case, it was never a real defense against a smart network "abuser".

> IMNSHO, if both ports are reachable for a given provider of Do*, the DoT port MUST be used. DoH should only be
> used with explicit informed user consent, and only when DoT is unavailable.. This supports the “dissident” use
> case, without impacting any other aspects of privacy provided by DoT.

If the network allows DoT, clearly it does not care about DoH being
used? Since it will also not be able to read DoT to a remote server
like the Quads. So I do not understand what is gained by such a
policy.

Unless you meant "must use a local DoT server first", in which case we
are again shifting the discussion towards when can or should you trust
a network for anything but relaying IP packets. Because then you
basically demand access to my decrypted DNS stream.

Why should I ever use a starbucks DNS server, regardless of whether
I use DoT or DoH or plain 53? On almost every network I connect to,
I only want one service: "relay my (encrypted) IP packets". The rest
of the services I obtain from trusted sources elsewhere, using this
ephemeral network as an insecure transport only.

So your policy above that you propose really assumes a lot about the
network, namely that you are considered hostile to the network and
that you trust that network more than your own device. That's a very
specific application. It basically never applies to me unless I join
an enterprise network with an enterprise device, and then we have
other ways for the enterprise to enforce things on their device.

> The blocking of DoT to a given provider should be interpreted as an explicit policy. Users should be informed
> that they may, and very likely will, be violating someone’s policy, if they choose to use DoH in that
> circumstance, and that they may be violating laws by doing so, and should only do so if they are willing to
> accept that risk.

Again, this is the network operator centric view. There are many hostile
networks that would block DoT just so that they could monetize (legally
or illegally!) from my harvested DNS data. I can assure you the warning
you want to write to users would be very different from the warning I
would want to give those users. Which is why the IETF doesn't do
banners towards endusers.

Besides, why should the network operator have a say about when I want my
device to connect to my remote servers? Do you want my VPN client to
throw the same warning around that it might be against the network
operator's wishes to inspect all my traffic and it might be against the
law to circumvent it? Then you also have to do that for _all_ TLS
connections, and make the internet go back to port 80. Why is there a
different expectation of website content monitoring versus dns content
monitoring? You shouldn't have access to either.

> There is no reason DoH should be used if DoT works (towards the same DNS provider).

If DoT works to dot.nohats.ca, which you cannot decrypt, why do you care
whether I use DoH to that server or not?

Paul