> Use non-expired certificates first when building a certificate chain.
.. Is relevant to the recent expiry of Sectigo's old "AddTrust" root. If your library cheerfully assembles a trust path with the expired root and then concludes the certificate isn't valid because the root is expired you're pointlessly inconvenienced compared to a library that can use the same raw materials to discover a working trust path with no expired certificates.
https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.1.1-...
So you only benefit from features that already existed in TLS 1.2 (using the same API) or do not require an API such as the reduced round trips for initiating a new connection.
In particular you can't use 0RTT "Early" data because the specification asks that only be supplied via a dedicated API in both clients and servers.
The reason is that Early data might be replayed by an attacker in some cases despite all practical countermeasures and so your application software needs to make an explicit decision about whether it's acceptable to use Early data. Providing a separate API forces you to actually confront that decision and not get surprised by upgrading to TLS 1.3 and finding now you're subject to a replay attack.
However, note that the OpenSSL API compatibility layer doesn't support TLS 1.3 yet. So, if you're using Nginx or something else that doesn't use the LibreSSL API, you're out of luck for now.
OpenSSL offers some additional APIs for certain TLS 1.3 features, but are hardly mandatory.
As I parse more and look at the libressl site I see that similarly, this is a development release and the stable release, 3.1.2, matches OpenBSD 6.7.
