V6 Cryptography - Perfect Forward Secrecy

[danielcuthbert]

Scheme	Domain Parameters
RSA	k >= 2048
Diffie-Hellman (DH)	(L, N) parameters: L >= 2048 & N >= 224
Elliptic Curve Diffie-Hellman (ECDH)	f >= 224

[danielcuthbert]

An interesting comment, thank you. Firstly I guess we need context here. Both RSA and DHE do support PFS and we need transient key pairs (temp keys) in order to encrypt $stuff$ for that conversation.

We have specified that both RSA and DHE need k >= 2048, which is the minimum amount required to suppport PFS (same goes for DH). So yes, they do support it in the above

However, there is a computational impact say on TLS of using PFS, and there is the issue of backwards compatability with older clients.

Im closing this for now but by all means open a new issue if this isn't clear

[randomstuff]

We have specified that both RSA and DHE need k >= 2048, which is the minimum amount required to suppport PFS (same goes for DH). So yes, they do support it in the above

I believe we are talking about the RSA transport scheme here (i.e. sending a shared secret to the peer encrypted using the peer's RSA public key) which do not provide forward secrecy with respect to the peer's RSA private key, right?

[unprovable]

It's really unclear which kind of forward secrecy you're referring to. PFS uses negotiated long term keys followed by per-message session keys derived sequentially from messages that have been sent so far (hence the 'forward secrecy' name). This makes sense when you talk about TLS or Signal protocol, but not generally for KEX. If you can elaborate your argument, @randomstuff, this would make it easier to answer. M.

[randomstuff]

AFAIU, forward secrecy means that if the long term secrets used in the key exchange protocol are disclosed, previous sessions are not compromised (previous session/transient keys cannot be recovered).

I understand that the RSA KEX discussed here is the "RSA transport" scheme where peer A uses RSA to send an some encrypted session key material to the peer B (using peer B's public key). Is this what we are talking about here?

If this is what we are talking about, do we agree that this scheme does not provide forward secrecy (because if B's public key is disclosed the session key material can be decrypted)? If so, are there any reasons for recommending it (outside of compatibility)?

[unprovable]

Can you do me a favour and name a scheme that does support PFS so I can better understand where you are coming from? Many thanks! M

…

On Mon, 11 Nov 2024, 16:15 Gabriel Corona, ***@***.***> wrote: AFAIU, forward secrecy means that if the long term secrets used in the key exchange protocol are disclosed, previous sessions are not compromised (previous session/transient keys cannot be recovered). I understand that the RSA KEX discussed here is the "RSA transport" scheme where peer A uses RSA to send an some encrypted session key material to the peer B (using peer B's public key). Is this what we are talking about here? If this is what we are talking about, do we agree that this scheme does not provide forward secrecy (because if B's public key is disclosed the session key material can be decrypted)? If so, are there any reasons for recommending it (outside of compatibility)? — Reply to this email directly, view it on GitHub <#2252 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADHBXOXY5GS5YDENPNAR6432ADJ2ZAVCNFSM6AAAAABRGXH62OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRYGU2DIOBQGE> . You are receiving this because you commented.Message ID: ***@***.***>

[randomstuff]

Ephemeral Diffie-Hellman?

[unprovable]

Ah so you are referring to TLS ciphersuites. Theoretically, you can do PFS with RSA, it just isn't done because it is very computationally expensive. It is restricted from TLS for this reason. This looks like you think we should put some ideal TLS advice in the appendix. If so, we have a whole load of work we have already done that we can utilise, along with notes for common pitfalls (such as Mozilla always ordering AES128 even in TLSv1.3 ciphersuites, etc.). Let me know if this would be useful. :) M.

…

On Mon, 11 Nov 2024, 18:25 Gabriel Corona, ***@***.***> wrote: Ephemeral Diffie-Hellman? — Reply to this email directly, view it on GitHub <#2252 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADHBXOV5RNPXQ3NPKTZYRKD2ADZBTAVCNFSM6AAAAABRGXH62OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRYG44DONBSGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[randomstuff]

I did not intent my question to be about TLS ciphersuites.

I agree that you can build some key exchange scheme on top of RSA which features forward secrecy. From a theoretical standpoint, my argument is therefore moot. However, is such a scheme ever used anywhere in practice?

In practice, with the text as it is, isn't there t a risk that we may encourage using a non-forward-secure scheme where a we send a session secret encrypted with a static RSA key?

[unprovable]

"Key Exchange" is not synonymous with "uses PFS". As I mentioned, there are protocols that use it, but it is a recommendation to use PFS where it is an optional feature, rather than a requirement to be placed on KEX. I suggest we put it there. M.

…

On Mon, 11 Nov 2024, 19:28 Gabriel Corona, ***@***.***> wrote: I did not intent my question to be about TLS ciphersuites. I agree that you can build some key exchange scheme on top of RSA which features forward secrecy. From a theoretical standpoint, my argument is therefore moot. However, is such a scheme ever used anywhere in practice? In practice, with the text as it is, isn't there t a risk that we may encourage using a non-forward-secure scheme where a we send a session secret encrypted with a static RSA key? — Reply to this email directly, view it on GitHub <#2252 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADHBXOXG5S7OGG3C2VBP5UL2AEAPVAVCNFSM6AAAAABRGXH62OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRYHA4DGNJTGM> . You are receiving this because you commented.Message ID: ***@***.***>

[tghosth]

@randomstuff is there any further action here?

[randomstuff]

We can close this as duplicate of #2215.