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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
