> 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.
For example, if the server just selects a random prime and a random generator
value, well, that has a good probability of leaking quite a bit of information
about the private exponents; leak enough, and the shared secret may be
recoverable. This is not obvious to someone new to the field; it is also very
hard to detect by the client.
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 (exception: if the server proposes
an SNFS-friendly modulus, say, one with a very simple binary representation -
that would reduce the security noticeably). Of course, this works only if the
legacy servers you are talking about actually do use safe primes...
-----Original Message-----
From: TLS <tls-boun...@ietf.org> On Behalf Of Viktor Dukhovni
Sent: Friday, July 30, 2021 2:57 PM
To: tls@ietf.org
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods
in TLS
On Fri, Jul 30, 2021 at 05:14:08AM +0000, Peter Gutmann wrote:
> >The only other alternative is to define brand new TLS 1.2 FFDHE
> >cipher code points that use negotiated groups from the group list.
> >But it is far from clear that this is worth doing given that we now have
> >ECDHE, X25519 and X448.
>
> There's still an awful lot of SCADA gear that does FFDHE, and that's
> never going to change from that. The current draft as it stands is
> fine, in fact it seems kinda redundant since all it's saying is "don't
> do things that you should never have been doing in the first place",
> but I assume someone needs to explicitly say that. No need to go beyond that.
Can you explain what you mean by "don't do things that you should never have
been doing in the first place"?
There are quite a few deployments that generate local strong (Sophie Germain
prime) DH parameters. These would break if the draft sails through as-is, and
there's no mechanism for the client to inform the legacy server that its would
be choice of DH parameters is not acceptable.
Was it wrong to generate server-side DH parameters?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
