0
$\begingroup$

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.

$\endgroup$
1
  • $\begingroup$ To be clear for any non-PSK suite you must send the server cert to the client, and for ECDHE-RSA also a signature; client-auth is optional but if used you must also send the client cert and signature to the server. Generating your own certs with minimal content, for 2048-bit RSA you can get each to about 700-800 bytes. Except for 1.3 which your suites aren't, the rest of a standard handshake including client-auth signature can be about 700-1000 bytes more. You can do lots of data (as much as devices llike yours can do) with one handshake. $\endgroup$ May 24, 2022 at 0:33

1 Answer 1

1
$\begingroup$

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.

$\endgroup$
2
  • 2
    $\begingroup$ In addition to padding to block boundary for encryption, the listed suites add at least 20 bytes (some 24 or 32) for HMAC, and all add a header of 5 bytes (or 13 for DTLS but that removes TCP which more than compensates). $\endgroup$ May 24, 2022 at 0:34
  • $\begingroup$ However MQTT does not use DTLS? Only TLS over TCP, right? $\endgroup$ May 24, 2022 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.