On 8/31/26 16:45, Clemens Lang wrote:
Ah, that’s a lot easier to change for me. I’ve filedhttps://bugzilla.redhat.com/show_bug.cgi?id=2526328 to track this in Fedora.
Using the RFC 7919 groups would certainly avoid the CPU cost of generating fresh DH parameters, but there is a security tradeoff. Finite-field DH permits substantial discrete-logarithm precomputation that depends only on the group modulus. Once that precomputation has been performed for a particular group, it can be reused against subsequent DH exchanges using the same group. This was demonstrated by the Logjam research: David Adrian et al., "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice", CCS 2015. The concern is also explicitly recognized by IETF standards. RFC 8268 states: "Using a fixed set of Diffie-Hellman parameters makes them a high value target for pre-computation. Generating additional sets of primes to be used, or moving to larger values mitigates this issue." RFC 4419 gives essentially the same rationale for allowing SSH servers to generate new DH groups, specifically citing the risk of extensive precomputation against fixed groups. RFC 7919 itself also acknowledges the issue in Section 8.5, noting that "Using the same groups in multiple protocols increases the value for an attacker with the resources to crack any single group." Therefore, replacing stunnel's periodically generated parameters with a globally shared RFC 7919 group would not be security-neutral. With sufficiently large groups, particularly ffdhe3072 and above, the precomputation attack is believed to be impractical, so RFC 7919 makes a reasonable engineering tradeoff. Nevertheless, periodically generating unique DH parameters does provide additional protection against this class of attack. Best regards, Mike