On Friday, 22 September 2023 08:08:17 CEST, Peter Gutmann wrote:
This draft still has the same problem that's been pointed out previously:
Clients MUST NOT offer and servers MUST NOT select FFDHE cipher
suites in TLS 1.2 connections.
What this means is that if the implementation doesn't support
ECC, as some do,
then it's in effect saying:
Clients and servers MUST use RSA cipher suites.
Some people may actually read a bit further and see the MUST NOT RSA, but
that's just as non-useful because now it's saying you can't do
TLS at all. So
it needs to say:
Unless ECC suites are not available, [Clients MUST NOT ...].
Or just something that doesn't end up being MUST RSA as it's currently being
interpreted.
I'd also go further and say that since FFDHE is allowed in TLS 1.3 it's also
safe with EMS or LTS in effect, so it should really be:
Clients and servers that do not support TLS-EMS or TLS-LTS MUST NOT offer
and servers MUST NOT select FFDHE cipher suites in TLS 1.2 connections.
the "problem" with FFDHE in TLS 1.2 are the parameters provided by the
server that the client can't really influence (as most servers that can't
do ECC also ignore rfc7919), so there's chance that they are bad.
The other is if the server has static key share, then it's vulnerable to
Raccoon attack.
None of which are fixed by EMS
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
