On Fri, Jul 30, 2021 at 10:34:55AM +1000, Martin Thomson wrote:
> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
> > This is a working group call for adoption of Deprecating Obsolete Key
> > Exchange Methods in TLS (draft-aviram-tls-deprecate-obsolete-kex-00
> > <https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/>).
> > There was support for adopting this draft at the IETF 111 meeting.
> > Please review the draft and post your comments to the list by Friday,
> > August 13, 2021.
>
> Yep, let's do it. There were comments suggesting that this wasn't
> going to work for some deployments yet. That's OK, that's how this
> works: we decide to deprecate, discuss and publish a document, then
> people get to work out how they change their deployments. If we don't
> take that first step, then in many ways things don't get better.
> Adopting this is that first step and a good idea.
I support adoption of the draft and deprecation of RSA key exchange.
For FFDHE, I'd much rather see outright deprecation a la Chrome, than a
silent restriction by client (with no mechanism to negotiate otherwise0
to parameters that the server may not be prepared to support.
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 is far less risk of interoperability failure if the client or
drops support for FFDHE, rather than silently chooses to reject
previously working parameters.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
