Sadly because of SNI browsers send the domain name in clear text, so I do not feel there is much to gain in going all encrypted. HTTPS/HTTP2 is broken by default in this regard and there is no way you can fix it other than using a VPN. At least with DNS you can do something about it your self.
It looks like TLS 1.3 still puts server_name into ClientHello and that isn't encrypted.
I can't see how you could encrypt SNI without pushing TLS out to at least two round trips, which would suck for the Web although it might be tolerable in other applications.
One option that does occur to me would be to shove say, a 32-bit SHAKE(FQDN) instead of an FQDN in as the identifier. This way we don't show eavesdroppers the actual FQDN we wanted, although they can try to guess and discover if their guess was right at their leisure. So it doesn't prevent a sophisticated attacker verifying that we connected to vpn.example.com not www.example.com on the same IP address + port, but it does make it essentially impossible for them to find out that our server has a site named xy4298-beejee-hopskotch-914z.example.com by inspecting the traffic.
The server knows all the hosts it serves for, and can work out 32-bit SHAKE(name) for them and pick the right one or reject it without revealing anything extra. The birthday paradox means this is likely to have conflicts above a few tens of thousands of vhosts per server, but that's already getting into deeply bulk hosting territory where you don't care too much about security anyway. Ordinary people aren't doing much more than hundreds of distinct sites per IP address so conflicts for them would be extremely rare.
I can passively sniff all traffic and know where my users are going that is a big deal. Having a ip -> DNS mapping is a lot of work AFAIK, sure it can be done, but executing a get_hosts_by_ip() on every https packet is hard. In contranst this is enough to get all hostnames from SNI:
I do agree that there is more things to consider about privacy, but the call for al websites to be encrypted is so naive. If that is what you want it would be enough to extend chunked http with an adler32 on the end of each response/chunk, and it would be a lot easier to work with than TLS.
