OpenSSL 3.3, and moving the QUIC API to a separate project?

[tmshort]

I was speaking with Matt Caswell of OpenSSL, and he suggested that with the new pluggable record-layer features of OpenSSL 3.2, that it might be possible to implement the QUIC API that way, eventually moving the code to a Provider (once the pluggable interface is available in the Provider API in 3.3?). This would mean that vanilla OpenSSL 3.2 or 3.3 (?) could be used with a separate QUIC interface. Internal OpenSSL header files might be required, so there would still be a version dependency on the built (binary) code, but not necessarily the source code.

This could be done in parallel with the existing QUIC repo; it wouldn't impact that development.

[talregev]

This is similar to my suggestion to convert quic tls to library on top of open ssl, and install it along side.
It Also can be installed in vcpkg that way and get to more people. (and enable the http3 protocol in many libraries).
So I am support this way.

[wbl]

I'm worried that the performance characteristics of the pluggable record layer might be prohibitive. We've seen pretty bad designs come out of OpenSSL in the past favoring extreme late binding over performance. If the interface is designed for their QUIC implementation it might work out, and if this something they are going to support it could really help, although would bring slightly different packaging.

[nibanks]

MsQuic has extensive performance tests and if such a chance is made, we can use it to validate performance.

[tmshort]

This was designed explicitly for their QUIC support. We would use it for the downstream data send and receive.

[talregev]

You should talk with openssl and share your thoughts.

[talregev]

When you implement quic API over pluggable record-layer features of OpenSSL (3.2 or 3.3), Can you open a new repo. for example quictls for the new code there?