From b481f074fd13cfa71b8eb242bb359fe49111944f Mon Sep 17 00:00:00 2001 From: aussieklutz Date: Tue, 9 Jun 2020 12:04:10 +1000 Subject: [PATCH] Reference RFC7919 for choosing DHE Group Param --- docs/SSL_TLS_Deployment_Best_Practices.xml | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/docs/SSL_TLS_Deployment_Best_Practices.xml b/docs/SSL_TLS_Deployment_Best_Practices.xml index 19140c5..d3e81dc 100644 --- a/docs/SSL_TLS_Deployment_Best_Practices.xml +++ b/docs/SSL_TLS_Deployment_Best_Practices.xml @@ -341,10 +341,18 @@ EDH-RSA-DES-CBC3-SHA The researchers discovered that lower-strength DH key exchanges (e.g., 768 bits) can easily be broken and that some well-known 1,024-bit DH groups can be broken by state agencies. To be on the safe side, if deploying DHE, configure it - with at least 2,048 bits of security. Some older clients (e.g., Java 6) might not - support this level of strength. For performance reasons, most servers should prefer - ECDHE, which is both stronger and faster. The secp256r1 named - curve (also known as P-256) is a good choice in this case. + with at least 2,048 bits of security. Ideally, using one of the DH groups specified + in RFC7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for + Transport Layer Security (TLS) + + RFC7919: Negotiated + Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer + Security (TLS) (retrieved 9 June 2020) + + Some older clients (e.g., Java 6) might not support this level of strength. For + performance reasons, most servers should prefer ECDHE, which is both stronger and + faster. The secp256r1 named curve (also known as P-256) + is a good choice in this case.
2.7 Mitigate Known Problems