4 ms·

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 w

by ctz 12y ago

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.

Perseids 12y ago
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?
- ctz 12y ago
  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.
dvdkhlng 12y ago
> 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.
- zAy0LfpBZLC8mAC 12y ago
  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.

by ctz 12y ago

Perseids 12y ago

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?

ctz 12y ago
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.

dvdkhlng 12y ago

> 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.

zAy0LfpBZLC8mAC 12y ago
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.