OpenSSL Feature Requests and Priorities
All,
We have been asked by the BAC to provide a list of features or capabilities that the large business community (LBC) would like OpenSSL to deliver (or focus on).
In that spirit can each of you provide a prioritized list of things that your large business would like? For extra credit, why it's important would also be valuable.
For example, Cisco and Comcast believe that DTLS1.3 should be prioritized and delivered ASAP. DTLS1.3 is heavily used in VPN as well as streaming platforms where the installed base cannot be easily migrated to QUIC. Since PQ cannot be supported on DTLS1.2 the OpenSSL doesn't fully support PQ until DTLS1.3 is delivered. So PQ and DTLS1.3 are very important to Cisco as well as Comcast.
Maybe this isn't the case for your large business. But what is important to your business? Is it performance? Is it support for some new RFC? What would be valuable to your business.
This forum provides the opportunity to have your say into the OpenSSL roadmap. Please, help OpenSSL by having your voice heard!
thx,
-jj
Jeff Johnson Tue 25 Nov 2025 4:06PM
No problem at all! I'm looking forward to some turkey as well! Have a good one!!
Clemens Lang Tue 25 Nov 2025 7:53PM
For Red Hat, we're interested in:
DTLS 1.3, for PQC in non-HTTP protocols that have not or will not move to QUIC
Performance; not necessarily because we have big problems with the current performance, but because we really want to avoid more upstream projects deciding to chose some other fork as their default that we'd then have to revert downstream
A better way to phase out SHA-1. We have downstream patches, but a better upstream method would be good. See #17662 and #19084 that were an attempt to get that done, but haven't gotten anywhere since we couldn't really agree on how to best implement this.
Improving the contribution experience. I believe this helps us all long-term.
This is just a quick list, haven't had a discussion about it with the team yet. I'll ask around for some more input.
Jeff Johnson Tue 25 Nov 2025 8:42PM
@Clemens Lang Thanks so much Clemens! Nice to hear from you! If I was able to have a meeting with LBC along with OpenSSL would you be willing to participate?
thx,
-jj
Clemens Lang Wed 26 Nov 2025 10:51AM
@Jeff Johnson Sure, if it works time-wise for me, I'll be happy to join.
Dmitry Belyavsky Tue 25 Nov 2025 11:53PM
@Clemens LangI would add the improvement of EVP_SKEY support to the list
Watson Ladd Tue 25 Nov 2025 8:18PM
Some preliminary thoughts.
Support for the BoringSSL QUIC support API. We need a full featured QUIC stack so use Google Quiche and having to maintain our own patches on top of OpenSSL for this is increasingly untenable. Migration to the OpenSSL one is a nonstarter given the degree of integration with our main connection processor we have.
Better tracking of backwards compatibility issues. Surprises with changes to FIPS requirements forcing support for some option shouldn't happen: we should be able to alert our internal consumers what's happening ahead of time so they can migrate.
Performance at scale absolutely matters (many hundreds of thousands of connections a second, gigabytes of bandwidth), and we don't need dynamic loading/unloading of providers. Providers were helpful in getting PQ ready early.
Better FIPS policy: we often end up having to avoid FIPS compliant constructions with an impact to security because of what OpenSSL has chosen. AES-GCM in particular has been an issue, where the security policy limits it to TLS.
Build system migration to CMake or similar. Right now we have to wrap a bunch of changes around to handle the integration with our internal packaging and development cycle, and the integration never really works right. With CMake we'd get that for free.
Jeff Johnson Tue 25 Nov 2025 8:41PM
@Watson Ladd Thanks! I really appreciate your input! I'll compile the total list and provide them back to OpenSSL. Maybe a meeting to hear the concerns of the LBC would be good? Would you participate in such a meeting?
thx,
-jj
Watson Ladd Mon 1 Dec 2025 6:08PM
@Jeff Johnson Yeah, we would participate
Tim Hudson Tue 25 Nov 2025 9:01PM
@Watson Ladd For "Support for the BoringSSL QUIC support API. We need a full featured QUIC stack so use Google Quiche and having to maintain our own patches on top of OpenSSL for this is increasingly untenable."
You should direct that request to the Google Quiche maintainers where it properly belongs - to add support for the officially documented interface in OpenSSL for external QUIC TLS usage. This is what the other independent QUIC stacks have done - including msquic and ngtcp2. nginx also has a pure OpenSSL solution which predates the official API for external QUIC stacks to use. The old BoringSSL QUIC APIs aren't going to be added into base OpenSSL - that ship has long since sailed. And we aren't going to backfit those APIs into earlier releases (the other related request that has been raised).
Most QUIC implementations support a range of TLS crypto interfaces - the concept that there was just the one single API for BoringSSL and everyone used it and life was simple and no other changes were required isn't reality. The set of interfaces are varied and QUIC stack maintainers deal with this issue.
If you chose to sit on top of BoringSSL or a using a BoringSSL dependent package, then you have to be willing to pay the costs of doing so (something which Google makes abundantly clear in their documentation). We have never seen this as an "OpenSSL" issue to solve and we respect that other projects make other decisions about what to depend on. If you have a collection of companies that also face this same issue in terms of increasing costs of maintaining your own OpenSSL fork, then perhaps you can collectively work to contribute patches to Quiche - assuming you can convince the Quiche maintainers that this is something they should do.
I note that there are no open issues on quiche to support the official OpenSSL interfaces that I can see with a quick look.
Watson Ladd · Tue 25 Nov 2025 4:04PM
It's Thanksgiving this week, we'll respond longer next week as a result.