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
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.
This Internet Draft was formally adopted by the TLS working group in 2018.
If you have valuable technical input for this work, or indeed any of TLS, you should subscribe to the TLS working group, familiarise yourself with the culture and pitch in - but there doesn't seem to any particular reason it's more relevant to Hacker News today than last week or next month.
Meanwhile there are few mechanisms to popularize the results of standards groups aside from occasional sexed up vendor blog posts (for example, CloudFlare are great at these). I see no problem with this extra visibility, and find it quite perplexing that someone would have reason to complain about it.
If you're expecting to get any value from this hacker news story, you need to understand enough of how the IETF works to know what meaning this particular draft has as opposed to any of the previous 6 revisions.
SNI is an interesting experiment. One could argue it benefits users because it has made it less expensive for websites to provide TLS, and therefore there has been more use of TLS, however at the same time it takes users a step back in terms of privacy. Before SNI, SSL/TLS websites never leaked hostnames. Even a user who is using "encrypted DNS" (not the DNScurve kind) or who is not even using DNS at all (she already has the server IP address) ends up leaking hostnames when she accesses websites requiring SNI. That's all of Cloudflare and many other hosting providers/CDNs. The whole exercise makes it trvially easy to track the usage habits of users by sniffing the plaintext TLS setup traffic. Whatever was gained by using SNI to achieve virtual hosting for TLS must be offset by the amount of user privacy sacraficed.
Not surprising one of the sponsors of this draft is an enormous user of SNI in its hosting business.
ESNI is a noble idea however it is riddled with complexity. As a user concerned about leaking hostnames, nothing beats a good old-fashioned TLS website on a decicated IP addresss. There are still plenty of those around.
You can probably just probe the IP on port 443 and look at the certificate subject to characterize that traffic.
Might work for very obscure sites, but not anything commonly used.
However, to be fair, I think there could be an argument regarding websites now using TLS with SNI because of the cost reduction of shared TLS hosting that previously were only only using TCP. Before they started using TLS, arguably hostnames could be sniffed from HTTP headers. Whether pulling hostnames from HTTP Host headers is easier on a mass scale than sniffing ClientHello packets, and whether anyone would do that for marketing/advertising purposes, is for the reader to decide.
BoringSSL ticket for implementation: https://bugs.chromium.org/p/boringssl/issues/detail?id=275
Chromium ticket, blocked on above: https://bugs.chromium.org/p/chromium/issues/detail?id=109140...
