Please change your mind about your announced release plans

[Salz, Rich]

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/openssl-project@openssl.org/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