OpenSSL Feature Requests and Priorities

@Clemens Lang I mean if openssh-portable is not able to use algorithms exclusively from openssl, it sort of defeats the purpose. I have had pushback on my patches to use OpenSSLv3 APIs; and also moving away from SHA1 to SHA256 for non-security-usage to create session-id. It is annoying that openssh has grown cryptographic implementations - one had to put openssh through FIPS validation; and there was a period of time when one didn't need to do that; and now we are back there.

@Dimitri John Ledkov (Chainguard) My team at Cisco is doing this as well (using OpenSSL Provider or FIPS Provider). We also have an RFC to use pure PQ algs as well that has received major pushback (basically a no way), even though NIAP requires these. The openssh hybrids (IIRC) aren't FIPS'able either (x25519) so we have done our own via OpenSSL there as well.

@Jeff Johnson We've been dealing with this at Akamai using some patches from Red Hat: a colleague of mine Bill Ahern was involved deeply in this.

@Watson Ladd Since we all seem to be dealing with the same issue, maybe it would be good to meet and provide a united front or plan? Thoughts?

@Jeff Johnson We're not super concerned about NIAP's requirement of pure PQ algos for key exchange. If pure isn't available (and it doesn't seem like a pure PQ proposal would ever fly in the IETF SSH working group), I bet they'll settle for the next best thing. Alternatively, they can try working without SSH.

x25519 with ML-KEM 768 should be OK for FIPS iff your ML-KEM is certified, see SP 800-227 section 4.6 (it even mentions X25519MLKEM).

We at Red Hat would certainly be open to sharing the load of writing and maintaining these OpenSSH patches.

Re SHA-1 and MD5 usage, at Chainguard, we see clearly that both SHA-1 and MD5 are used extensively for non-security purposes as a generic digest. And we are adding both of these to the base provider without any `fips=` value, meaning one can get to them with `?fips=yes` and `-fips` and many existing projects already know how to do that (python dotnet) and others can be taught to do that. We are trying to only allow simple digest, and block HMAC and signatures. This is based on FIPS 140-3 IG 2.4.A. See detailed explanation of what we are doing there at https://edu.chainguard.dev/chainguard/fips/non-approved-algorithms/ if others are interested, we can introduce this wider in OpenSSL. Possibly as some sort of "fips-unapproved" provider, which is intentionally outside of the FIPS provider boundary; does not need to go through FIPS validation; can be loaded along side base and fips providers, and intentionally is there to support computing digests only - essentially as a CRC functionality only.

Provide source code compat with openssl forks

Specifically, things like EVP_sha1 can become macros only, in a compat header or some such - or activated by compat define. Such that there is more source code compatibility with boringcrypto/aws-lc/libressl. Similarly we can do that even for complex HMAC -> EVP_MAC transition. Intention is that ABI does not have such functions, but source code can compile against either openssl or boringcrypto unmodified and use "the right" modern EVP APIs.

Please support RFC 7093 Section 2(1) SHA256/160 for subjectKeyIdentifier=hash

This is for SHA1 deprecation and matches what already letsencrypt does by default, as well as most other libraries.

See https://github.com/openssl/openssl/issues/28381

Please support SHA-256 for OCSP

https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc5019bis-12 and other drafts are in a queue to be published soon/eventually. It would be nice if openssl was able to support OCSP with SHA-256. Or somehow else support unapproved SHA-1 when operating with fips provider.

For Versa Networks, we are interested in:

• PQC Backporting: Request to backport new PQC features from recent and future non-LTS releases to LTS OpenSSL 3.5 as new drafts, RFCs, FIPS, and NIAP requirements evolve. Since OpenSSL 3.5 is the latest LTS including many PQC features, it will likely become the de facto LTS version for PQC. This adoption will likely be driven by CNSA 2.0 requirements for various DoD use cases over the next 1–3 years.

• LMS Verification: Request to backport the LMS-verification algorithm to LTS OpenSSL 3.5. While we might not need LMS for many use cases, if ML-DSA is explicitly confirmed soon in the NIAP protection profile for DoD, we must cover worst-case scenarios—specifically where BIOS/firmware vendors support or use only LMS for signing.

• DTLS 1.3: Request for DTLS 1.3 support.

• QKD Provider: Request for a QKD provider compliant with ETSI-014.

• Runtime Control APIs: Request for an equivalent to the ENG_CTRL/ENG_CTRL_CMD_STRING() APIs to control the runtime behavior of the provider (formerly "crypto engine"). These APIs, which allowed for finer control over cryptographic operations, were deprecated during the migration to 3.x.

• Performance: Scale and performance improvements for TLS and QUIC.

@Suresh Keisam Backporting major features into an LTS release would be a significant change. I don't think OpenSSL has ever done that before, and I'm not convinced it should start to do that now.

I've a dim recollection that it was done once. I agree, it shouldn't become a common thing and each case should be carefully considered with a bias to not doing it.

@Paul Dale @Clemens Lang I agree that it would be a significant change and shouldn't become a common thing. However, PQC is a once-in-a-lifetime event/change, and it presents a great opportunity for all of us. It would be great if we could make at least the main features and algorithms (ML-DSA and LMS for now) available in a LTS release, as the payoff will be huge for everyone in the long term.

ML-DSA is included in the 3.5 release. LMS is not.