Adopt BCP 195 for TLS ciphers

[nils-work]

Description

Consider the change proposed as Stage 2 in #643 - Update TLS cipher suite requirements to address DHEat Attacks and Raccoon Attack vulnerabilities

Intention and Value of Change

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

Area Affected

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

Change Proposed

(Stage 2 from #643 - Update TLS cipher suite requirements to address DHEat Attacks and Raccoon Attack vulnerabilities):

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.

DSB Proposed Solution

The current DSB proposal for this issue is in https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/648#issuecomment-2257415305

[nils-work]

Participants are advised to verify their implementation against the recent Standards change:

The following cipher suites SHOULD NOT be supported: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

and the additional proposal in this issue, to ensure any concerns can be considered during Maintenance Iteration 20.

[markverstege]

The FAPI WG now has proposed wording for both FAPI 2.0 and FAPI-CIBA, but not yet FAPI 1.0 Advanced.

Note BCP195 link: https://www.rfc-editor.org/info/bcp195

FAPI 2.0 wording:

shall follow the recommendations for Secure Use of Transport Layer Security in [@!BCP195];

This change is accompanied by additional requirements the FAPI 2.0 Security Profile introduces for TLS which are not present in FAPI 1.0 Advanced.

FAPI-CIBA wording:

Only the cipher suites recommended in [@!BCP195] shall be permitted.

This change is closely aligned to the original wording in FAPI 1.0 Advanced and alters the constrained list of TLS 1.2 ciphers to instead adopt BCP195. As a result, it is proposed that this wording be adopted. Once FAPI 2.0 is adopted by the Consumer Data Standards, the Security Profile can simply defer to the FAPI 2.0 Security Profile for TLS.

Therefore, there is a small change to the original proposal altering "by" to be "in":

Proposed solution

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

[markverstege]

Further to the change being proposed above, it is proposed that a 6 month FDO be assigned for ADRs and DHs. Based on the ⁠Obligation Date Schedule, this would set an FDO of 17 March 2025 (Y25 #1). Whilst there has not been any feedback that this would constitute a breaking change for implementations, setting an FDO would ensure participants would have sufficient time to assess impact and make necessary changes if applicable.

[nils-work]

Incorporated into Standards v1.32.0.