Network, Open Source, Security

The QUIC API OpenSSL will not provide

6 Comments

In a world that is now gradually adopting HTTP/3 (which, as you know, is implemented over QUIC), the problem with the missing API for QUIC is still a key problem.

There are a number of existing QUIC library implementation now since a few years back, and they are slowly maturing. The QUIC protocol became RFC 9000 and friends, but the most popular TLS libraries still don’t provide the necessary APIs to make QUIC libraries possible to use them.

Example that makes people want HTTP/3

Example tweet of what makes people keen on experimenting and deploying HTTP/3.

OpenSSL PR8797

For a long time, many people and projects (including yours truly) in the QUIC community were eagerly following the OpenSSL Pull Request 8797, which introduced the necessary QUIC APIs into OpenSSL. This change brought the same API to OpenSSL that BoringSSL already provides and as such the API has already been used and tested out by several independent implementations.

Implementations have a problem to ship to the world based on BoringSSL since that’s a TLS library without versions and proper releases, so it is not a good choice for the big wide world. OpenSSL is already the most widely used TLS library out there and lots of applications are already made to use that.

Delays made quictls happen

The OpenSSL PR8797 was delayed back in February 2020 on when the OpenSSL management committee (OMC) decreed that they would not deal with that PR until after their pending 3.0.0 release had shipped.

“It is our expectation that once the 3.0 release is done, QUIC will become a significant focus of our effort.”

OpenSSL then proceeded and their 3.0.0 release was delayed significantly compared to their initial time schedule.

In March 2021, Microsoft and Akamai announced quictls, an OpenSSL fork with the express idea to ship OpenSSL + the QUIC API. They didn’t want to wait for OpenSSL to do it.

Several QUIC libraries can now use quictls. quictls has kept their fork up to date and now offers the equivalent of OpenSSL 3.0.0 + the QUIC API.

While we’ve been waiting for OpenSSL to adopt the API.

OpenSSL makes a turn instead

Then came the next blow to everyone’s expectations. An autumn surprise. On October 13, the OpenSSL OMC announces:

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).

OpenSSL has decided to implement a complete QUIC stack on their own and with the given time line it sounds like it will take them a few years (?) to ship. And instead of providing the API lots of implementers have been been waiting for so long, they explicitly say that it is a non-goal at the start:

The MVP will not contain a library API for an HTTP/3 implementation (it is a non-goal of the initial release).

I didn’t write my own QUIC implementation but I’ve followed the work of several of the implementations fairly closely and it is fairly complicated journey they set out for themselves – for very unclear reasons. There already exist several high quality QUIC libraries, why does OpenSSL think they need to make yet another one? They seem to be overloaded with work already before, which the long delays of the 3.0.0 release seemed to show, how are they going to be able to add a complete new stack implementation of top of this? The future will tell.

PR8797 closed

On October 20 2021, the pull request that was created in April 2019, is finally closed for real as a “won’t fix”.

Screenshot of the actual closing of the PR

Where are we now?

The lack of a QUIC API in OpenSSL has held us back and with this move from OpenSSL, it will continue to hold us back for an uncertain amount of time going forward.

QUIC stacks will have to stick to using or switching to other libraries.

I’m disappointed.

James Snell, one of the key contributors on the QUIC and HTTP/3 work in nodejs tweeted:

Credits

Image by Marzena P. from Pixabay

6 thoughts on “The QUIC API OpenSSL will not provide”

  1. Push quictls hard. Incorproate bugfixes from upstream OpenSSL. Maybe it will become the defacto new SSL library.

    1. QuicTLS is already kept in a manner to easily incorporate upstream fixes, and is scoped to just add the APIs necessary for quic handshakes. For the sanity of the ecosystem as a whole, we’d rather not have to have a separate fork of OpenSSL – it was meant as a stopgap solution until OpenSSL was done with 3.0 which had a hard deadline to get submitted for FIPS 140-2 certification before that window closed.
      The 8797 PR may not be the exact API design that OpenSSL would add – it has some patterns from BoringSSL that are inconsistent with other APIs – but the ecosystem needs a solution and it seem that the OMC’s plans are not accommodating that feedback.
      OpenSSL is a critical piece of the internet infrastructure as the main crypto library used for TLS. The impact that crypto flaws introduce to the ecosystem are a reason to have fewer implementations so that all the weight can be put behind one arrow, rather having a disparate set of TLS implementations, each of which their own issues and attack surface.

  2. I really don’t understand their decision. OpenSSL almost died twice due to code quality, resulting in two forks (LibreSSL and BoringSSL), and in a major cleanup work to address that major concern, then a much better development process helping to deal seriously with bugs. That saved them. And now almost 3 years after they’ve been aware of the work on QUIC, a committee finally decides that they’d rather insult all their users by telling them their 3 years of work can go to the trash and they can wait to have a supposedly better implementation in several more years. Not only nobody will trust them to do anything in a reasonable time frame as the last 3 years have proven, but history has also shown that OpenSSL’s design choices do not always match what end users need (including this all saga). This is pathetic. Probably that the OMC should be dissolved if it cannot steer the project correctly ? (I’m fine with the principle of not taking a PR and doing a homegrown implementation of whatever, but not after 3 years of asking everyone to wait).

    So my understanding is that OpenSSL is now a zombie project and that the new official universal and portable TLS library is quictls ?

    We really didn’t need yet another fork of that project, and it just proves its governance should seriously be questioned.

    1. Willy: I think one of the key mistakes done by OpenSSL in this saga (and maybe in more generic terms) is their complete lack of communication. They just came down from their ivory tower with these “decrees to the people”, but without explaining why they think this is reasonable for the world and the best thing for their project.

      Then they vanish again and leave us all to our confusion and speculations.

      1. Sure, but even such an explanation would come too late by now. They’ve continually be saying “let us finish 3.0.0 before responding to you” then “now that 3.0.0 is out, f*** you”. There has been an immense amount of work from various projects to get QUIC in a more or less acceptable shape based on what was available while they were not making any progress. And the only justification they give is “durable API”. By the time they finish their implementation in 5+ years, QUIC will already be at v2 or v3 and they might even give up half-way because nobody will want their outdated implementation anymore. They should only focus on their historical job: crypto+TLS and leave the protocol layers to those who know how transport layers work and who don’t want to learn crypto. There’s enough work areas in QUIC to give everyone a job, without seeing one project try to do everything from scratchwith no experience about how that will be used 🙁

Comments are closed.