Confirming Consensus on removing RSA key Transport from TLS 1.3 | Hacker News Reader

Confirming Consensus on removing RSA key Transport from TLS 1.3

ietf.org

85 pointsilamont9 comments

No, you won't need new certificates.

This is great news. The RSA handshake is a relic of the 1990s. It predates forward-secret key exchange. RSA is discernibly weakening over time (1024 bit keys are almost universally believed to be within the practical reach of governments), and the RSA handshake puts all the weight of securing TLS on RSA. Because it uses RSA to encrypt and not just to sign, the TLS RSA handshake also adds significant complexity to the spec; for instance, we're all just living with the fact that TLS uses PKCS1v15 padding and is vulnerable to Bleichenbacher's oracle, and just sort of hoping nobody figures out a way to operationalize the attack. But just a few weeks ago researchers found a way to do exactly that to JSSE.

Good riddance. A protocol competently designed in 2014 would not work the way SSL 2.0 did.

What is proposed for removal is using RSA as a key encapsulation mechanism. The reasons are:

a) you don't get forward secrecy,

b) the details of the way it works are just wrong, have been broken several times in the past, and killing it outright is thought preferable to replacing it with something which works, and

c) some deployments do both signing and encryption with the same RSA key, which is terribly dangerous.

d) it requires the holder of the high value certified keys to keep them online, and use them for every handshake. (edit: this is incorrect, see below)

RSA will still be usable with TLS, in the role of long term authenticity keys. For example, my connection to HN now is using ECDHE_RSA. That won't go away.

I don't see what you mean with d). For ECDHE_RSA you still need your high value certificate key online to sign your public Diffie-Hellman parameter. Or do want to presign a few thousand of them and use them one after another in normal handshakes?

Sorry, I was confusing this with something else (ECDH_RSA suites, where you can achieve decent levels of forward secrecy by signing a new ECDH key offline every minute or so). All ECDHE_ suites need the high value key to be online at all times, because the signed data includes per-handshake values.

> c) some deployments do both signing and encryption with the same RSA key, which is terribly dangerous.

I think that just switching to DHE creates its own set of very dangerous problems.

When using RSA the same secret key will be used for all connections. This is a bad idea in case there is a chance the key gets eventually leaked, then you'll be able to decrypt all past communications. But as long as you create and use a sufficiently long key pair, and make sure nobody ever has access to it, communication will be pretty secure.

With DHE the problem is you have to create a new key per connection. This requires high-quality randomness (sufficient entropy) all the time. Now if randomness is just compromised one time, the attacker will be able to decrypt one communication session. You may say, no problem, it's just one session, secrecy will be reestablished the next session. However, compromising a single session is often as worse as compromising all sessions. A single session will give you access to session cookies, maybe to a user's password. It may allow you to inject malicious code and permanently back-door a victim's system.

Since the Dual_EC_DRBG disaster we saw how vulnerable "randomness" can be. Also attacks on a random number generator cannot be detected at all, if done correctly.

There are other caveats: With everybody going for ephemeral keys, people may think, less bits will be just safe enough, as it's just an "ephemeral" key. That's currently the problem with the apache shipped with most older Linux distros: DHE is hard-coded to merely use 1024-bit keys.

Also there may be attacks that work more efficiently if you have many session keys to break: i.e. if breaking a single key takes time N, breaking one out of M keys may just take M/N time. So getting a single session of a user and backdoor'ing his system may actually get easier with ephemeral keys.

Not saying that I'm opposed, but these kind of blunt decisions won't make me feel more secure.

1. If the RNG that you use for generating the one static RSA key is broken, you aren't secure either.

2. RSA key transport also transports a(n ephemeral) session key that is used for symmetric encryption and authentication of the payload and that can be used to compromise the connection if it can be predicted.

3. In a way, encrypting the session data is also done by generating an ephemeral "key" for each byte/block using the symmetric cipher as a CSPRNG (moreso with stream ciphers/modes than with "real" block modes), but you most certainly would not want to use that as an argument for using ECB in TLS.

4. Such blunt decisions have been long overdue. Complexity is a huge risk, it's about time we get rid of some of the cruft that makes systems vulnerable.

Don't almost all installations use RSA? Am I missing something?

They're jettisoning the RSA key transport handshake; that is, the part of the protocol where a client generates a session secret all by themselves, encrypts it with the server's RSA key, and sends the RSA-encrypted blob to the server.

The forward-secret handshake uses Diffie Hellman (or, more commonly, ECDH) so that both sides of the connection cooperate to derive the session secret. RSA is still used in the forward-secret handshake, but only to sign the DH handshake, to protect it from MITM attackers.

To expand a little on what tptacek said, and with the disclaimer that I have no idea what I'm talking about, ...

If you find your nearest copy of the OpenSSL command-line tool and run "openssl ciphers -v ALL", you'll get a list of all of the cipher suites that your particular OpenSSL build supports. For example:

    % openssl ciphers -v
    ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
    ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
    ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
    ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
    [...]

An SSL/TLS cipher suite is a specific combination of a key exchange method (the method the TLS peers use to exchange the keys used with the bulk cipher), an authentication method (the method the TLS peers use to authenticate each other), a bulk encryption cipher (the symmetric cipher used to encrypt data sent between the peers), and a message authentication code (the method used to verify that data isn't modified in transit). These four things are the "Kx=", "Au=", "Enc=", and "Mac=" columns in the output above.

Virtually all X.509 certificates issued by certificate authorities today for use with SSL/TLS are for use with cipher suites that use RSA authentication. You generate an RSA key pair, stuff your public key in a certificate signing request, staple some money to the CSR, and hand it to the CA. The CA takes your money, verifies that you are in control of the hostname(s) you want a certificate for, creates a certificate containing your public key (and other X.509 goop), signs the certificate with their private key, and hands the certificate to you. For better or worse, this isn't changing.

What is being proposed is the removal of cipher suites that use RSA for key exchange ("openssl ciphers -v kRSA") from TLS 1.3. There are many other cipher suites that use RSA for authentication but use other methods for key exchange ("openssl ciphers -v aRSA:\!kRSA"), and some of these other key exchange methods have the rather nice property of perfect forward secrecy.

(Note that OpenSSL's list of ciphers isn't exhaustive, especially if you're using the lame OpenSSL build that Apple ships. But even if you're using an up-to-date OpenSSL build, the various SSL and TLS RFCs specify so many cipher suites that even OpenSSL doesn't support them all.)

Reply on news.ycombinator.com