V6 - Discuss forward secrecy

[randomstuff]

Some requirement(s) should require the usage of forward secrecy whenever it makes sense.

see #2212 (comment)

Possible impact:

• Key exchange (ephemeral DH vs. RSA and static DH)
• mTLS client authentication using static client DH keypair (is it still relevant?)
• TLS session resumption (with TLS before 1.3)

[danielcuthbert]

I did address this with #2252

Do you think we need to clarify further @randomstuff

[randomstuff]

Both RSA and DHE do support PFS

Can you clarify (or provide reference) when you say that RSA supports PFS? Maybe we are not talking about the same thing?

[randomstuff]

My point is that we should have explicit requirements about forward secrecy which is currently not mentioned explicitly at all.

Proposed generic requirement:

9.2.X Verify than for all communications using an encrypted protocols (TLS, SSH) the communication provides forward secrecy with respect to the long term private keys when communicating with modern clients. Non-forward secret communication might still be supported only for compatibility with old client which do not support it and if such compatibility is required.

This generic requirement could be specialized into more specific requirement about TLS (?). Proposed requirement about forward secrecy with respect to the client private key

9.4.X Verify than for all communications using TLS provides forward secrecy with respect to server private key when communicating with modern clients. Key exchanges such as RSA transport, static diffie-hellman, static ECDH key exchanges must not be used for when communicating with modern clients.

Some questions/comments:

• Is 9.4.X redundant with existing requirement such as 9.4.1? ("latest recommended cipher suites")
• I would consider a requirement about forward secrecy with respect to the client private key in TLS (i.e. rsa_fixed_dh, dss_fixed_dh). I don't know if this has been used in practice and I don't believe this has been used much anyway.
• I'm not including requirements about forward secrecy with TLS PSK as this is quite niche (outside of TLS 1.3 session resumption).
• Before TLS 1.3 and when using TLS 1.3 with psk_ke, there is no forward secrecy with respect to the session secret. This might need to be mitigated. More generally, there are considerations wrt TLS sessions secrets which might need to be included.

[ImanSharaf]

Should we enforce the use of ephemeral key exchange methods, such as ephemeral Diffie-Hellman (DHE) or Elliptic Curve Diffie-Hellman (ECDHE)?
It can ensure that session keys are unique per session, preserving forward secrecy. In contrast, static key exchanges, like RSA or static Diffie-Hellman, do not provide forward secrecy and are therefore less secure.

[randomstuff]

@ImanSharaf, I think the requirement should focus on the goal which is to provide forward secrecy. In practice, this is typically achieved using DHE but could be achieved using other schemes (triple diffie hellman, some RSA based schemes, etc.).

[randomstuff]

See #2252