Soliciting feedback for advice related to roadmap and feature prioritization for the OpenSSL Library
Nicola Tuveri
Public
Seen by 15
Hello fellow academics!
First of all, thank you for entrusting me with the privilege of representing our community within the Foundation BAC.
Yesterday, we held our inaugural kick-off meeting and began discussing some key topics where we could provide valuable advice and insight.
One initiative I am particularly excited about, since the announcement of the new advisory committees, is the opportunity to gather input from our broader communities to inform both the OpenSSL Foundation and the OpenSSL Corporation. Historically, it has been challenging for non-developers to influence the direction of OpenSSL, but this new structure provides an excellent avenue to bridge that gap.
This is where your feedback becomes invaluable. What features, enhancements, or priorities do you think OpenSSL should consider as it develops its future roadmap? Are there specific pain points, missing features, or areas for improvement that you’d like to see addressed?
Your insights could help shape a more inclusive, responsive, and forward-looking OpenSSL. Feel free to share your thoughts, whether they’re technical, strategic, or focused on accessibility and documentation. Every perspective matters!
Looking forward to hearing from you all.
Nicola Tuveri Thu 23 Jan 2025 11:31AM
@Peter Gutmann thanks! noted!
Peter Gutmann Thu 23 Jan 2025 2:06AM
A second one, and this is more of a nice-to-have, would be proper support for TLS-LTS, https://datatracker.ietf.org/doc/draft-gutmann-tls-lts for systems that will be stuck on TLS 1.2 for a long time. There's a patch set that seems to implement this (I've only seen an extract, I think kludge set would be a better term for it), but having it officially present would be good. It's a fairly minor set of changes so hopefully shouldn't be much work.
Nicola Tuveri Thu 23 Jan 2025 11:34AM
@Peter Gutmann we can of course bring this forward for debate in the BAC, but one objection that I could see arising is that the current policy of OpenSSL is to adopt new protocols/schemes/primitives only after they have been standardized.
I see that your draft did not meet consensus in the TLS WG for adoption, do you have plans to push this work forward through other venues inside/outside IETF?
Peter Gutmann Fri 24 Jan 2025 11:54AM
@Nicola Tuveri It's progressing through the IETF ISE channel instead of the TLS WG one. It got caught up in a political catch-22, before TLS 1.3 was finalised I was asked to put it on hold while the TLS 1.3 work progressed, and then once TLS 1.3 was finished this changed to "we've got TLS 1.3, why should we bother with 1.2 any more?"... ignoring the hundreds of millions, possibly billions of devices still running in TLS 1.0-1.2 infrastructure which haven't even heard of TLS 1.3, and possibly never will.
Stephen Farrell Thu 23 Jan 2025 12:11PM
I'll argue that prioritising getting ECH support merged would be a good one. Browsers and cloudflare support ECH and we need to get web servers that use the library to have that feature for it to really get deployed. I've been working with maintainers on getting code merged to a feature branch but it's slow progress as there's quite a chunk of code involved and the maintainers have a hard time getting time to do the reviews.
Peter Gutmann · Thu 23 Jan 2025 2:02AM
Thanks for the chance to provide input! Two things come to mind, a biggie would be a move away from the proprietary PEM format for private keys to a standard one like PKCS #15 (personal preference) or at least PKCS #12 despite all of its problems. I don't know how many times I've had a query along the lines of "we have an existing key (and typically an associated expensive certificate) in PEM format, how do we get it into a form that anything else can understand?", to which the response is a lot of to-and-fro about how to use the OpenSSL app to manually convert it... and then the other 200 keys on other machines that need the same treatment. Using a standard format by default would remove this pain point.