Decrecating _DHE_ cipher suites seems ok but sends a weird message. A more reasonable approach would be to deprecate all cipher suites without _ECDHE_. An essential zero trust principle is to minimize the impact of breach such as key compromize. Key exchange without forward secrecy should only be allowed in resumption.
While the WG is in deprecation mode, please deprecate all non-AEAD cipher suites as well. RFC 7540 did this 7.5 years ago... It is a much bigger problem that IETF is legitimizing bad crypto and bad security practice than that TLS used in some small amount of deployed devices are labeled depracated. Cheers, John From: TLS <tls-boun...@ietf.org> on behalf of Hubert Kario <hka...@redhat.com> Date: Wednesday, 21 December 2022 at 14:59 To: Martin Thomson <m...@lowentropy.net> Cc: tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] consensus call: deprecate all FFDHE cipher suites On Tuesday, 20 December 2022 23:56:22 CET, Martin Thomson wrote: > On Tue, Dec 20, 2022, at 23:52, Hubert Kario wrote: >> use of FFDHE with large key sizes is the best protection against >> store-and-decrypt-later attacks > > This doesn't deprecate use of FFDHE in TLS 1.3, for which we > have some ludicrously large named groups. Is that not enough? Not everybody has migrated to TLS 1.3 yet. Not everybody has migrated to ECC. For the people that still have the only options of RSA key exchange or FFDHE key exchange, both in TLS 1.2, we need to be crystal clear that they should pick FFDHE. Telling people that they shouldn't use the only things they can use means that the advice is unactionable, thus will be ignored. >> If anything, RSA key exchange should be deprecated first. >> RFC 8446 deprecated only the DSA ciphersuites, not RSA. > > This is an odd statement. TLS 1.3 ciphersuites no longer > include the concept of key exchange or signing. Ciphersuites, yes. Protocol itself, no. It still performs a key exchange. And TLS 1.3 explicitly deprecates DSA, see below. > If you are talking about the signing part, both were sort of > deprecated. RSASSA-PKCS1_v1.5 (ugh, I hate typing that) is only > usable within the certificate chain, not in the protocol. PSS > was added back. There's a difference between saying that a TLS 1.3 client MUST NOT advertise client hello with TLS_RSA_* ciphersuites listed, and just having TLS 1.3 not supporting RSA key exchange. Both of them can be called "deprecated", but one is a clearer and stronger condemnation than the other. DSA is effectively treated with the former "deprecation": RFC8446 Section 4.2.3: > They MUST NOT be offered or negotiated by any > implementation. In particular, MD5 [SLOTH], SHA-224, and DSA > MUST NOT be used. RSA key exchange has nothing like it. For me "deprecated" means "You really shouldn't use it", not "You should stop using it at the earliest convenience". I.e. MUST NOT vs SHOULD NOT. > However, for key exchange, which is more relevant to this > conversation, RSA was indeed removed. And the draft we're > discussing does indeed say that RSA key exchange in TLS 1.2 is > deprecated. > > Can you help me better understand the scope of your objection? I guess my primary objection is with the subject of this thread: "deprecate all FFDHE cipher suites". That I don't agree with. As far as the "draft-ietf-tls-deprecate-obsolete-kex-01" text goes, I would tweak some things, but the general description of FFDHE state I do agree with: "that you shouldn't use it in TLSv1.2, but if you have to, there are simple things to do to make sure you're relatively secure". -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com<http://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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
