OpenSSL Communities
Wed 19 Feb 2025 4:44PM

Priorities for 3.6

JE Jon Ericson Public Seen by 33

We are fast approaching the release of OpenSSL 3.5. As the features for that release get locked in, we’re looking ahead to what might go into the October release (3.6). The Foundation would like your help, as representatives of your various communities, in prioritizing that work.

It’s important to understand that OpenSSL has time-based releases so there’s no guarantee that any particular feature will be ready for 3.6. Some features will be difficult to complete in the timeframe and others could be done well before the feature branch merge date. We are asking that the Foundation BAC focus on desirability for non-commercial purposes when prioritizing. Please do not factor the degree of difficulty at this stage.

Below is a list of features we are considering. Feel free to use this as a starting point but we very much welcome adding any other potential features for consideration.

  • Encrypted Client Hello
  • DTLS-1.3
  • BIGNUM refactoring for constant-time
  • Simplified CLI
    • New command to meet modern standards
  • Command-line UI for attribute certificates
  • Advanced QUIC features - 0-RTT, path migration
  • QUIC stack performance improvements
  • Providers/fetching/decoders performance improvements
  • Finalizing replacements of legacy constructs / functionality
    • Example: GOST support in CMS would be lost in 4.0 when ENGINE support is dropped
  • Backlog of Github issues and PRs
  • Documenting (or removing) undocumented API functions
  • More guide-style documentation
    • When to use what and not just how to use
    • Flag the difference between functionality that you can use without knowing everything and which are low-level features that the average user should avoid
  • Increasing test coverage
  • Additional PQC
    • LMS
    • X509 integration

Please check in with the community you represent and meet together as a committee. Jon Ericson can help set up a call, if that would be helpful. We are looking forward to your input!

DB

Dmitry Belyavsky Wed 19 Feb 2025 7:49PM

May I extend this list?

E.g. there are a lot to do related to the support of opaque symmetric key objects

JE

Jon Ericson Wed 19 Feb 2025 8:09PM

@beldmit Yes please! The list is intended to give the BAC a place to start. We hope there will be more suggestions and that the list will evolve over time.

PD

Paul Dale Wed 19 Feb 2025 11:10PM

What kind of deadline is there to provide input here?

The reason I ask is that gaining some practical experience with the upcoming 3.5 release might prompt some additional PQC changes. Do we have that long to finalise the 3.6 desirables?

JE

Jon Ericson Thu 20 Feb 2025 1:29AM

@ppzgs1 Since work on 3.5 is wrapping up, it would be helpful to have some data from the BAC fairly soon. But we'd rather get careful consideration than rush to get a list out to meet a fairly arbitrary deadline. The Foundation has some very informed guesses about what the various communities would find desirable, so it's not as if we will be working blind.

I think it's also reasonable to change the order based on new information. If experience with 3.5 features suggest they need more work, I would expect priorities could change.

MC

Matt Caswell Thu 27 Feb 2025 9:57AM

I'd note that the 3.5 release date is currently set as 8th April. So by 9th April we are going to be working on delivering stuff. It would be nice to get input well before that in order to give us an opportunity to size the items and then work out what we can actually deliver. So perhaps mid-march would be a good target to get an initial list. Say 14th? Is that achievable?

PD

Paul Dale Tue 25 Feb 2025 11:08PM

After a discussion amongst the committers the following suggestions were put forward/supported:

  • BIGNUM constant time support was the most popular item. The relevant issue is #6640. I expect there is more support than appears on the thread because David originally raised the issue and has been vocal about this for approaching seven years. Additionally, six OTC members (all of whom are committers) supported the OTC vote to make this high priority The vote seemingly was never actioned and certainly did not receive any response from the directors.

  • The next most popular item was improvements to testing and the testing infrastructure. This included fuzzing, coverage and testing more generally. CMS, PKCS #12 and HTTP were singled out for better coverage testing, but the coverage ask was wider and more general. Improved fuzzing and better testing aren't mentioned in the list above, although coverage is.

  • On a related note, Shane suggested ABI testing of the assembly. Refer to #21522.

  • Frederik wanted DTLS 1.3 to be made a higher priority because the work is stalled pending reviews..

  • Kurt expressed a desire for IO uring for QUIC transmit and receive to allow zero copy semantics (excluding the encryption/decryption). Single copy (i.e. no copy apart from the encrypt/decrypt step) was a stated desirable in the QUIC work, but not entirely achieved.

  • Shane noted that hybrid PQ signatures are desirable.

  • Shane also asked for the next round of PQ algorithms to be included when standardised.

  • More generally, improvements to performance are desirable, although exactly what wasn't quantified. The list above mentioned providers, fetching and decoders explicitly. I see this ask as more general in nature.

  • Again more generally, improvements to security was deemed to be desirable. Specific areas were not pinpointed.

Finally, Kurt asked that links to relevant issues that contain more details and sub-items be included in the future. This seems like a reasonable and worthwhile suggestion.

JE

Jon Ericson Thu 27 Feb 2025 2:09AM

@ppzgs1 Thanks for putting this summary together!

MC

Matt Caswell Thu 27 Feb 2025 9:35AM

Thanks @Paul Dale. That's useful input to the discussion. What we really need as an output from the exercise is a consolidated list from the BAC in priority order. I would probably concentrate on the top 5 or 6 most important things. We only have limited bandwidth - and we have to incorporate priorities from the Corporation too - so we're unlikely to get to anything in the 3.6 timeframe beyond the top priority items. I envisage a process where, once we know what the top priorities might be, we (the engineering team) then spend some time trying to figure out the relative sizes of those things, and working out what might fit. From there we can decide the actual things we are going to target for 3.6. Moving forwards beyond 3.6 it would be helpful to maintain a prioritised list which the BAC regularly reviews and updates.