On Thu, Jul 13, 2023 at 03:03:15PM +0200, Hubert Kario wrote:
> And in general, it's far better to use FFDHE kex with legacy client
> than RSA. Getting RSA right is very hard, using ephemeral secrets for
> FFDHE is trivial and recommended practice already.
Indeed, though I agree that TLS applications should prefer ECDHE key
exchange over FFDHE key exchange, I hold that requiring non-support
is counterproductive.
As a data point, here's a negotiated cipher suite breakdown from SMTP
servers that have DANE TLSA records:
30746 TLS 1.3 with AES256GCM-SHA384
2192 TLS 1.2 with ECDHE-RSA-AES256GCM-SHA384
426 TLS 1.2 with ECDHE-ECDSA-AES256GCM-SHA384
153 TLS 1.2 with ECDHE-RSA-AES128GCM-SHA256
115 TLS 1.2 with ECDHE-ECDSA-AES128GCM-SHA256
96 TLS 1.3 with AES128GCM-SHA256
71 TLS 1.3 with CHACHA20POLY1305-SHA256
71 TLS 1.2 with DHE-RSA-AES256GCM-SHA384
25 TLS 1.2 with DHE-RSA-CHACHA20POLY1305-SHA256
15 TLS 1.2 with ECDHE-RSA-AES256CBC-SHA384
5 TLS 1.0 with DHE-RSA-AES256-SHA1
4 TLS 1.2 with ECDHE-RSA-AES256CBC-SHA
3 TLS 1.2 with RSA-AES256GCM-SHA384
3 TLS 1.2 with DHE-RSA-AES128GCM-SHA256
2 TLS 1.2 with ECDHE-RSA-CHACHA20POLY1305-SHA256
1 TLS 1.2 with DHE-RSA-AES256-SHA1
Without any "MUST NOT"s, already TLS 1.3 dominates, and by far the bulk
of TLS 1.2 connections are using ECDHE.
What benefit do we expect from forcing weaker security (RSA key exchange
or cleartext in the case of SMTP) on the residual servers that don't do
either TLS 1.3 or ECDHE?
So long as we "raise the ceiling" we reap most of the benefit, and if
the handshake is downgrade resistant, raising the floor isn't always a
win.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
