David Benjamin writes:
>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.
TLS 1.3 is a non-starter for lots of embedded stuff so that leaves ECDHE which
I assume is what you're referring to with
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
Ilari Liusvaara 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
On Fri, Jul 29, 2022 at 01:59:58PM +, Peter Gutmann wrote:
> An additional comment on this, a pretty straightforward solution is
> to use the TLS-LTS one:
Unfortunately, that does not work because it would require protocol
modifications requiring coordinated updates to both clients and
An additional comment on this, a pretty straightforward solution is to use the
TLS-LTS one:
TLS-LTS sends the full set of DH parameters, X9.42/FIPS 186 style,
not p and g only, PKCS #3 style. This allows verification of the DH
parameters, which the current format doesn't allow:
o
