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?