The release page itself mentions the existence of 0RTT in TLS 1.3 but the TLS 1.3 wiki page omits mention of 0RTT. It'd be nice if it said e.g. "We do not yet offer 0RTT" or whatever is the case.
A compliant TLS 1.3 implementation can of course just not provide 0RTT and maybe that's what OpenSSL has chosen to do (at least in 1.1.1), if functioning as a client it just always does the normal 1RTT ClientHello, if as a server it responds to attempts to do 0RTT by ignoring/ rejecting them.
But if they do have 0RTT they need a separate API to let library users hook into that, which is why I've supposed they perhaps don't offer it at all. The reason to have a separate API is that 0RTT doesn't (can't under the practical constraints of the Internet) offer a bunch of the guarantees we have for 1RTT and so an application needs to explicitly opt into this risk, often on a case-by-case basis (e.g. doing GET /favicon.ico with 0RTT is probably safe for your website, but POST /account/payments is almost certainly not safe unless you put serious engineering effort into making it so)
0-RTT / early data is supported. It is mentioned in the blog.
The wiki is really a document about issues you might run into when upgrading, and 0-RTT is not such a problem. To enable 0-RTT you need to use new functions.
Ubuntu 18.04 LTS ships openssl 1.1.0, with the intention to upgrade to 1.1.1. Does anyone know the timeline for this upgrade? I would like to just have TLS 1.3 without building stuff myself.
A compliant TLS 1.3 implementation can of course just not provide 0RTT and maybe that's what OpenSSL has chosen to do (at least in 1.1.1), if functioning as a client it just always does the normal 1RTT ClientHello, if as a server it responds to attempts to do 0RTT by ignoring/ rejecting them.
But if they do have 0RTT they need a separate API to let library users hook into that, which is why I've supposed they perhaps don't offer it at all. The reason to have a separate API is that 0RTT doesn't (can't under the practical constraints of the Internet) offer a bunch of the guarantees we have for 1RTT and so an application needs to explicitly opt into this risk, often on a case-by-case basis (e.g. doing GET /favicon.ico with 0RTT is probably safe for your website, but POST /account/payments is almost certainly not safe unless you put serious engineering effort into making it so)