Re: A side meeting on OpenSSL's plans about QUIC

[Peter Gutmann <[e-mail]>]

Reposted here (with permission) since I think it's important to get this on
the record for discussion on this list.  It's always interesting to read about
protocol implementation details, especially if others can learn from them.

Peter.

-- Snip --

Please change your mind about your announced release plans
Salz, Rich rsalz at akamai.com
Fri Oct 29 15:13:35 UTC 2021

I think the current plan, to do QUIC over a series of releases, is a mistake
it seems seriously likely to make OpenSSL less relevant.  Some reasons follow.

According to https://www.openssl.org/blog/blog/2019/11/07/3.0-update/, the
initial target for 3.0 was end of 2019, but the announced release date was
moved once to early Q2 2020, then early Q4 2020. It was ultimately released
early Q4 2021. That’s a slip of nearly two years. Sure, I know COVID affected
many things, but the impact on OpenSSL, whose fellows all worked from home
offices, should have been slight. Regardless, the focus of this release was on
*cryptography* something which is highly familiar to the team.

With this release, as detailed in
https://www.mail-archive.com/[e-mail]/msg02585.html, it
appears that OpenSSL is trying to do two things. Have a more rapid release
cadence -- the stated objective is six months -- and implement QUIC over a
series of releases. To keep a six-month cycle probably means five months of
planning and development. During the 3.0 work, the project hired, and then
fired, a project manager to keep things on track. Are you going to hire
another? The project has a very bad history of meeting time-bounded deadlines.
This is not surprising; software engineers tend to chronically under-estimate
the amount of time needed.

In addition, an LTS release will be either 3.1 if available by next September,
or the current 3.0. Neither alternative is good. The section on QUIC discusses
the MVP for that release. Making an LTS release that is based on a radical
restructuring of the record layer, not to mention having a half-baked and
useless QUIC release, does not meet the community's needs. It is also
exceedingly unlikely to be ready within a year, which means 3.0 will be the
next LTS release. This means that many issues found by the community while
adopting 3.0 will go unaddressed in LTS, as each will have to pass the "is
this a bug-fix" barrier or be approved as an exception. Exceptions are *wrong*
for an LTS release. The next LTS release should be just cleanup, fixes, and
usability enhancements found during 3.0 deployments.

The level of technical detail in the release requirements are curious. They go
into great detail and greatly constrain the OTC. This was not done for FIPS,
where the design was led by the OTC and had involvement from the project
sponsors. I know that some OTC members are not pleased with this level of
detail, and I don't blame them. It might be useful for the OMC to release a
rationale. Why is it necessary to "implement QUIC" when instead the directive
could have been "support QUIC"?  If the API from
https://github.com/openssl/openssl/pull/8797 is so distasteful (yes, enum's in
function parameters are not OpenSSL style), it would have been better if the
project convened leading TLS and QUIC implementors to come up with a new one.
That would have shown true leadership, and I know some of those affected by
these plans would have supported that.

QUIC is a subtle protocol. Its evolution within the IETF took several years,
and the development staff at major implementations includes full-time
developers, QA engineers, and documentation writers. Currently OpenSSL has
five full-time fellows, and none of them have any recognized experience in
implementing transport protocols. Look at the complexity in the BIO code
around DNS and handling IPv4/IPv6 address families portably. While the project
currently has DTLS, which is a UDP protocol, QUIC is more like the former than
the latter.

The MVP does not rise to the level of minimally viable: A single-stream client
that can be added to the s_client application without significant API changes.
There is no mention of server implementation -- will there be one? It's not
even mentioned as a stretch goal for the first release. Is that bifurcation of
the community intentional? If it's an oversight, it can be seen as yet another
indication that the QUIC plan is not well thought out.

There are numerous freely available QUIC implementations. For example, look at
https://interop.seemann.io/ which shows 14. It is easy to get an
implementation added to that, and yet OpenSSL is only promising to interop
against one implementation. Why aren't Google, bundled with Chrome and
Android, or Microsoft, bundled with Windows, or Apple,  bundled into iOS 15,
tested? Perhaps the reason is that only client-side is part of the first
release. Again, the Internet doesn't need yet another limited client-side-only
QUIC implementation, and the plan as currently stated will force anyone
deploying a server to go elsewhere. Even if you add single-stream server
support to the MVP, that will not be sufficient for any server that wants to
support modern browsers.

The additional API in PR8797 is under 2000 lines. It supports, at least,
Microsoft MSQUIC, Google QUIC, the QUIC implementation in Node.js, and ngtcp2
by Tatsuhiro Tsujikawa. The API devised by David Benjamin and ported by Todd
in the PR, is clearly something the QUIC community wants. In addition, Apache
Traffic Server implements QUIC and recommends QuicTLS, not OpenSSL. Nginx
supports using the QuicTLS fork during their development. A complete QUIC
implementation by OpenSSL will take several years and certainly be many times
that.

An OpenSSL implementation is not something the QUIC community wants. The
leaders of the MSQUIC, gQUIC, Curl, and Node projects have all spoken out
against OpenSSL implementing QUIC. Many people in the community commented in
PR 8797 against the OpenSSL plan, including Lars Eggert, IETF Chair and former
QUIC WG Chair, Martin Duke, IETF Transport Area Director, and Lucas Pardue,
co-chair of the QUIC WG.

It is important to realize that QUIC is not "done." While the initial
documents are RFCs, looking at https://datatracker.ietf.org/wg/quic/documents/
, shows that there are nearly a dozen drafts in preparation. Certainly not all
of them will advance to RFC, but many will. Also, other IETF WG's are using
QUIC, include ALPS in the TLS WG, and the multiplexed transport on top of QUIC
known as MASQUE WG. There will be *significant* progress on QUIC during the
time OpenSSL is distracted by playing catch-up. As little work can be done by
anyone on new features until a full-featured implementation is available,
OpenSSL will forever lag behind.

By focusing on QUIC, the project is also not serving its existing community.
The OMC plan has already tossed aside DTLS 1.3, no matter when it is finished.
What other worthwhile, standardized, work will be given short shrift? The plan
makes no mention of existing PR's, or possible new ones.

Now speaking for myself, I am concerned that the the implementation of the
stated plan will not be good. The performance impact of the 3.0 provider
interface have not been fully quantified, but experience shows the overhead is
significant. For example, Microsoft recommends avoiding the 3.0 version of
QuicTLS for performance reasons. I also suggest a careful reading of IETF RFC
9001. While it is possible to do a "pluggable" record implementation, that RFC
and wide implementation experience, shows that it is not necessary. This is
not like a new crypto algorithm or provider; a pluggable record layer to
accommodate TLS, DTLS, KTLS, and QUIC, seems like a fool's errand, perhaps
brought on by the hubris of thinking that the world needs OpenSSL to implement
QUIC.  It doesn't.  It needs OpenSSL to implement OpenSSL cryptography.

Thank you for having read this far. I apologize if my strong language offended
anyone, that was not my intent. I only wish to convey, as strongly as possible
through the medium of email, that the path the project is on is bad and will
force people to leave.  To repeat something I've seen posted before, "No
matter how far down the wrong road you've gone, turn back."

Most sincerely,
-rich $alz