On 06/11/2019 11:43, Jan Just Keijser wrote: > Hi David, > > I am not entire sure I agree 100% with you ;) > See my comments below. > > On 05/11/19 23:23, David Sommerseth wrote: >> On 05/11/2019 11:09, Thomas Luening wrote: >>> Hello >>> >>> I hope you can help me with the answers for 2 theoretical questions. When I >>> open a new OpenVPN session, an asymmetric RSA encryption is used to >>> determine >>> a symmetric session key, e.g. for AES. The subsequent session is then >>> encrypted with AES and the found symmetric key. >> In OpenVPN terminology, the asymmetrical key is used in the OpenVPN Control >> Channel communication, while the symmetric session key is used in the OpenVPN >> Data Channel. >> >> The Control Channel is essentially where authentication, options pushed by >> server, peer information, etc is sent, while the Data Channel is the tunneled >> network traffic being sent or received to/from the remote side. >>> 1. Does the choice of RSA2048 or RSA8192 affect the length or strength of >>> the >>> new symmetric session-key? >> No. There is no direct relation between key sizes in the control or data >> channel, the crypto parameters there are handled/configured separately. >> >> The strength of the control channel is controlled via the >> --tls-cipher/--tls-ciphersuites options (but the default values here should >> be >> more than strong enough for the vast majority of OpenVPN users). There is >> also --tls-cert-profile which can be used to further restrict what kind of >> cryptographic algorithms being allowed for the control channel. >> >> The data channel strength is managed using the --cipher option (as well as >> the >> deprecated --keysize option, for ciphers not indicating the key size in the >> cipher suite - such as the not recommended Blowfish cipher). >> >>> 2. Or does the choice of RSA2048 or RSA8192 only affect the security of >>> communication in the symmetrical key finding process? >> No, as mentioned above, the data channel cipher settings is handled >> independently of the control channel. With OpenVPN 2.4 the Negotiable Crypto >> Parameters (NCP) feature was added, which allows some kind of negotiation - >> even though it is not a particularly intelligent negotiation. See the >> --ncp-ciphers option in the man page for details. >> >> The default behavior when using OpenVPN 2.4 clients or OpenVPN 3 based >> clients >> (OpenVPN Connect, OpenVPN for Android with OpenVPN 3 backend enabled or >> OpenVPN 3 Linux), is to upgrade to AES-256-GCM if this has not been >> configured >> with --cipher already. > > For the datachannel, OpenVPN derives the session keys from the TLS keying > material (see ssl.c, 'tls_session_generate_data_channel_keys') ; this keying > material is based on the current TLS session and then ephemeral keys are > calculcated from that, using the (TLSv1-based) MD5 + SHA1 routines (see > openvpn_PRF).
That's right. > Thus, there *is* a minor link between the RSA key strength and the datachannel > keys, if I understand the crypto correctly. Yes, it is somewhat a link in this regards. The crypto parameters (cipher, key length, authentication) used in the data channel are not directly related to the crypto parameters used in the control channel. While the data channel key is derived from the ephemeral TLS session key, thus not being the same key as the one used in control channel. So with a weaker RSA key, the TLS negotiation for the control channel is weaker. But the length of the asymmetrical keys doesn't really affect the key size directly used for the symmetric part of the further TLS operations. If the negotiated TLS channel uses ECDHE-RSA-AES256-GCM-SHA384, the ephemeral session key will still be 256 bits, regardless if the RSA key is 2048 or 8192 bits. Now, if the negotiated channel uses a 128 bits key (like ECDHE-RSA-AES128-GCM-SHA384), the keying material for the data channel will have less "entropy" for the PRF operations. But the resulting key will still be the key size defined by the cipher (or --keysize). But again, this is not directly related to the key size of the asymmetric RSA keys. So yes, there is somewhat a link ... but I'm not sure how much impact that has in reality to strength of the data channel key. Or did I miss something? > Having said that, I think it will be worthwhile to upgrade the data channel > key generation to use the TLSv1.2+ "export_keying_material" routines, which > will require a new flag for backward compatibility. This would also make it > much easier to do FIPS validation for OpenVPN again. We discussed last year at the hackathon a possibility to add a kind of plugin interface to exchange the PRF with something else. Another option would be to have a new --prf option to be able to switch to a stronger PRF function. But if we can't easily swap out the PRF function unless both sides does the same, otherwise the data channel key will be different on each side of the tunnel - which won't work well with symmetric encryption. -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
