If we trust DNS to publish the SNI public keys, why don't we trust it for the website certificate in the first place?
The threat model around TLS public key substitution is basically full read/write control over your requests. This represents both a major privacy invasion and exposure of auth secrets like your bank account password. Your DNS provider doesn't already have access to those things.
edit: You could deliver a cert this way, and authenticate the cert out of band e.g. through the CA system. This kind of approach is sound from a security standpoint, but there just isn't a lot of upside. There are fewer moving parts when you just deliver the cert the way we do now.
I was quite hopeful it might lead to widespread use of self-signed certs, though with things like LetsEncrypt, it's not really needed any more
These are two very different things. The SNI public keys are only used to encrypt the hostname, i.e. the goal here is hostname privacy.
You can't have hostname privacy without trusting the DNS. But it will always be a weak form of privacy, because you have to trust a third party.
So what is happening here is that we say "ok, we can't have perfect hostname privacy, but allowing the DNS server to compromise our privacy is better than allowing it to everyone".
Now if you put the cert there you'd say "we allow the DNS to compromise all of our TLS". You really don't want that.
As multiple people here have said there's a way to put signed certificates into DNS called DANE. But it suffers from the fact that it relies on DNSSEC, which is a complex beast and probably most relevant: Which in the decades it has existed hasn't managed to get any relevant traction.
It really doesn't matter though. You can just use DoH and trust Google / Cloudflare for everything. /s
From rfc8484: "HTTP cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case."
You'd have to review your particular resolver implementation to be sure. I suppose one would have to say DoT is safer in this regard, since accepting cookies is not an implementation error you could reasonably make without using an HTTP library.
Most users are probably better off with DoH. It protects transport better. Sadly the problem of finding someone trustworthy to resolve through doesn't go away.
EDIT: ^ This is wrong; DNS-over-TLS is fine.
Thanks. Why it protects transport better?
Yeah DNS-over-TLS is safer in this regard and provides equivalent network-path protection. DoH is kind of a garbage protocol but it's a concession to the fact that a lot of "real" networks are broken and HTTP(s) is the only thing you can rely on being able to transport.
Since DNS-over-HTTPS goes over proxies and uses port 443, it'll "work by default" in a larger variety of networks than DNS-over-TLS.
CloudFlare have made the argument that DoH "blends in" better with regular HTTPS traffic but I don't really buy that when everyone just uses the same few recursive resolvers.
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).
But on the other hand to have substituted this key for the correct one they presumably already intercepted your DNS query and so they likely already knew you were intending to talk to some.name.example from that query.