On Mon, Jan 02, 2023 at 06:32:26PM +0200, Nimrod Aviram wrote: > (To concede a point in advance: It is obviously possible to _assume_ that > if the server presents a modulus, then it "must" be a safe prime, or it > meets some desired security notion that the server operator has deemed > sufficient for the connection.
The server's choice of FFDHE groups is signed with the server's private key (matching the public key in its certificate). If that server is so poorly operated as to sign a weak FFDHE group, why would one expect its ECDHE private key to be strong (https://dilbert.com/strip/2001-10-25)? What's the actual threat model here? Sure server operators SHOULD NOT configure weak FFDHE groups (export-grade, small subgroups, ...), but if they do (despite all advice to the contrary, and much effort in various tools and libraries to ensure safe defaults), then that's the best security you can expect if you want to connect to *that* server. My take remains that progress would be to make ECDHE MTI for TLS 1.2 (if not already) and mandatory to choose over FFDHE when supported at both ends. This entirely achieves all the benefits of the proposed deprecation, without causing needless auditor grief for FFDHE-only deployments, knee-jerk switches to RSA key exchange, ... It would also be helpful if at least one widely-available browser left FFDHE support available (if not by default, then with a runtime config setting) so that legacy servers with perfectly good safe DH parameters remain reachable. -- Viktor. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
