Generating private keys based on the list of ciphersuites available

Question

I am building my own MQTT based network for which I would generate my own ca/server/client certificates for authentication.

The goal here is to keep the message sizes as small as possible so as to reduce the bandwidth traffic, but I already know that the TLS layer adds quite an overhead to the traffic it sends. Namely, with the client certificates, I would actually have to send the client certificate to the server and vice versa on each TCP connection attempt which can add up to 8kb without even sending one byte of real data. (I hope I got that part right so far)

Also, since a lot of my clients are small embedded devices which only have a limited number of ciphersuites they can use the matter is complicated even more.

For example this is the allowed list of ciphersuites a client can use:

CIPHERSUITE	CODE
TLS-PSK-WITH-AES-128-CBC-SHA256	00ae
TLS-PSK-WITH-AES-256-CBC-SHA384	00af
TLS-PSK-WITH-AES-128-CBC-SHA	008c
TLS-PSK-WITH-AES-256-CBC-SHA	008d
TLS-PSK-WITH-3DES-EDE-CBC-SHA	008b
TLS-RSA-WITH-AES-128-CBC-SHA256	003c
TLS-RSA-WITH-AES-256-CBC-SHA256	003d
TLS-RSA-WITH-AES-128-CBC-SHA	002f
TLS-RSA-WITH-AES-256-CBC-SHA	0035
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA	c013
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA	c014
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256	c027
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384	c028

Now in this example the only ciphersuites available are PSK and RSA based ones. Of course I would love to use the EC ciphersuites but I don't think this is an option for me given the list.

Now a couple of questions I have are:

• Given the ciphersuite list can any of the private keys (CA, Server or Client) be EC based or do they all have to be RSA?

• Should I also keep individual MQTT packages that are wrapped with TLS as small as possible or is this something which will be padded with additional bytes? (e.g. will it make a difference if my package is as small as 5 bytes or can I freely write a package that is 25 bytes long)

• What are some other things I should keep in mind if I want to reduce the traffic bandwidth?

• ECDHE-RSA ciphersuites are giving me a headache. They are using EC for key exchange but RSA for PKI ? Does this mean that a server can have EC private key.

Answer 1

Given the ciphersuite list can any of the private keys (CA, Server or Client) be EC based or do they all have to be RSA?

No only RSA, or a pre-shared symmetric secret for TLS-PSK of course.

Note that for the TLS-RSA ciphersuites the key will be used for key encapsulation, i.e. the encryption key usage and the TLS-ECDHE-RSA ciphersuites you need a certificate that can be used for entity authentication with the key usage for signing. Often both bits are set for TLS specific certificates.

Should I also keep individual MQTT packages that are wrapped with TLS as small as possible or is this something which will be padded with additional bytes? (e.g. will it make a difference if my package is as small as 5 bytes or can I freely write a package that is 25 bytes long)

AES will encrypt to a multiple of 16 bytes, 3DES to a multiple of 8. 3DES is still reasonably secure, but it should not really be used anymore. Fortunately TLS uses 3 key 3DES, so there's that.

ECDHE-RSA ciphersuites are giving me a headache. They are using EC for key exchange but RSA for PKI ? Does this mean that a server can have EC private key.

Correct, but the E in ECDHE means ephemeral-ephemeral Diffie-Hellman. Both the client and server will (likely/hopefully) generate a new key pair for each connection. Key pair generation for EC is about as fast as performing the DH key agreement itself though, it is much faster than RSA key pair generation.

This key pair is session specific and doesn't need to be stored, so you don't have to perform any key management around it. Only the RSA key is used for entity authentication so the private key and certificate does need to be managed.