

Confirming Consensus on removing RSA key Transport from TLS 1.3 - ilamont
http://www.ietf.org/mail-archive/web/tls/current/msg12266.html

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

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

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

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

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

