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 "succ
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 se
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 i
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
server
ber groups or similar.
Peter.
From: TLS on behalf of Nimrod Aviram
Sent: Friday, 29 July 2022 02:41
To:
Subject: [TLS] draft-deprecate-obsolete-kex - Comments from WG Meeting
Hi Everyone,
Thank you for chiming in with comments and suggestions regarding
draft-deprecate-ob
Hi Everyone,
Thank you for chiming in with comments and suggestions regarding
draft-deprecate-obsolete-kex :-)
I've tried to summarize everyone's comments below, hopefully grouped by
subject.
Apologies in advance if I missed anything (or misspelled names...), please
do reply to this thread :-)
M
