This is a puzzling submission. On the 1st of June an updated eSNI draft, draft-ietf-tls-esni-07 was published with a new name reflecting the approach of encrypting more of the Client Hello rather than just SNI, but "draft status" isn't a thing, except in the sense that a draft either exists or does not, and this one exists.<p>This Internet Draft was formally adopted by the TLS working group in 2018.<p>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.
As a user, I will continue to favour websites that do not use shared hosting. They do not require SNI.<p>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.<p>Not surprising one of the sponsors of this draft is an enormous user of SNI in its hosting business.<p>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.