Update TLS cipher suite requirements to address DHEat Attacks and Raccoon Attack vulnerabilities

[markverstege]

Description

A recent vulnerability in the supported TLS ciphers has been identified by the FAPI Working Group. The Consumer Data Standards inherit adoption of the same ciphers.

TLS_DHERSA*** ciphers, which are currently recommended by FAPI and are also permitted by the Consumer Data Standards, are impacted. Details of the vulnerabilities are available here.

Accordingly, contained within BCP 195, RFC9325 has:

Dropped TLS_DHE_RSA_WITH_AES from the recommended ciphers.

Based on BCP 195, recommended ciphers for TLS 1.2 and TLS 1.3 are defined by RFC9325 and TLSDHE*** cipher suites are no longer supported:

4.2. Cipher Suites for TLS 1.2

Given the foregoing considerations, implementation and deployment of the following cipher suites is RECOMMENDED:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

4.3. Cipher Suites for TLS 1.3

This document does not specify any cipher suites for TLS 1.3. Readers are referred to Section 9.1 of [RFC8446] for cipher suite recommendations.

Intention and Value of Change

Improves transaction layer security to prevent exploits including the DHEat Attack and Raccoon Attack.

Area Affected

TLS 1.2 and to a lesser extend TLS 1.3.

The list of supported ciphers documented in Security Profile -> Transaction Security -> Ciphers.

Change Proposed

It is proposed that this change be made in two stages:

Stage 1: Deprecate the use of vulnerable ciphers

This stage proposes immediate deprecation of the vulnerable ciphers by recommending that they SHOULD NOT be supported. This shall leave it to the discretion of the Data Holders how quickly they adopt this recommendation.

Only the following cipher suites SHALL be permitted in accordance with section 8.5 of [FAPI-1.0-Advanced]:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

The following cipher suites SHOULD NOT be supported:

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Stage 2: Adopt BCP 195 rather than explicitly listing required ciphers

This stage changes the supported ciphers section to remove reference to explicit ciphers, and instead, refer to BCP 195. There are some relevant TLS considerations in the FAPI profile, so it is proposed that the standard is changed to clearly adopt section 8.5 of FAPI 1 Advanced, and then further constrain it by only permitting ciphers recommend in the current BCP 195.

In addition to section 8.5 of [FAPI-1.0-Advanced] only cipher suites recommended by [BCP 195] SHALL be permitted.

Whilst TLSECDHE*** cipher suites are recommended by BCP 195, they are not required. Consideration should be given as to whether the recommended ciphers actually be REQUIRED by the Consumer Data Standards.

Alternatively, another solution option is to only implement stage 1 and defer to BCP 195 when the standards are uplifted to FAPI 2.0.

[perlboy]

While perhaps not being perfectly standards compliant we already restrict to the proposed list while implementing the mandatory to implement TLS 1.3 ciphers of RFC8446:

We have not encountered any Recipient access issues with these restrictions in place. I note that cdr.gov.au endpoints appear to also prefer the newer ciphers:

api.cdr.gov.au: New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 secure.api.cdr.gov.au: New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256

All in all, Stage 1 looks like a "no-op" for most.

[CDR-API-Stream]

The stage 1 changes have been staged and can be reviewed here

[nils-work]

This issue will deliver the proposed Stage 1 change in Standards version v1.31.0. Stage 2 (#648 - Adopt BCP 195 for TLS ciphers) may be considered in a future iteration.