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