> Telling people that they shouldn't use the only things they can use means that the advice is unactionable, thus will be ignored.
Yep, that's precisely what people are suggesting. If someone has a legacy system that cannot be upgraded, or they need to interface with such systems, they can ignore the deprecation and continue to use FFDHE. On Wed, Dec 21, 2022 at 5:59 AM Hubert Kario <[email protected]> wrote: > 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 > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
