Brian Smith wrote: >Deprecating FFDHE key exchange without deprecating RSA key exchange will >substantially increase the usage >of RSA key exchange and thus make server key >compromise more dangerous. At a minimum, RSA key >exchange should be >deprecated at the same time, in the same document.
Deprecating static RSA and everything else that does not have PFS is long overdue. RFC 7540 did this 6 years ago, and it was not a day too late. Strange that the best TLS profiling was/is done by HTTPBIS. Viktor Dukhovni wrote: >In practice security improves more when you raise the ceiling, rather the >floor. Let’s start with mandating support of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for the remaining TLS 1.2 implementations. RFC 7540 did this 6 years ago, and it was not a day too late. Cheers, John From: TLS <tls-boun...@ietf.org> on behalf of Brian Smith <br...@briansmith.org> Date: Tuesday, 9 March 2021 at 01:13 To: Martin Thomson <m...@lowentropy.net> Cc: "TLS@ietf.org" <tls@ietf.org> Subject: Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe It is sad that nobody is willing to discuss the obvious downsides of this proposal as written, which should at least be mentioned in the security considerations. Without discussing the downsides we're reducing engineering to politics. If we discuss the downsides then we can substantially improve the proposal. Deprecating FFDHE key exchange without deprecating RSA key exchange will substantially increase the usage of RSA key exchange and thus make server key compromise more dangerous. At a minimum, RSA key exchange should be deprecated at the same time, in the same document. Look at Windows Server 2012 and similar legacy products that are in widespread use, which don't support any PFS cipher suites except FFDHE. Please deprecate RSA key exchange at the same time so that there is enough motivation for vendors of these legacy products to add safe alternatives and/or for users of these legacy implementations to upgrade to something new that implements a safe alternative. (Note that Windows Server 2012 did add a patch to enable increasing its FFDHE key size to safe sizes.) It would be useful for the browser vendors that recently dropped FFDHE support to share their measurements for how much RSA key exchange usage increased after their changes. That would help us quantify the real-world impact of this change. RSA key exchange uses flawed and error-prone cryptography that is prone to side channels as well, PKCS#1 encryption/decryption. Previous studies have found widespread flaws in implementations that are (AFAICT) even more easily exploitable than the Racoon attack is. It is easy to imagine a perfect implementation of RSA key exchange that also perfectly protects the server's private key. It is unrealistic to expect implementations to actually live up to that ideal. When RSA key exchange is used, then a government that can effectively undo all the past encryption of a server if it can force the server operator to disclose the key, even for a perfect implementation of RSA key exchange. Deprecating RSA key exchange at the same time as FFDHE will encourage adoption of newer products that also often support TLS 1.3. Without creating a new, correct, way to use FFDHE key exchange, we're left with elliptic curve (ECDHE) key exchange as the only reasonable and widely-implemented key exchange mechanism. Cheers, Brian (Speaking only for myself) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
