In this article I take a look at the technical properties of Encrypted Client hello as well as some scenarios that are not really covered by the threat model proposed.
I argue that to get any tangible benefit you have to use the big providers, which places trust into entities that are behaving less trustworthy by the hour.
This is a really good write-up. I can't really think of anything important to add.
I don't know if it is worth adding but there is one small piece that can be kept at home rather than depending on Cloudflare or Google though by itself is rather moot but I will mention it anyway.
If using Unbound DNS [0] at home as a DNS resolver one can enable DoH if Unbound was compiled using --with-libnghttp2 thus allowing an HTTPS listener and enabling ECH tested / verified on [1]. I realize its just one tiny piece of the puzzle but we can take away the logging of DNS queries away from the big providers. If people do not trust their home ISP they can put Unbound on a VM or physical server somewhere else. I only mention this because I know some people run PiHole and other security distros on their WiFi or Firewall hardware at home.
Documentation [2][3]
I am half tempted to put a DoH listener out there for anyone to experiment with and see what kind of abuse it gets.
Then in browsers / devices I set a custom DoH endpoint of https://dohint.mydomain.tld/dns-query and uses the same key/cert I used in the past for DNS over TLS (DoT) which is still listening on TCP port 853
Have you tried putting this behind a reverse proxy? This gives us a lot of features like rate-limiting and it should work well since it is https after all.
I argue that to get any tangible benefit you have to use the big providers, which places trust into entities that are behaving less trustworthy by the hour.