OpenSSL to implement QUIC

[tmshort]

The OpenSSL Management Committee mailed the following (quoted below) to the openssl-project list.

In light of this, we will continue to rebase the QUIC API changes on top of 1.1.1 and 3.0 releases; both of which remain fully supported through September 2022.

Source

OMC Release Requirements

This document provides information on the OMC requirements and expectations for the next release after 3.0 and subsequent releases.

Release timeframe

The OMC objective is to have shorter release timeframes, with releases occurring every six months.

1.1.1 is our current LTS release and we are committed to specifying another one by September 2022. Therefore OMC expects that the next release (3.1) will be the next LTS. In the event that 3.1 is not released by September 2022 then the fallback position is for 3.0 to be the LTS.

Platform List

Follow the to-be-published platform policy update covering the primary and secondary platforms.

QUIC

The focus for the next releases is QUIC, with the objective of providing a fully functional QUIC implementation over a series of releases (2-3).

The current libssl record layer includes support for TLS, DTLS and KTLS. QUIC will introduce another variant and there may be more over time. The OMC requires a pluggable record layer interface to be implemented to enable this to be less intrusive, more maintainable, and to harmonize the existing record layer interactions between TLS, DTLS, KTLS and the planned QUIC protocols.

The application must have the ability to be in control of the event loop without requiring callbacks to process the various events. An application must also have the ability to operate in “blocking” mode.

The QUIC implementation must include at least one congestion control algorithm. The fully functional release will provide the ability to plug in more implementations (via a provider).

The minimum viable product (MVP) for the next release is a pluggable record layer interface and a single stream QUIC client in the form of s_client that does not require significant API changes. In the MVP, interoperability should be prioritized over strict standards compliance.

The MVP will not contain a library API for an HTTP/3 implementation (it is a non-goal of the initial release). Our expectation is that other libraries will be able to use OpenSSL to build an HTTP/3 client on top of OpenSSL for the initial release.

Once we have a fully functional QUIC implementation (in a subsequent release), it should be possible for external libraries to be able to use the pluggable record layer interface and it should offer a stable ABI (via a provider).

The next major release number is intended to be reserved for the fully functional QUIC release (this does not imply we expect API breakage to occur as part of this activity - we can change major release numbers even if APIs remain compatible).

PR#8797 will not be merged and compatibility with the APIs proposed in that PR is a non-goal.

We do not plan to place protocol versions themselves in separate providers at this stage.

For the MVP a single interop target (i.e. the server implementation list):

1. Cloudfare - https://cloudflare-quic.com/

Testing against other implementations is not a release requirement for the MVP.

DTLS

DTLS-1.3 is not a target for any release until it becomes an RFC. DTLS-1.3 is not a target for the next release even if it becomes an RFC.

[nibanks]

We've set aside some time for an IETF 112 side meeting to discuss this and possible next steps. It's next Wed (Nov 10th). ICS file

[tmshort]

Some local times (2021-11-10 unless noted)
10:30 PST (Seattle)
13:30 EST Philadelphia IETF 114)
18:30 UTC (London)
19:30 CET (Berlin/Prague/Rome/Paris)
01:30 2021-11-11 (Bangkok IETF 113)
Time Calculator