Hi Alicja,

Except that the precomputation is still more expensive than targetted attack for the same size of parameters.

Yes, but that is also why widespread reuse of the same group matters. For a unique or frequently replaced modulus, expensive modulus-specific precomputation has relatively little opportunity to pay for itself. For a standardized group used by a very large population of servers and implementations, the same precomputation can potentially be amortized over many targets. This is the concern described by the Logjam research. The concrete attacks demonstrated there involved substantially smaller groups, but the underlying property is not specific to 1024-bit DH.

And the arguments you quoted are about 1024 bit DH, not 2048.

The demonstrated attacks were, but the standards arguments are more general:

• RFC 8268 explicitly 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 7919 similarly notes that using the same groups in multiple protocols increases their value to an attacker with sufficient resources to attack a group.

Of course, this does not mean that ffdhe2048 is currently known to be practically breakable. However, I don't think cryptographic design should be based solely on attacks that have already been demonstrated to be practical. Security margins are intended to account for future improvements in cryptanalysis, hardware, and attacker capabilities.

Periodically replacing the public DH group parameters removes the possibility of amortizing modulus-specific precomputation over a long-lived or globally shared group. That is a real hardening property, even if its practical value at 2048 bits is difficult to quantify today.

If static DH parameters were such a big issue we wouldn't have them as the _only_ option in TLS 1.3.

Agreed, for finite-field DHE. RFC 7919 groups are an entirely legitimate way to implement FFDHE, and TLS 1.3 demonstrates that this tradeoff is considered acceptable. The per-connection DH key shares are still ephemeral, while the public group parameters are fixed. I don't think that implies, however, that periodically replacing those public group parameters provides no additional protection. RFC 7919 represents a reasonable standardized security/performance tradeoff; it is not necessarily the strongest hardening an implementation can reasonably provide.

More importantly, I think this discussion is drifting away from the original problem. I don't consider finite-field DHE a desirable default for stunnel in 2026. The expensive DH parameter generation became noticeable because Fedora/RHEL changed the cipher-suite configuration and enabled DHE cipher suites that upstream stunnel would otherwise have little reason to use. Given that, I would prefer not to change upstream stunnel further merely to reduce the cost introduced by that downstream configuration.

If DHE is explicitly enabled, stunnel's periodically regenerated group parameters are an intentional additional hardening measure. Upstream stunnel is not required to limit its security measures to the defaults chosen by OpenSSL or by a distribution, particularly when the additional protection addresses a known cryptographic property. There is therefore no claim that RFC 7919 groups are insecure. They are standardized and considered secure. I simply don't see a compelling reason to remove an existing upstream hardening measure in order to optimize a cipher-suite configuration that I would not recommend in the first place.

Best regards,
    Mike