1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

Use of TLS 1.2 Ciphers

Issue #685 resolved
Ralph Bragg created an issue

We still have potential interoperability issues with restricting tls cipher lists to this specific subset. FAPI1 recognised this with this language. For the authorization_endpoint, the authorization server MAY allow additional cipher suites that are permitted by the latest version of BCP195, if necessary to allow sufficient interoperability with users' web browsers or are required by local regulations.

I would suggest that ecosystem implementations or vendors with Bank implementations discuss if this is still a concern and or language we need to carry over. If we tighten the cipher suites up to a SHALL use these sub four, i would expect a large number of implementers to fail a conformance and certification test as i understand we can’t put a warning test on a failure to meet a SHALL requirement.

‌

TLS 1.2 permitted cipher suites

For TLS 1.2, only the following cipher suites shall be used:

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Requirements for endpoints used by web browsers

For endpoints that are used by web browsers, the following additional requirements apply:

  1. Servers shall use methods to ensure that connections cannot be downgraded using TLS stripping attacks. A preloaded [@preload] HTTP Strict Transport Security policy [@RFC6797] can be used for this purpose. Some top-level domains, like .bank and .insurance, have set such a policy and therefore protect all second-level domains below them.
  2. When using TLS 1.2, servers shall only use cipher suites allowed in [@!BCP195].

‌

Comments (16)

  1. Tom Jones

    There is a real possibility that these will be deprecated before this year is out.

    This is part of the challenge for standards that attempt to work across levels, that is between the transport and application levels.

  2. Mark Verstege

    From an ecosystem perspective, constraining TLS ciphers on the application layer that would prevent certain cohorts of consumers gaining access to their data and this would be problematic (e.g. screen reader, or other accessibility support). From a backchannel perspective, constraining ciphers would be ok because the end user isn’t interacting with the server. Is there a way to differentiate these two requirements so we aren’t unintentionally excluding consumers who have a disability or have other accessibility concerns?

    I would imagine this would impact many other regulatory ecosystems like Open Banking in the UK, not just Australia. From a regulatory perspective, data sharing in the CDR needs to support such consumers as there provided the person is of legal age and has online access to one or more accounts.

    Having a look at the latest FAPI 2 security profile draft it does state the restriction is for server-to-server communications, so has this been addressed?

    TLS 1.2 permitted cipher suites
    Server-to-server communication endpoints using TLS 1.2 shall only use the following cipher suites:

    • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

    ‌

    For endpoints accessed by web browsers, is the deferral to BCP195 in FAPI 2 Security Profile ok, or is this where the problem lies? BCP195 recommends the use of those four ciphers but does not preclude other ciphers. This would allow OPs to implement other ciphers, however that nuance could easily be lost by implementers (ecosystems and individual OPs alike). Is more guidance around accessibility required in the security profile?

    https://www.rfc-editor.org/rfc/rfc9325.html#section-4.2

    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

    ‌

  6. Joseph Heenan

    I believe the current situation in the certification suite is:

    When making an outgoing call (i.e. from the suite to the AS/RP under test) it will check that the non-accepted ciphers are rejected and will I believe servers that only accept TLS 1.3 will pass.

    For an incoming call (i.e. from the RP/AS under test to the conformance suite) TLS 1.3 is not currently supported due to architectural limitations; we’re working on enabling that: https://gitlab.com/openid/conformance-suite/-/issues/1192

  8. Nat Sakimura

    Atlantic call 2024-05-15

    • Agreement current clause allows for a wider set of cipher suites for endpoints used by web browsers
    • Discussion around some banks supporting legacy ciphers for compliance reasons
    • Restriction are for non-browser endpoints
    • Proposal to add a line to the FAPI 1 vs FAPI 2 differences table to clarify FAPI 2 is more permissive in this area
    • @Ralph Bragg to come up with the text to add to the difference table.

    ‌

  11. Ralph Bragg reporter

    Hi,

    In lite of the above, my previous action point is a little moot. We’re going to have to be more? restrictive or less or do we defer to BCP195 and still carry on with the previous agreed set of actions.

    RB

  12. Brian Campbell

    I think we should get out of the business of naming specific cipher suites. Defer to BCP195. And make some statement/note that acknowledges the potential need for maybe more flexibility at “endpoints used by web browsers” or directly by end users.

    ‌

  17. Log in to comment
Assignee
–
Type
bug
Priority
major
Status
resolved
Component
FAPI2: Security Profile
Milestone
–
Votes
0
Watchers
2
Jira: the preferred issue tracker for Bitbucket. Join the team!