What you're describing sounds similar to the use of temporary RSA key exchange, as described in Appendix F.1.1.2 of RFC 4346 (TLS 1.1) (also in RFC 2246, TLS 1.0).
I have never seen it used (but others may have). However, there seem to be a few inconsistencies in the specification on this subject. In particular, this appendix says that "[it] may be a temporary RSA key sent in a server key exchange message", but Section 7.4.3 (Server Key Exchange Message) says: "It is not legal to send the server key exchange message for the following key exchange methods RSA, DH_DSS, DH_RSA", which leaves the DHE cipher suites (and DH_anon). I must admit I'm not quite sure how this would work then, considering that with DHE_RSA and DHE_DSA, the DHE parameters are still signed using the certificate's key. This may explain why the mention of temporary RSA keys has disappeared from TLS 1.2.
Your other suggestion, about fixed DHE parameters, removes the "ephemeralness" of DHE, so that's rather about fixed DH; not all stacks support it. In addition, you'd still want the RSA/DSA key in the certificate itself to be used for the authentication anyway.
More fundamentally, it sounds like the potential vulnerability you're trying to prevent is someone stealing your certificate's private key.
- Firstly, you may find you still need a way to revoke C_K_d, should its private key be compromised too. You don't necessarily gain that much using a scheme like you describe.
- Secondly, "[...] stored in a special mass storage" sounds like you have access to the hardware and could potentially plug something in. Instead of twisting TLS like you're suggesting, I'd suggest using a Hardware Security Module: there are cryptographic tokens/smart cards from which the private key cannot be extracted, it can only be used on-board. You might have to leave the PIN code in clear in your server configuration, but at least the private key will never be copied, so if you suspect foul play, just unplug the device. (I've managed to run a Java-based SSL/TLS server using such a token and a PKCS#11 provider in the past. I'm not sure how this can be configured with other servers, but this is possible in principle.)
Just a bit of background about how SSL/TLS is used. There are essentially 3 categories of specifications involved:
- SSL/TLS itself. Depending on the version this will be RFC 2246, 4346 or 5246. This describes how the protocol itself works (including the handshake). You could include in this category other RFCs that define additional cipher suites (e.g. Kerberos or EC).
- Certificate validation/verification. Assuming X.509 certificates are used (as it is the case for HTTPS communications, see RFC 2818), clients rely on RFC 3280/5280. This defines how the client evaluates whether it considers a certificate genuine, trusted and valid for this purpose.
- Host name verification. RFC 2818 Section 3.1 or RFC 6125: this defines how the client should decide whether the server certificate matches what the client was looking for.
As I was saying above, I don't think what you're trying to do can be done out of the box with these specifications.
It's not quite clear to me whether you're more after modifications involving the TLS Server Key Exchange message (so tweaking TLS itself) or new certificates (more along the lines of tweaking the certificate validation/verification step). It's easier to do the latter (both in theory and in practice), although both can be risky.
Since it seems that the problem you're trying to fix is the theft of your server private key, you may be interested in RFC 3820 (not to be confused with RFC 3280), which defines proxy certificates. Essentially, you can use an End-Entity Certificate (that is not a CA certificate) to issue a proxy certificate, usually with a much shorter validity period (e.g. 24 hours). This tends to be used in the Grid world to delegate authentication credentials, when connecting as a client. This aims to address the problem of potentially vulnerable private keys (on the machines where you delegate your credentials). I've never tried it from a server point of view, but it could work in principle. Apart from the generation of this proxy certificate, this approach wouldn't require many changes on the server side (they're X.509 certificates with a few specific attributes). However, this would still require changes on the client side to trust these certificates, since it would break RFC 3280/5280. (You can make modern versions of OpenSSL recognise such certificates.) This wouldn't work with most browsers out of the box.
At least, proxy certificates have a time limit. It's not clear how other schemes that you may be suggesting would help against the theft of private key. If you don't have a mechanism to revoke your temporary key/cert, the vulnerability would still exist, since a spoof server having one of your temporary private key could still impersonate your real server forever.
Considering the threat you seem to be worried about, a HSM still sounds like the best option, and it would work with existing stacks without tweaking the standards normally used.