Re: [TLS] draft-deprecate-obsolete-kex - Comments from WG Meeting

[David Benjamin <[e-mail]>]

Solutions which require software changes to both sides may as well apply
that software change to TLS 1.3, or even just TLS 1.2 ECDHE. (RFC 7919
could also have been such an option, but it was defined wrong, per the
meeting discussion, it is not. So it goes.)

Skimming the TLS-LTS formulation, it seems like it'd have the same problem
as 7919 in this context anyway. Any negotiation-based solution must work
correctly when the feature is *and isn't* negotiated. Reusing the same
cipher suites forces the client to offer DHE in the problematic mode too.
(Also if we're making a new construction, it should be NamedGroup code
points, not spelled out params.)

Regardless, I don't think it's worth the time to define and deploy a fixed
variant of TLS 1.2 DHE. We've already defined a successor twice over.

On Sun, Jul 31, 2022 at 3:28 AM Peter Gutmann <[e-mail]>
wrote:

> Ilari Liusvaara <[e-mail]> writes:
>
> >Unfortunately, that does not work because it would require protocol
> >modifications requiring coordinated updates to both clients and servers.
>
> I was thinking of it more as a smoke-em-if-you-got-em option, since -LTS
> is by
> negotiation it'd be something to the effect that if you're using -LTS then
> you're covered, otherwise do X.
>
> Peter.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>