Combinations of key exchange and signature algorithm in TLS

Question

Let's say that one does not trust ECC a lot, and values confidentiality over authenticity (perhaps simply for the reason that MitM is more difficult than passive eavesdropping and decryption later on). In this case one might use classical DHE for key exchanges, and ECDSA for signatures.

Is there anything problematic in doing so? In order to have high encryption strength, one would use large DH params (16k perhaps) since the classical DHE key exchange is not computationally expensive, and faster ECDSA signatures on the exchanged DHE keys. Further, this combination is not part of the TLS specification (as far as I know), why not?

EDIT: Just to clarify, it appears this is indeed not part of the specification, but I am seeking answers as to why not, or if this would be a bad idea from a security perspective.

Answer 1

In order to have high encryption strength, one would use large DH params (16k perhaps) since the classical DHE key exchange is not computationally expensive,

I can't give you hard numbers for the speed. The openssl speed command does not seem to offer the benchmark for regular (finite field) Diffie-Hellman.

This answer offers guidance on practical DH-parameter sizes:

• Thomas Pornin. Answer to: Is this prime number large enough / too large for a Diffie-Hellman for AES-256?

this combination is not part of the TLS specification (as far as I know)

Correct. There is no combination of _DHE_ and _ECDSA in the current cipher suite assignments.

$ wget https://www.iana.org/assignments/tls-parameters/tls-parameters.txt
$ cat tls-parameters.txt | grep -i _ecdsa_  | awk '{print $2}' | cut -d _ -f2 | sort | uniq -c
     17 ECDH
     21 ECDHE

Answer 2

The classical DHE is computationally expensive, at least as these things go. This rarely matters (a normal PC can still do hundreds of DHE per second), but if you are in a situation where computing budget is tight (e.g. small embedded systems) then ECDHE is substantially cheaper.

With "normal" implementations, the cost of DHE is proportional to p²r, where p is the size of the modulus, and r is the size of the secret exponent used in DHE. r needs not be larger than, say, 256 bits, IF the DH parameters are such that the size of the subgroup does not have small prime factors. Unfortunately, TLS gives no way to the server to convey to the client the size of the subgroup, so a cautious client will need to use a secret DH exponent at least as big as the modulus, raising the cost to p³. Even if a "small" exponent can be used, a DHE with a 16384-bits modulus is going to be expensive (depending on the size of the secret exponent, it will be between 64 and 512 times the cost of a more mundane 2048-bit DHE modulus). Perhaps more importantly, an oversized DH modulus may not work at all, because many implementations have internal limitations for various engineering reasons.

There is no defined cipher suite that combines a classic DHE, and ECDSA signatures. So the question may be moot anyway. Such cipher suites could be conceptually defined; it would not be hard; but it has not been done, hence implementations don't support it.