Exchange of public keys with DHE-RSA

Question

The paper "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice" by Adrian et al claims that the NSA might be able to eavesdrop on a large percentage of TLS connections, because they managed to crack certain Diffie-Hellman groups. Now, I assume a situation where a client is connected to a server via DHE-RSA. What I don't understand is why, in this situation, cracking Diffie-Hellman alone would be enough to eavesdrop. Wouldn't it be necessary for the NSA to also get ahold of the private RSA key of the server? Put in different words: When the client sends his DH public key to the server, doesn't he encrypt his DH public key with the RSA public key of the server? (If not, why not?)

Answer 1

In case of DHE-RSA the RSA part is only used for authentication that the client speaks with the proper server. While it might be used to detect modifications of the key exchange it will not detect passive analysis of the key exchange, i.e. protect against attacks which only require to sniff but not to modify the data. An attacker who has managed to crack the specific DH group used by the key exchange (or has a planted a cryptopgrahic backdoor in it) does not need to actively fiddle with the connection but only needs to passively sniff on the connection in order in order to get to the exchanged key and decrypt the traffic.

It is known that the Five Eyes (i.e. NSA, GCHQ,...) but also other government services in various countries have access to a large part of the internets core systems and can thus passively listen to these data. Combined with weak or backdoored cryptography this makes it possible to sniff and decrypt the traffic without changing the traffic and in a way that sender and recipient will not notice it.

To address the question in the comment on why RSA is not used to protect the key exchange: one might argue that the knowledge of the servers RSA public key by the client would make it possible to encrypt the part of the key exchange which is send from client to server since the server might decrypt this part using its private key. While this would be possible with RSA it would mean that the DH key exchange is too much bound to the use of RSA and no longer a more or less independent mechanism. For example it would require the client to know the servers public key first. While is possible with TLS 1.0...TLS 1.2 where the DH key exchange is only done after the certificate of the server is known this is no longer the case with TLS 1.3 where the DH key exchange starts before the certificate is known. Also, more modern authentications mechanism based on ECC (i.e. ECDSA) are designed for signature only but not encryption which would mean that they could not be used to protect the DH key exchange anyway.