[TLS] Short Ephermal Diffie-Hellman keys
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[TLS] Short Ephermal Diffie-Hellman keys




Hello all,

I have recently started to see an increasing number of reports about SSL/TLS servers using short Ephermal Diffie-Hellman keys, in some cases very short ones.

Opera's SSL/TLS client will display warnings to users if the server is using RSA/DH/DSA keys shorter than (currently) 900 bits. All keys used in the chain, including the CA certificates are included in this evaluation, as well as the ephermal key, if the server selects a cipher with an ephermal key.

The short DHE keys I have seen have usually been 512 bits, but I have seen servers sending keys as short as 256 bits.

I have seen these keys on both normal webservers and mail servers, but I have an impression that there are more reports about the mail servers.

I think it might be an idea for TLS specification to include recommendations about how such keys should be selected.

My preference for such a recommendation is that the ephermal key should be as long, or as strong, as the key used to sign the ephermal key. I don't think the specification should mention specific keylengths, because what is secure is likely to change over time.

Comments?

As far as Opera is concerned, I am considering a few options, including automatically disabling the ephermal ciphersuites or re-sorting the cipher suite list toplace them last, and renegotiate the connection.

--
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: yngve at opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.