[Openid-specs-fapi] Issue #685: Use of TLS 1.2 Ciphers (openid/fapi)

[Ralph Bragg]

New issue 685: Use of TLS 1.2 Ciphers
https://bitbucket.org/openid/fapi/issues/685/use-of-tls-12-ciphers

Ralph Bragg:

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](https://tools.ietf.org/html/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\].

‌