OpenSSL Feature Requests and Priorities

Tim,

I'm trying to understand why you couldn't adopt the BoringSSL QUIC API instead of the more complex OpenSSL API proposal put forward. In general there's been a lot of work done by them to make safer APIs for common operations: it would be good if you could learn and use it in ways that help people writing code that need to use both.

@Watson Ladd can you elaborate more on FIPS policy and also about AES-GCM?

About AES-GCM. It is approved. One can trivially use it with internally-generated IVs => ask fips provider to generate IV, encrypt things, query the IV => pass-along IV, decrypt with externally provided IV. If for any reason you need to externally set IV (because it is actually a shared secret, is rotated, is unique, etc similar to TLS but not TLS) one too can use that in approved mode. There will be a dynamic indicator raise of non-approved but allowed usage with security claim.

# openssl list -cipher-algorithms -propquery fips=yes | grep GCM
  { 2.16.840.1.101.3.4.1.6, aes-128-gcm, id-aes128-GCM } @ fips
  { 2.16.840.1.101.3.4.1.46, aes-256-gcm, id-aes256-GCM } @ fips
  { 2.16.840.1.101.3.4.1.26, aes-192-gcm, id-aes192-GCM } @ fips

Note I have tried to provide approved way of doing aes-gcm as a code example demo, but it has not yet been merged.

See https://github.com/openssl/openssl/pull/25623 and i sort of gave up on merging that. Should this be provided as a demo?

@Dimitri John Ledkov (Chainguard) It's not the case for the 3.0 series modules: the security policy only applies to AES-GCM in TLS as I understand.

AES-GCM is not restricted in this way in the security policy. You are free to use it anywhere.

There is a restriction on the IV being internally generated (i.e. inside the FIPS boundary). There are exceptions for TLS, SSH, IPsec and one other protocol (these are specified in one of the IGs).

@Paul Dale We didn't read the relevant text in the security policy as covering every case in the IGs. Could easily have been our unfamiliarity with what exactly are the counturs.

From FIPS policy point of view - what do you want? More access to legacy, deprecated, disallowed constructs? or inverse access to future constructs compatible with draft future deprecation? (i.e. APIs that already enforce the upcoming 128 bit transition)

I too dislike the current OpenSSL FIPS policy stance - as I very much prefer forward-looking implementation, even if it causes breakage to existing usage.

Implement KDF SNMP in Default and FIPS providers

Implement KDF IKEv2 in Default and FIPS providers

Implement PQC SSH KDFs in the Default and FIPS providers and/or contribute to openssh-portable to use existing openssl primitives if possible

As far as I can tell openssh-portable has own implementation for all the PQC algorithms, and for it to be FIPS validated one now once again needs to validate openssh as a module (and/or pqc libraries it uses) or to disable PQC or to do something on either openssh and/or openssl side to implement PQC KDF / KEM etc to satisfy the needs of openssh to offer all the PQC goodies. Is anybody looking at doing openssh with PQC powered by openssl fips providers? ( i guess at @Clemens Lang )

@Dimitri John Ledkov (Chainguard) Yes, we're patching this downstream. We're having a hard time convincing the openssh-portable project to take those patches, but maybe we need to try harder (this is all work in progress at the moment).

If that fails, maybe there's a space for an openssh-portable² project where distributions collaborate to make OpenSSH use algorithms from OpenSSL?

@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.