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:	nss	Assignee:	Bob Relyea <rrelyea>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Alexander Sosedkin <asosedki>
Severity:	unspecified	Docs Contact:	Mirek Jahoda <mjahoda>
Priority:	medium
Version:	9.0	CC:	asosedki, cllang, mjahoda, rrelyea
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	nss-3.90.0-3.el9_2	Doc Type:	Enhancement
Doc Text:	.NSS now enforce EMS in FIPS mode The Network Security Services (NSS) libraries now contain the `TLS-REQUIRE-EMS` policy to require the Extended Master Secret (EMS) extension (RFC 7627) for all TLS 1.2 connections as mandated by the FIPS 140-3 standard. NSS use the new policy when the system-wide cryptographic policies are set to `FIPS`. If your scenario requires interoperating with legacy systems without support for EMS or TLS 1.3, you can apply the `NO-ENFORCE-EMS` system-wide cryptographic subpolicy. Such a change violates the FIPS-140-3 requirements.	Story Points:	---
Clone Of:
Clones:	2229793 (view as bug list)		Environment:
Last Closed:	2023-11-28 11:23:54 UTC	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.

Comment 17 Clemens Lang 2023-11-28 11:23:54 UTC

RHEL 9.3.0 contains nss-3.90.0-3.el9_2:

$ brew -q latest-build rhel-9.3.0 nss
nss-3.90.0-3.el9_2                        rhel-9.2.0-z          distrobaker/distrobaker.osci.redhat.com