ANSWERED Which TLS cipher suite should be used ?

[iampd 6]

Hi, I am not sure if this has been discussed before or if this is the right forum to post it. Kindly correct if there's any issue.

While connecting to AirVPN through openvpn client using .opvn configs, the control channel always shows TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 as the cipher suite in the logs throughout all the servers/countries.

Since openvpn supports both: TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384; TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 of these ciphers suites, why aren't they the default encryption suites for the connection?

   ECDHE    and   ECDSA   provide  better security than   DHE   and  RSA , respect ively. ECDSA  clear  ly has an advantage of providing similar security over much smaller key space than  RSA , although ECC verifying takes a bit more time. Is the overhead time a concern to not switch to these  cipher suites, or is there any other reason ? Please explain.

Thank you.

 

[Staff 10119]

 Hello!

 

Since openvpn supports both: TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384; TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 of these ciphers suites, why aren't they the default encryption suites for the connection?

 

For a precise choice we explained several times in the past. Feel free to search the forum.

 

ECDHE    and   ECDSA   provide  better security than   DHE   and  RSA , respect ively.

 

This is questionable, especially since you don't specify parameters. In 2007 Schneier expressed some doubts about NSA backdoors in ECC, and we have always followed a vary conservative approach against NIST-recommended ECs.

 

Later in 2013 the documents revealed by Snowden showed that backdoors were indeed implemented by NSA in the ellyptic curve bit generator Dual_EC_DRBG, and that a vast program to implement backdoors on various ciphers and have those very ciphers approved as standards was active in NSA.  Therefore facts proved that we were right, and any conservative approach is not a bad thing.

 

See also... the suspicions:

https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters

https://www.wired.com/2007/11/securitymatters-1115/

 

and the first paramount revelation:

https://en.wikipedia.org/wiki/Dual_EC_DRBG

 

About your last question on overhead time, this becomes very relevant in packets verification. Currently there is no reason to add a significant computational burden (which would be relevant on the server side as well) on the Data Channel by shifting from HMAC SHA1 to, for example, HMAC SHA384, even if OpenVPN supported it on the Data Channel (and it doesn't).

 

Kind regards

[iampd 6]

Thank you for your prompt reply. I'll look more into it.

Regards