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
