ESNI just protects the name of the site you're visiting. It's going to be most useful to reduce the amount of data available to bulk snoopers like ISPs or mass surveillance efforts.

But there are lots of ways traffic analysis can uncover data. They can look at request sizes, timing, IP addresses - and critically, your DNS requests. ESNI is an incremental protection that is not expected to be perfect. Just reduce the amount of "low hanging data" that can easily be plucked from streams.

If an attacker can snoop or hard MITM your DNS they know what site you are visiting anyway.

So under the kind of threat model that makes sense for ESNI to be useful there is no real downside to distributing the keys over DNS.

Actually I just had a look at the RFC and this explanation is redundant because they did it themselves in section 7.1: https://tools.ietf.org/html/draft-ietf-tls-esni-04#page-21

In contrast the existing CA infrastructure is intended to protect the content of the user's communications in basically all malicious networking scenarios: DNS hijacking and MITM in particular. The threats that the existing CA infrastructure are meant to protect you from are quite different.

However, there is no reason I can think of that you couldn't distribute the certificate for say, foo.com (signed by existing CA infra) via DNS instead of sending it in-band. I believe you could make the protocol "work" this way.

But DNS is not such a great protocol for sending big things like long certificate chains (in contrast to more svelte naked keys for ESNI). It would not be as good as sending it in-band and the security would be rather worse (more prone to disruption / poisoning / DoS), with more metadata leaked (eg certificate exchange is part of encrypted handshake in standard TLS).

The main semantic difference I can see is that usually the server chooses what server certificate to present; DNS distribution would be more like the client choosing what server cert to use due to DNS eventual consistency. As a practical concern, servers would have to support all valid certs until expiry or introduce additonal negotiation. Servers would also need to figure out which cert the client actually chose, somehow (either by trial decryption or client signalling). Anyway, not TLS as we know it anymore.

It's subtly (but not fatally) worse along several dimensions and I keep thinking of more ways it's worse as I've continued to edit this comment. Last thought: an attacker could easily force you to use an old (but not yet expired) cert. Again I guess the DNS-CA-TLS franken-protocol would have to work around that with additional mechanism (perhaps something like OCSP stapling).