Description of problem: The implementation guidance for FIPS 140-3 mandates that all modules verified after May 2023 must operate the TLS 1.2 KDF in Extended Master Secret mode. NSS should have a way to deal with it. One way would be to have a setting that allows requiring EMS negotiation (and abort connections if EMS extension isn't received from the peer), which could then default and lock on to enabled when working in FIPS mode.
We've discussed the nss-3.90.0-3.el9_2 behaviour and I consider the fix to be incomplete. The client aborts timely, the server proceeds with EMS-less ClientHello at first, but aborts later in the handshake. While EMS RFC reads like server can either accept or continue the handshake: > If the server receives a ClientHello without the extension, it SHOULD > abort the handshake if it does not wish to interoperate with legacy > clients. If it chooses to continue the handshake, then it MUST NOT > include the extension in the ServerHello. our current FIPS mode behaviour doesn't straightforwardly check for extensions in ServerHello/ClientHello handlers the way other libraries do, but errors out much lower when EMS is actually being used, and the resulting error propagation leads to aborting later in the handshake. This, surprisingly (to me), contradicts neither > If the server receives a ClientHello without the extension, it SHOULD > abort the handshake if it does not wish to interoperate with legacy > clients (the server does abort the handshake later) nor > If it chooses to continue the handshake, then it MUST NOT > include the extension in the ServerHello. (because the server does choose to continue the handshake). I do hold the opinion that the two sentences above are supposed to be mutually exclusive, and, at the very least, we're violating the spirit of the paragraph. But since the original FIPS requirement seems to be satisfied even with the behaviour we have, I'll spin up follow-up-fixing of this behaviour into a bug we'll evaluate separately.