Re: Key exchange for dummies.
"That's true for authenticated keys, but that should be done after an encrypted channel has been formed and over the encrypted channel. Otherwise you're revealing who is conversing in plain-text (the signatures themselves)."
This is not how SSL works, nor is it a problem it tries to solve. It's perfectly obvious who is conversing because (over the public internet) you can see the endpoints anyway. And signed certificates will be passed to anyone that connects to the server, so it's pretty irrelevant to this domain (though probably not all domains) who gets to see it and we don't care if it's secret or not.
But in my example the session key isn't encrypted with B's key, it's encrypted with A's public key, and as A's key isn't verified it can be temporary. If A uses a permanent key then yes, A could be strong-armed, but A is the client.
I think I became confused over who A and B were. OK, lets flesh out your example a bit -
The client is A and the server is B. It's not mentioned but we'll assume that RSA authentication is used to rule out MITM attacks (right?) at the start of the connection in the usual way. The Key pair used here will be Kb0 (private) and Kb1 (public) and Kb1 is signed. So now we know who is talking to who and we're left with the problem of establishing a session key in a way that cannot be decoded from a traffic dump afterwards.
The 'pure' RSA method is for A to use Kb1 to encrypt a session key, Ks, and send it to B which decrypts using Kb0. If Kb0 is ever discovered then Ks can be recovered and the whole session can be decrypted.
Your proposal is that the client generates a new Public/Private key pair (Ka0 and Ka1) and sends the public part (Ka1) to the server. The server uses this to encrypt a random session key Ks, sends it back to the client which decrypts using the private key (Ka0), so now encrypted comms can commence. Ka0 and Ka1 are immediately erased so Ks can't be decrypted in future. Correct?
The method used in the article and in practice is to use DH, send some parameters over the wire, and come up with Ks in a way that never exchanges Ks or enough information to derive Ks over the wire.
I can see no reason your solution wouldn't work (this doesn't mean it's perfect, there may be good reasons it isn't, I'm an amateur crypto-geek not a pro). It does send Ks over the wire so if RSA factorisation ever gets 'solved' you may have the same issue. This seems unlikely, though you'd want to use a long key to be sure.
The reason you might not deploy it in practice is that generating RSA key pair Ka0 and Ka1 is a non-trivial computational expense for the client and can take a number of seconds even on a relatively modern machine, greatly extending the TLS handshake period. Encrypting with them is also somewhat expensive for the server. DH is comparatively trivial and fast for both sides.
So AFAICT there's no cringeing needed, your scheme would work but is slow. AFAICT.