What you describe is possible, but has a several disadvantages: - If the client's RSA private key leaks in the future, past communication sessions can be deciphered; there is no [forward secrecy][1], like there can be in some Diffie-Hellman variants. The only option to get that desirable property would be to use a new RSA key pair for each exchange, but then - the server has no way to verify the public RSA key generated by the client, thus the protocol might become vulnerable to a [man-in-the-middle][2] unless the client also has a long-term RSA key to sign it's one-session RSA public key. - as pointed in that [other answer][3], it requires generation of an RSA key on the client side, and that is typically quite slow. - The client does not participate in the generation of the session key, thus might be vulnerable to [replay][4], and rightly less confident in the session key (one generator more easily becomes stuck or low-entropy than the combination of two generators implemented by two parties). - RSA decryption (and RSA signature, which is needed for forward secrecy) on the client side is significantly more compute-intensive than the whole Diffie-Hellman exchange needs to be. That's true if DH is performed on a group $\mathbb Z_p$ (notice that the modulus is of the same order of magnitude in RSA and DH for comparable security, but the decryption exponent in RSA has about as many bits as the modulus, when it can be much shorter in DH; we are talking e.g. 2048 versus 256 bits, and commensurate performance gp; use of [RSA CRT][5] does not offset that); the difference in performance can even larger if we use an [elliptic-curve group][6] for DH. [1]: https://en.wikipedia.org/wiki/Forward_secrecy [2]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack [3]: https://crypto.stackexchange.com/a/41557/555 [4]: https://en.wikipedia.org/wiki/Replay_attack [5]: https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Using_the_Chinese_remainder_algorithm [6]: https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Theory