Bug 2157950

Summary: Deal with the new EMS requirement for TLS 1.2 in FIPS mode [rhel-9.3.0]
Product: Red Hat Enterprise Linux 9 Reporter: Hubert Kario <hkario>
Component: nssAssignee: Bob Relyea <rrelyea>
Status: VERIFIED --- QA Contact: Alexander Sosedkin <asosedki>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 9.0CC: cllang, rrelyea
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: nss-3.90.0-3.el9_2 Doc Type: Enhancement
Doc Text:
Feature: A new policy has been added to NSS which allows admins to require EMS when doing tls 1.2 Reason: FIPS requires EMS. NSS does remove the indicator when not doing EMS, but we want to make our FIPS policy conform the our security policy whenever possible. crypto-policies add this policy to it's FIPS policy, which the system switches to when in FIPS mode. Result: NSS (along with openssl and gnutls) will not be able to connect to clients and servers that do not support EMS when the systen is in FIPS mode.
 Story Points: ---
Clone Of:
: 2229793 (view as bug list) Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2229793    

Description Hubert Kario 2023-01-03 16:53:57 UTC 
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.
Comment 6 Alexander Sosedkin 2023-08-09 15:10:08 UTC 
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.