[tialaramex]

Well, this _is_ public-key signatures, it's just that the public keys here are just for signing things, whereas RSA public keys serve a bunch of purposes.

It turns out that using keys for unrelated things can make them into a footgun, so actually even for RSA where we know in principle how to safely use it for lots of purposes, the direction of modern cryptography is to pick one and just do that a lot.

For example, a typical web server "SSL certificate" has an RSA public key baked into it, and the server knows the corresponding private key. You want to exchange encrypted messages with this server, so you use RSA encryption right?

Nope. In the almost-published TLS 1.3 you proceed as follows: 1. Use ephemeral Diffie-Hellman to agree random new symmetric encryption keys, and immediately use those to do AEAD encryption for everything further 2. Send (encrypted) your Certificate. 3. Take a transcript of everything that happened so far, and _sign_ that transcript using RSA, send (encrypted) the signature.

This setup means an attacker can't make even a dumb server do any operations with their RSA private key except signing transcripts of sessions in which that server got to make random key choices. This is useless for any conceivable shenanigans so long as RSA is no more insecure that we think it is, and even if RSA is insecure, you need to actively penetrate specific sessions, the DHE protects any other sessions, even if you subsequently get all the private keys.

[bogomipz]

>" it's just that the public keys here are just for signing things, whereas RSA public keys serve a bunch of purposes."

Well but its still for "just signing things" in TLS when DH is used no?

>"Nope. In the almost-published TLS 1.3 you proceed as follows: 1. Use ephemeral Diffie-Hellman to agree random new symmetric encryption keys, and immediately use those to do AEAD encryption for everything further 2. Send (encrypted) your Certificate. 3. Take a transcript of everything that happened so far, and _sign_ that transcript using RSA, send (encrypted) the signature."

I haven't read the draf but in TLS 1.2 with DH and RSA, RSH is used to sign the DH parameters. Is this different in TLS 1.3? I guess I don't understand what you mean by "transcript" though. Is that word in the spec?

[tialaramex]

In TLS up to 1.2 straight RSA is an option. TLS 1.3 requires DH so it has this simpler flow. You are correct that with DH we already don't need RSA encryption, but did you make sure to remove straight RSA support from all your servers?

Yes the specification says, and means, transcript. Signing the entire communications transcript means a MitM can't touch anything.

Example, if a client optimistically wants to use VeryVerySecure feature and we are a MitM who wants to prevent that, we might think to fake a message from the server saying "No, I don't understand VeryVerySecure - do WeakAntique instead". In TLS 1.3 this extra message will be in the client's transcript, so a transcript signature from the server without any mention of VeryVerySecure fails and our MitM attack with it.

[bogomipz]

>"In TLS up to 1.2 straight RSA is an option"

Indeed, although straight RSA encryption fell out of favor some time ago. I see your original point now. Cheers.