RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2157950 - Deal with the new EMS requirement for TLS 1.2 in FIPS mode [rhel-9.3.0]
Summary: Deal with the new EMS requirement for TLS 1.2 in FIPS mode [rhel-9.3.0]
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: nss
Version: 9.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Bob Relyea
QA Contact: Alexander Sosedkin
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks: 2229793
TreeView+ depends on / blocked
 
Reported: 2023-01-03 16:53 UTC by Hubert Kario
Modified: 2023-11-28 11:24 UTC (History)
4 users (show)

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.
Clone Of:
: 2229793 (view as bug list)
Environment:
Last Closed: 2023-11-28 11:23:54 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker CRYPTO-9242 0 None None None 2023-01-04 17:13:47 UTC
Red Hat Issue Tracker RHELPLAN-143560 0 None None None 2023-01-03 17:04:00 UTC

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
Note You need to log in before you can comment on or make changes to this bug.