On Tue, Dec 13, 2022 at 09:46:29AM -0500, Sean Turner wrote:
> This message starts the process to judge whether there is consensus to
> deprecate all FFDHE cipher suites including those well-known groups.
> Please indicate whether you do or do not support deprecation of FFDHE
> cipher suites by 2359UTC on 6 January 2023. If do not support
> deprecation, please indicate why.
My take is that an RFC deprecating TLS 1.2 FFDHE ciphersuites will not
have a positive impact on the ecosystem. Most security improvements
result from raising the ceiling, not the floor, implementing the
preferred algorithms, and making sure that algorithm negotiation resists
downgrades.
If the protocol's algorithm negotiation fails to protect against
downgrade attacks, then either the protocol needs to be replaced, or
else indeed parameters that make downgrade attacks possible need to be
deprecated.
Otherwise, less-preferred, but widely used (at least in some industry
sectors) parameter choices should be marked as less preferred than
other parameter choices (i.e., in this case, implementations SHOULD
support ECDHE, SHOULD use ECDHE whenever mutually supported), but
should not be "deprecated" (as in marked "DO NOT USE").
If I've not paid enough attention, and missed an important reason
why leaving FFDHE available, while preferring ECDHE opens the door
to downgrade attacks or other critical problems, then of course
deprecation would be appropriate.
Otherwise, as a data point, looking at SMTP IP endpoints that support
DANE (presumably bleeding-edge enough to take non-default security
measures), I see:
TLS 1.3:
20187 AES256GCM
7115 CHACHA20POLY1305
12 AES128GCM
TLS 1.2:
3283 ECDHE
103 DHE
3 RSA
TLS 1.0:
5 DHE
1 RSA
This supports the idea that raising the ceiling is in fact sufficiently
effective:
* The majorify of servers support and use TLS 1.3.
* The majority of TLS 1.2 servers negotiate ECDHE
In this population of servers I see 108 DHE-preferring/only endpoints
out of ~30k (and 4 RSA endpoints).
The numbers will continue to improve organically, but laggards could
be encouraged by publishing a document that strongly recommends use
of ECDHE (or X25519/X448) whenever possible, rather than DHE.
The scope of any proposed "deprecation" should also be clarified, in
response to David Benjamin's question, as to whether this is just TLS
1.2, or also TLS 1.3.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
