There's some features you could easily add to yours in order to make it a better overall image.
I don't like having to apply third party patches to any mission critical software such as nginx. So I'll wait until nginx releases official support for linking the quiche library, like they did with brotli.
At the API layer reject any libraries or tools that try to foist this on you, many today either don't do 0RTT or correctly offer it as a separate API call for those willing to pay a price in terms of Replay resistance.
It does seem a bit unsafe. An administrator might opt-in because they copy-pasted it from a tutorial, and not understand or pay attention to the second part.
> On 28 October 2018 in a mailing list discussion, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Groups, made the official request to rename HTTP-over-QUIC as HTTP/3 to "clearly identify it as another binding of HTTP semantics to the wire protocol ... so people understand its separation from QUIC"
Any opinions on how things are likely to play out?
https://www.musl-libc.org/faq.html
The logo is a mussel :)
Not sure what's the implementation status though.
At the point where the last drafts of TLS 1.3 were shaping up, Eric (Rescorla)'s initial ideas for how to achieve eSNI had failed and the extant draft was only a problem statement. It basically said: Here is what eSNI needs to achieve in our opinion, we don't know how to do that
Between that point and when TLS 1.3 was published, several people brainstormed a proof of concept for how to actually make it work, which so far led to the draft you've linked.
The eSNI draft is defined as an extension to TLS 1.3 but - since the whole point is to deny snoopers information about who we're talking to - if we have to "fall back" to not doing eSNI because the server isn't compatible then we lost.
Cloudflare and Firefox devs cooperate to implement drafts of eSNI, so if you have a recent Firefox and a site which has opted into Cloudflare's trial of this feature, then it works for you, but the drafts definitely will change further and you should not go building anything based on this draft that you aren't able to support updating to future drafts or abandon altogether weeks or months from now.
The link you posted is the right one, but it’s to the Internet-Draft. This is the step prior to becoming an RFC, where revisions are stored for everyone (including implementors) to use. So (for example) when you hear someone saying “I support TLS 1.3 Draft 8”, that means they support version 8 of the Internet-Draft.
Once this is finalized and becomes an RFC, you’ll see it updated here: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ (and I’m sure someone here will post about it!)
