Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adopt BCP 195 for TLS ciphers #648

Closed
nils-work opened this issue Jul 1, 2024 · 4 comments
Closed

Adopt BCP 195 for TLS ciphers #648

nils-work opened this issue Jul 1, 2024 · 4 comments
Labels
Breaking change A change expected to result in a new endpoint version. Proposal made The DSB has proposed a specific change to the standards to address the change request Security Change or question related to the information security profile
Milestone

Comments

@nils-work
Copy link
Member

nils-work commented Jul 1, 2024

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 TLS_ECDHE_*** 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 #648 (comment)

@nils-work
Copy link
Member Author

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
Copy link
Member

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 markverstege added the Proposal made The DSB has proposed a specific change to the standards to address the change request label Jul 30, 2024
@markverstege markverstege moved this from Iteration Candidates to In Progress: Design in Data Standards Maintenance Jul 30, 2024
@nils-work nils-work added this to the v1.32.0 milestone Sep 2, 2024
@markverstege
Copy link
Member

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 nils-work added the Breaking change A change expected to result in a new endpoint version. label Sep 18, 2024
nils-work added a commit to ConsumerDataStandardsAustralia/standards that referenced this issue Oct 21, 2024
* Created 1.32.0 branch base

* Updated to newer openapi-generator-cli

Added new jar and removed older jars

* Merged the Change Log and Archives sections

Addresses: ConsumerDataStandardsAustralia/standards-staging#413

* Retaining original anchors

* Fixed spelling mistake for authorization_code reference. Addresses issue comment ConsumerDataStandardsAustralia/standards-maintenance#647 (comment)

* Removed redundant statement regarding client ID. Addresses issue ConsumerDataStandardsAustralia/standards-maintenance#647 (comment)

* Corrected field description for tariffUType. Addresses issue ConsumerDataStandardsAustralia/standards-maintenance#647 (comment)

* Updated URIString example to use HTTPS scheme rather than HTTP. Addresses issue ConsumerDataStandardsAustralia/standards-maintenance#647 (comment)

* Update details in Common Field Types section

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#641

* Clarified the format of adjustment rate values

Addresses: ConsumerDataStandardsAustralia/standards-maintenance#641

* Fixed typos

Addresses: ConsumerDataStandardsAustralia/standards-staging#411

* Endpoint as one word

Addresses: ConsumerDataStandardsAustralia/standards-staging#411 (comment) and ConsumerDataStandardsAustralia/standards-maintenance#527 (comment)

* Corrected required properties

Addresses: ConsumerDataStandardsAustralia/standards-staging#417

* Add version delta comment and removed line breaks

* #418 - Add CX guidelines link to footer

Addresses: ConsumerDataStandardsAustralia/standards-staging#418

* Update Common and Admin APIs descriptions

* Staging #419 - Update field name styling

Addresses: ConsumerDataStandardsAustralia/standards-staging#419

* Update description of Product Categories section

Addresses: ConsumerDataStandardsAustralia/standards-staging#411 (comment)

* Staging #426 - Corrected OAS, moved files

Addresses: ConsumerDataStandardsAustralia/standards-staging#426

* Fixed typos

* Standards Maintenance Issue #652: Updated description of AmountString field clarifying the currency format and noting it defaults to AUD

* adding 'and'

for one hundred 'and' twenty-three dollars

* Minor update to styling and wording

* Fix link for local build testing

* Added x-version-notes and x-diff custom extension keys. x-version-notes allows capturing API version notes. x-diff allows capturing diff statements against specific API or schemas

* Standards Maintenance Issue #653: Amended description of dailySupplyChargeType field

* Standards Maintenance Issue #653: Fixed incorrect diff statement

* Staging #438 - Improve code samples

Addresses: ConsumerDataStandardsAustralia/standards-staging#438

* Version delta and release notes

* Staging #437 - Remove Known Issues

Addresses: ConsumerDataStandardsAustralia/standards-staging#437

* Corrected error title

Addresses: ConsumerDataStandardsAustralia/standards-staging#411 (comment)

* Update _errors.md

* Corrected quotes in JSON samples

* Added Register Base URLs to spec

* Updated links

* Added TLS changes to align with BCP 195 and FAPI 2.0. Addresses issue: ConsumerDataStandardsAustralia/standards-maintenance#648

* Removed x-diff custom key from json swagger. Moved diff statement into energy erb file

* BCP195 as one word, bolded key words

* Update "account id" to "accountId"

* Removed bold styling

* Update to validation version only

Clearly distinguishing the specific JAR versions used in each step of the build process and updated to the newer JAR for validation only.

* Reverted non-RateString changes

* Updated notes

* Update issue title

* Resolve release notes and change log

* 1.32.0 build for Staging

* Build 1.32.0

---------

Co-authored-by: Mark Verstege <[email protected]>
Co-authored-by: Hemang Rathod <[email protected]>
@nils-work
Copy link
Member Author

Incorporated into Standards v1.32.0.

@github-project-automation github-project-automation bot moved this from Awaiting Chair Approval to Done in Data Standards Maintenance Oct 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking change A change expected to result in a new endpoint version. Proposal made The DSB has proposed a specific change to the standards to address the change request Security Change or question related to the information security profile
Projects
Status: Done
Development

No branches or pull requests

2 participants