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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
