Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

> 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 <[e-mail]> On Behalf Of Viktor Dukhovni
Sent: Friday, July 30, 2021 2:57 PM
To: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/tls