- edited description
FAPI2-Baseline - has the time come to recommend/require TLS 1.3?
The current TLS restrictions in https://openid.net/specs/fapi-2_0-baseline-ID1.html#name-network-layer-protections are a little weaker than FAPI1-Adv, in particular FAPI2-Baseline allows the user of various ciphers known to be insecure.
We could make this much easier (and arguably, considerably more secure in the face of both correct and incorrect configuration given the many security improvements in TLS1.3) by just requiring the use of TLS 1.3. However I’m not sure we’re quite at that point yet?
It feels like TLS 1.3 support should at least be a ‘should’. And we should probably add that language from FAPI1-Adv that reduces the ciphers that can be used in TLS 1.2.
For browser support, see: https://caniuse.com/tls1-3
It seems TLS 1.3 support is relatively recent in Windows: https://docs.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-
And it seems like Azure may not support TLS 1.3 as of today, and I couldn’t find anything saying if they have a plan to enable it: https://stackoverflow.com/questions/61927225/is-tls-1-3-available-on-azure-app-services/61927285#61927285
I didn’t do an exhaustive search but it seems like the other major cloud providers generally support TLS 1.3, although support for it in some AWS services was only enabled in the last few months: https://aws.amazon.com/about-aws/whats-new/2021/10/aws-network-load-balancer-supports-tls-1-3/
Comments (13)
-
reporter -
reporter - edited description
-
reporter - edited description
-
reporter https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final says “requires that TLS 1.2 configured with FIPS-based cipher suites be supported by all government TLS servers and clients and requires support for TLS 1.3 by January 1, 2024. “ (thanks to Craig Borysowich for the link)
-
- changed status to open
Recommending seems to be sensible. Requiring support may be ok. Requiring only using 1.3 may be premature.
-
Requiring only 1.3 (i.e. disallowing negotiation of 1.2) is definitely premature.
-
reporter Discussed again on today’s call.
We want to continue to allow authorization servers to support TLS 1.2 if they need to / are not able to support TLS 1.3 for technical reasons, but on the call there seems to be a consensus that FAPI2 should say things “should” (i.e. are recommended to) support TLS 1.3.
We need to make sure that FAPI2 isn’t less secure than FAPI1, so may need to strengthen the wording on FAPI2 to either say something like ‘the ‘should’s in the TLS BCP must be treated as 'musts’” and/or include the recommended cipher list as a MUST as FAPI1 does.
There was some further discussion about whether the FAPI1 requirements would require the support of ciphers that aren’t allowed in Russia or in PCI DSS compliant environments, without a clear conclusion.
-
Rework the TLS section re issue 461
→ <<cset 5cce221bf9b0>>
-
-
reporter As another possible alternative to BCP195 there’s this document:
https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF
I have no idea how they compare, but this is at least much more recent than the TLS 1.2 BCP.
-
Merged in tls-fapi2 (pull request #307)
Rework the TLS section re issue 461
Approved-by: Joseph Heenan
→ <<cset fc104a52d74b>>
-
- changed status to resolved
PR merged
-
- changed component to FAPI2: Security Profile
- Log in to comment