Owen DeLong <owen@delong.com> wrote:
DOH isn?t inherently bad, but every implementation of DOH that I am aware of involves depriving the user of choice and/or control
I don't think that's quite correct. There is an unfortunate and persistent conflation of "DoH" with "DoH to a centralized third-party resolver"; that is largely Mozilla's fault, but even for Firefox the argument can be made that that is not _depriving_ the user of choice, but enabling their choice. (Defaults being seen as no-choice seems a stretch, even if we know the majority of users will not (know how to) change the defaults.) Google, for example, has noted that they have no plans to follow Mozilla's example, and instead will only use DoH if the local stub resolver in question is on their explicit shortlist of DoH resolvers. That is, the user (or the organization controlling the end-point) have already set the stub resolver to that service; if the user changes the stub resolver to point to some other IP, then Chrome will _not_ override that and use DoH to e.g., Google's public resolver.
and also depriving network operators of the ability to enforce the ?my network, my rules? concept.
The network operator has _some_ control, but that control is limited by design, as the primary threat model for DoH and especially for _DoH to a third-party resolver_ is to defend against an untrusted network operator. That is indeed the argument of increased choice made by Mozilla: if a user explicitly enables DoH to a given server, they can enable it to be mandatory with no fallback and the network operator cannot change that. (Unless the network operator is also in control of the user's device, of course.) -Jan