Is there benefit in stating that the server SHOULD choose a safe group, even if the client is unable to negotiate one?
Either way, I would support deprecating FFDHE completely. > On Jul 30, 2021, at 12:46 PM, Viktor Dukhovni <[email protected]> wrote: > > On Fri, Jul 30, 2021 at 07:30:31PM +0000, Scott Fluhrer (sfluhrer) wrote: > >>> Was it wrong to generate server-side DH parameters? >> >> The problem is that it is hard for the client to distinguish between a >> well designed server vs a server that isn't as well written, and >> selects the DH group in a naïve way. > > I am well aware that verifying the safety of the server's choice is > computationally taxing. > >> Now, as I mentioned in the WG meeting, it would be possible to detect >> if the server proposes a safe prime (it's not especially cheap, being >> several times as expensive as the rest of the DH operations, but it's >> possible), and that would prevent most of the problems that can happen > > I don't think it is realistic for the client to go to that much trouble. > The server's choice of parameters is signed by the server's public key. > What is the threat model here? Is the client trying to avoid servers > that shoot themselves in the foot by verifiably choosing bad parameters? > > The server could also have a strong DH group, but a terrible RNG with a > well known RSA private key: > > http://dnssec-stats.ant.isi.edu/~viktor/mailcow.html > > If the server is not one of these or similar, and attests to its choice > of DH parameters, and they happen to be less than ideal, so be it. > Server operators should be encouraged to choose strong parameters, but I > see little reason for clients to second-guess that choice. > > If the DH parameter size is below a reasonable threshold (Logjam), a > client might balk, but otherwise I am not sure what practical problem > we're actually solving. > >> Of course, this works only if the legacy servers you are talking about >> actually do use safe primes... > > All the ones I know of use "openssl dhparam", which defaults to Sophie > Germain strong primes with generator 2. > > I strongly doubt there's a non-negligible server population with weak > locally generated groups. The only likely source of weak groups is > servers that used one the older now deemed weak groups published in > deprecated RFCs. > > So it might suffice to refuse specific known weak "standard" groups, > which would have a much lower impact than requiring particular standard > groups with no mechanism to negotiate these. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
