X25519/X448 in FIPS mode.

[slontis]

Looking at the FIPS 140-3 IG and SP800-186 seems to indicate the following..

Signatures using ED25519/ED448 are now allowed.
Key Agreement using X25519/X448 is not allowed currently..

This seems to be the exact opposite of what we have in the FIPS provider (Based on previous advice from the lab?).

This basically means that TLS1.3 in FIPS mode cant use X25519/ED448.

Should we seek clarification from the lab, and potentially change the FIPS provider? (This will most likely break tests).

[paulidale]

The lab has been asked. No response yet.

[paulidale]

Response from lab, the gist of which is:

The curves were previously being claimed as allowed (not approved) per IG D.F Scenario 3 and IG C.A (which points to the IG D.F). Resolution ＃2 in IG D.K also states the following:

On Feb 5, 2024, the CMVP will no longer accept new submissions that implement curves permitted under IG C.A for ECDSA and ECDH but not included in SP 800-186 for use in the approved mode (i.e., IG C.A Category 2). Until this date, these will continue to be accepted as allowed per IG C.A.

So they can still be included in a validation just not approved. At least until February next year.

[swkeypair]

Excerpt from IG C.K:

And an excerpt from SP 800-186:

It's hard to see how this permits X448 / X25519 for key exchange.

[swkeypair]

Related to this - does the mechanism to allow or not allow the Edwards 25519 and 448 curves also deal with the TLS Group capabilities found in provider/common/capabilities?
This seems to be a semi-independent mechanism to allow or disallow such functionality. The changes that have occurred to put EdDSA into / out of the module did not seem to touch the same type of provisions in capabilities.c.

[paulidale]

It is independent from what I can tell. I believe that a failure to fetch rules out that algorithm from TLS. @mattcaswell would know for sure.

[mattcaswell]

The groups listed in capabilities.c should match the actual capabilities of the provider.

If X25519/X448 is not listed in capabilities.c when those algs are actually available in the provider then this would cause those key exchange algs to not be used by libssl in some cases.

If they are listed in capabilities.c when the provider does not have an implementation for them then this is less serious since we always do a fetch of the algorithm to confirm that it is available in conjunction with the propq that we have set. But we still shouldn't really list algs that the provider doesn't have.

[swkeypair]

To be sure:

• if the update is made to the FIPS provider to allow EdDSA via FIPS_DEFAULT_PROPERTIES but disallow X25519 / X448 for key agreement (as that seems to be the strong NIST position) via FIPS_UNAPPROVED_PROPERTIES,
• then a corresponding change must be made in provider/common/capabilities.c to bracket the TLS_GROUP_ENTRY rows for X25519 (idx 28) and X448 (idx 29) within and #ifndef FIPS_MODULE

Is that correct?

[mattcaswell]

Yes we should do that but its not a must. It would be very strange for a provider to be advertising key exchange TLS capabilities that it cannot itself support. But it wouldn't break anything if we did.

Note that if X25519 gets removed then it will significantly degrade TLS performance for any servers using the fips module - at least when talking to OpenSSL based TLS clients that are not also using the fips module. An OpenSSL client will default to sending an X25519 key_share in its initial ClientHello. If the server cannot support that then there will be an extra roundtrip between client/server while they find a key_share that they can both use.

[swkeypair]

OK - thanks.

[slontis]

The IG ref comes from FIPS 140-3 and we will follow that for future validations (at least until they change it - which I believe they will do at some point).
For our FIPS 140-2 validation unless instructed by the lab to change it, it should remain how it is, as that was added based on conversations with the lab at an earlier time.