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
