QUIC is a new protocol which the IETF talks about as A UDP-Based Multiplexed and Secure Transport, and has attracted a lot of attention lately. The OpenSSL Management Committee (OMC) have followed the development with interest, and we feel that we owe it to the community to say where we stand on this, and on the inclusion of support for this protocol in our libraries.
To begin with, nothing written here is a policy decision or similar. It’s a collective view of the current consensus within the OMC.
We believe that the inclusion of QUIC support in OpenSSL is extremely important and there is an intention to provide it in a future version of OpenSSL. This may be in the form of an API to enable TLS integration into 3rd party QUIC products, or it may be in the form of a complete QUIC transport protocol implementation.
Whichever form our QUIC solution takes, our desire is to offer a complete and stable API. This requires an API and solution design, and also that the protocol itself has reached a level of stability. Judging from IETF’s datatracker at the moment of writing, QUIC is still at a point in its development where it is difficult to predict what stability to expect. Based on that, and our recent experience with the TLSv1.3 implementation, we consider there to be a high risk that the IETF process will not have reached sufficient maturity by the time that we need to freeze the OpenSSL 3.0 APIs when we release beta1 in June of this year.
The current focus of our development efforts is on OpenSSL 3.0. There is much work to be done and there are a number of alpha and beta releases planned in the coming months. Whilst QUIC is very important, it is not on the roadmap for the 3.0 release. We do not want to distract our development resources away from that work, meaning that there is insufficient time for us to do the QUIC design to the standard that we want.
It is our expectation that once the 3.0 release is done, QUIC will become a significant focus of our effort. By this time we hope that the IETF process will have reached sufficient maturity that we can design an API that is acceptable for the long term.
We gladly accept community contributions where they align with established project goals, and existing APIs. We have been offered a shim for interfacing other QUIC libraries on top of OpenSSL’s libraries based on one particular implementation’s requirements. It is not a contribution of QUIC support in itself. Rather, it is a bridge between an external implementation that is still evolving, and the OpenSSL library.
After much consideration, we have collectively concluded that this would be an experimental / temporary solution while waiting for a future more complete solution and API, which doesn’t align with our desire to offer a stable API. We believe that there is a high risk that the requirements for that API will change over time. Given our API stability policies this could result in us having to support an API that is no longer optimal for a very long time.
We believe it is more important to get a stable API that is correct for the long term than an unstable API that is delivered early. Projects eager to gain experience with QUIC are welcome to test the pull request in their own unstable prototype builds. This may even enable and motivate some to make contributions to the QUIC standardisation process. What we cannot presently commit to is a stable QUIC API that meshes with the project’s long-term goals.
Therefore, while we are pleased that OpenSSL has attracted an active contributor community, and remain very supportive of, and eager for more, community involvement in the project, we are deferring the decision on how QUIC will be integrated into OpenSSL.
So in conclusion; QUIC is on our minds, but it will not be included in the OpenSSL 3.0 release. We expect more tangible action to happen after we’ve released OpenSSL 3.0.