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

[tghosth]

@randomstuff what are the next steps on this issue?

[randomstuff]

Proposition:

9.2.X Verify that communications using in-transit encryption (for example using TLS, SSH, IPsec, QUIC), the encryption protocol provides forward secrecy. This can be achieved using an ephemeral Diffie-Hellman key exchange.

Somewhat more verbose (but possibly more precise) wording:

9.2.X Verify than for all communications using in-transit encryption (for example using TLS, SSH, IPsec, QUIC), the communication cannot be decrypted with any persistent secret (forward secrecy). This can be achieved using an ephemeral Diffie-Hellman key exchange.

Question: Any need for an exception for compatibility with old legacy external clients? ("[…] when communicating with up-to date clients […] Communication with external legacy clients which do not support forward secrecy can be used if such compatibility is required.")

Question: Add some hints about suitable TLS ciphersuites in appendix?

Question: Do we need to discuss about the impact of session resumption with respect to forward secrecy?

[tghosth]

My questions:

• Does offering TLS 1.3 mean that an app automatically complies with this requirement?
• If not, can the dev choose specific cipher suites to comply with this requirement?
• If not, what do they need to do?
• What does someone need to do if they also offer TLS 1.2?

Question: Add some hints about suitable TLS ciphersuites in appendix?

Open to suggestions but that would be a separate issue on the appendix. I don't think it is critical.

Question: Do we need to discuss about the impact of session resumption with respect to forward secrecy?

Does it alter the requirement?

[tghosth]

@randomstuff

[randomstuff]

Question: Do we need to discuss about the impact of session resumption with respect to forward secrecy?

Does it alter the requirement?

Short answer: It's complicated. I'd say we can include the requirement as is. Id needed, we can talk about session resumption in another issue.

Long answer below:

Possibly, somewhat.

Explanation: The secrets stored by the TLS server for session resumption can typically be used to break the encryption of the resumed TLS session. If these are persisted (and replicated in order to allow the session to work on different instances of the TLS termination server), this may compromise forward secrecy.

See for reference : https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/

Note: This is fixed in TLS 1.3 when if a Diffie-Hellman key exchange is done as part of the session resumption (psk_dhe_ke).

So for this proposed requirement:

9.2.X Verify than for all communications using in-transit encryption (for example using TLS, SSH, IPsec, QUIC), the communication cannot be decrypted with any persistent secret (forward secrecy). This can be achieved using an ephemeral Diffie-Hellman key exchange.

could be interpreted as implying that session secrets must be not persisted.

[tghosth]

Ok so how about my other questions @randomstuff :

• Does offering TLS 1.3 mean that an app automatically complies with this requirement?
• If not, can the dev choose specific cipher suites to comply with this requirement?
• If not, what do they need to do?
• What does someone need to do if they also offer TLS 1.2?

[randomstuff]

Summary of forward secrecy support depending on TLS versions and ciphersuites:

	TLS	Ciphersuites	Forward secrecy?
A	1.3	-	yes
B	1.2	TLS_DHE_*, TLS_ECDHE_*	yes
C	1.2	TLS_RSA_*, TLS_DH_*, TLS_ECDH_*	no

(Assuming the DH contributions are really ephemeral. And if we skip the question of session resumption. If we skip the exotic ciphersuites such as PSK, etc.)

We have two options for this proposed requirement:

1. the current proposed requirement says "always use forward secrecy";
2. another option would be "use forward secrecy with compatible clients (but keep less secure option for compatibility with old external legacy clients)"

Option 1: always use forward secrecy → This mean you would have to disable the ciphersuites in (C).

Option 2: support forward secrecy → this means that at least (B) must be supported. This should work out of the box on modern systems unless:

• you use a manual and broken ciphersuite configuration (which only enables old ciphersuites);
• or, I think, if you use a RSA certificate without digitalSignature key usage (but I don't believe this should happen).

[randomstuff]

Mozilla SSL server configuration has three modes:

• modern → TLS 1.3 only, forward secret only
• intermediate → intermediate → support for TLS 1.2 with DHE and ECDHE only (foward secret ciphersuites only)
• old ("Compatible with a number of very old clients, and should be used only as a last resort") → enables legacy ciphersuite which don't support forward secrecy.

So the question is. Can we require the usage of an "intermediate or higher" level (→ option 1)?

If I look at several servers:

• https://www.google.com still allows legacy ciphersuites
• https://github.com still allows legacy ciphersuites
• Two bank websites → forward secrecy only
• All apps I have configured recently follow the intermediate configuration and therefore only support forward secrecy. I have not had any recent complaints/brokeness about this.
• My ISP → forward secrecy only
• Wikiepdia → forward secrecy only

[tghosth]

So I would suggest the following:

9.4.1
[MODIFIED, MOVED FROM 9.1.2] Verify that only the latest recommended cipher suites are enabled, with the strongest cipher suites set as preferred. For L3 applications, only cipher suites which support forward secrecy should supported.

what do you think @randomstuff

[randomstuff]

[MODIFIED, MOVED FROM 9.1.2] Verify that only the latest recommended cipher suites are enabled, with the strongest cipher suites set as preferred.

"latest recommended cipher suites are enabled" is somewhat vague but maybe that's the point.

Moreover, this wording seems to be (implicitly) about TLS ("ciphersuites") but we might want it to apply to other protocols as well.

For L3 applications, only cipher suites which support forward secrecy should supported.

Is the "should" instead of "must" intentional here? Not that I am against saying "should" here.

I'd want to focus more on forward-secrecy as an explicit goal.

[tghosth]

"latest recommended cipher suites are enabled" is somewhat vague but maybe that's the point.

Yes as this guidance changes.

Moreover, this wording seems to be (implicitly) about TLS ("ciphersuites") but we might want it to apply to other protocols as well.

Seems like TLS is probably the vast majority of cases so I prefer to include it there.

Is the "should" instead of "must" intentional here? Not that I am against saying "should" here.

Agree it should be a little clearer:

9.4.1
[MODIFIED, MOVED FROM 9.1.2] Verify that only the latest recommended cipher suites are enabled, with the strongest cipher suites set as preferred. L3 applications must only support cipher suites which provide forward secrecy.

[randomstuff]

Seems like TLS is probably the vast majority of cases so I prefer to include it there.

Wouldn't it make sense to have (also) general requirement about this?

[randomstuff]

(musing)

The forward secrecy requirement could apply to these web-compatible flows as well (which are not completely niche):

• WebRTC /AV streams (which use SRTP)
• WebRTC data streams (which use DTLS)

More generally some of the transport security requirements might apply to WebRTC. There is not so much we can do about for browser-to-browser communications but for browser-to-server WebRTC, it might be relevant.

(If this does make sense, this should belong to the WeRTC appendix, though.)

[tghosth]

Wouldn't it make sense to have (also) general requirement about this?

In theory but I see the other examples as a lot more niche and I'd rather focus on the main relevant example.

For WebRTC, we have a guy who did those requirements so maybe open a separate issue and I will ping him :)

[tghosth]

opened #2439 to resolve