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 <pgut...@cs.auckland.ac.nz> wrote: > Ilari Liusvaara <ilariliusva...@welho.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
