> The problem is that the mechanics used for corporate monitoring are almost exactly the same mechanics used for your ISP spy on you or censor things.I disagree. With SSL getting more and more widely deployed, corporate monitoring has no choice but to add re-encrypting proxies.
In that case, all SSL sites you are visiting are signed by a company internal certificate which is more or less obvious depending on the browser (if you ask me, browsers don't make this nearly as obvious as they should)
However, this kind of monitoring absolutely continues to work fine even if the browser is using DNS over HTTPS.
What DoH does break though, is internal DNS resolution of internal intranet hosts. Those would obviously be corporate owned as they would obviously have a corporation specific domain anyways, so no MitM is needed anyways because the admin can just look at the traffic on the server side.
This means that as DoH becomes more widely used, a corporation has only two options to continue to be able to allow users to connect to internal sites, both of which are worse from a security standpoint than the status-quo:
* they could assign publicly resolvable names to all of their internal hosts. This is likely to cause issues with IDS systems which assume that to be a DNS reflection attack and it of course also means that they now have to leak internal names to the public which obviously isn't desirable.
* they could deploy browsers with a modified configuration. Now most corporation already do that anyways to deploy their internal monitoring cert, but some smaller companies might not be interested in monitoring their users and right now they can ship original browser installers from their original source with their original config whereas in the future they will need to use group policies or custom installers, both of which are less trustworthy for a user than the default installers with the default config (who knows what that group policy / custom installer is doing alongside of configuring DoH).
So while option 1 is worse for overall corporate security, option 2 is worse for security and trust for individual users when the corporation is not currently doing any monitoring.
This security downgrade hurts even more in light of the fact that real SSL interception is not at all stopped by this, so already malicious actors can continue to be malicious, but good faith actors have to accept a significant downgrade in either user-trustworthiness or security.
I do not think this is a fair trade-off.