Optimizing the TLS handshake

6.2. Optimizing the TLS handshake

6.2.1. Resumed vs. full handshake

The goal of the resumed handshake is to reduceCPUprocessing and the number of required round trips required during the full handshake [163]. There is however a clear tradeoff between the efficiency gains of using resumed handshakes and the security pro-vided by the full handshake, which is required when starting a new session. Indeed, a maximum session length of 24 hours is suggested in [61]. In practice, most web servers use sessions of a few minutes [6]. For embedded applications something in between should be considered as the prospects of successfully performing an attack increases with the amount of transmitted data. A hint towards a “reasonable" amount of data to be ex-changed during a single session of five megabytes is provided in [32]. For embedded ap-plications the amount of data exchanged may be relatively low, and therefore the session length can be allowed to span for a longer amount of time. In fact, instead of having a relatively short fixed maximum session length, it would be best to allow the server to per-form a full handshake whenever a certain amount of data has been exchanged during the session.

6.2.2. ClientHello

Each listed cipher suite uses a couple of bytes. Therefore, the client should include the minimum possible number of cipher suites in the❈❧✐❡♥t❍❡❧❧♦message.

Support for compression [59] is only worthwhile when large volumes of data are ex-changed. It only makes sense to include the compression method in the❈❧✐❡♥t❍❡❧❧♦

message when exchanges are expected to be large and contain low-entropy data. If mes-sages are short and/or contain high-entropy data—which is likely with data produced by sensors—using compression can actually increase processing time, and in some rare cases, expand rather than compress input data [107]. This is because running the com-pression algorithms is aCPUintensive process whose execution on short messages may take longer than actually transmitting the full uncompressed message. Similarly, data with little internal redundancies will not compress significantly but still takeCPUtime to run the compression/decompression algorithms. Furthermore, using compression is prone to implementation errors [107] and is a precondition for the CRIME attack [164]. Therefore, unless there is a clear benefit in terms of bandwidth savings by enabling compression, it should be disabled.

It is recommended to avoid listing non-essential extensions. For example, the mech-anism enabling theTLSserver to resume sessions and avoid keeping per-client session state [171] should be avoided because it adds a few hundred bytes to the handshake. Sim-ilarly, it is recommended to list as few curves and as few point formats as possible in the

❡❧❧✐♣t✐❝❴❝✉r✈❡sand♣♦✐♥t❴❢♦r♠❛tsmessages when theECCCipher Suites forTLS ex-tension is used [24].

6.2.3. Certificates

Encoding overhead

Most of theTLShandshake overhead is in the certificates exchanged during the hand-shake protocol. StandardTLSservers use X.509 certificates [54]. These certificates are con-structed and stored using ASN.1 and exchanged using Distinguished Encoding Rules (DER).

Consequently, each certificate contains metadata describing its structure as well as the types of each primitive data element constituting it. The amount of overhead that the certificate encoding brings is non-negligible, for example the server certificate of❤tt♣s✿

✴✴✇✇✇✳❣♦♦❣❧❡✳❝♦♠is 1151 bytes long, of which 310 bytes (27%) are encoding overhead.

Section 6.3.2 (page 103) provides an alternative which suggests using Card Verifiable Cer-tificates (CVCs) instead of X.509 certificates to avoid this issue.

Server certificates

Sending a server certificate chain should be avoided. If possible, clients should be provisioned with all required certificates to validate the (single) server certificate.

Certificate keys and signature schemes

RSAkeys and signatures have been traditionally used in X.509 certificates [54]. How-ever, usingECCkeys and signatures (fully compatible with X.509) is more appropriate on computational and transport efficiency grounds. For a given security level theECCkey and signature lengths are smaller than theirRSAcounterparts as a consequence of the most efficient attack onRSAkeys (Number Field Sieve method) having sub-exponential com-plexity, while the best attack method forECCkeys (Pollard-ρ) has exponential complex-ity [103, 193], thus resulting in smaller certificates taking less time to transport. ECCkeys and certificates are supported by many browsers [217] and smart card applications, par-ticularly by ePassports [31] and (chipped) driver licenses [117]. The study ofECCbased cryptosystems is certainly younger than the study ofRSA, but mature enough to be used with confidence.

The first and second columns of Table 6.1 present a rough comparison betweenECC

key sizes andRSAmoduli sizes for a comparable security level followed after the slash by

RSA Key Length (bits)/ ECC Key Size (bits)/

Certificate Size (bytes) Certificate Size (bytes) Savings

1024 / 589 160 / 291 51%

2048 / 845 224 / 315 63%

3072 / 1101 256 / 331 70%

Table 6.1: Comparison betweenRSAandECCkeys and the resulting certificates.

6.2. Optimizing theTLShandshake 99

the resulting certificate sizes (Without changing certificate fields other thans✐❣♥❛t✉r❡✲

❆❧❣♦r✐t❤♠, s✐❣♥❛t✉r❡❱❛❧✉❡, and s✉❜❥❡❝tP✉❜❧✐❝❑❡②■♥❢♦ [54]). The third column shows the substantial savings in certificate size whenECCis used instead ofRSA.

Issuer and Subject

The Issuer and Subject fields identify the entities issuing and being issued the certifi-cate, respectively. It is useful for these fields to have a well-defined structure that can be used to automatically index them in a directory service and “manually" checked. In most situations involvingM2Mcommunication and embedded devices, such as considered in this chapter, certificates are not intended for human validation. Hence, these fields can still be constructed following the conventions in [115], yet making them as short as possi-ble, e.g., each consisting of a single attribute pair,◆❆▼❊ ❂ P❑■❞, where◆❆▼❊correspond to the common name attribute, andP❑■❞is the public key identifier of the corresponding entity, e.g., a digest of the public key object encoded, for example, as a❯♥✐✈❡rs❛❧❙tr✐♥❣. We note that using❯♥✐✈❡rs❛❧❙tr✐♥❣sis discouraged in [102]. However, they allow the most succinct encoding of a public key identifier (binary data) and must be supported [54].

Alternatively a❯❚❋✽or❚❡❧❡t❡①tstring could be used, but then a printable and expanded representation of the public key identifier would be stored.

Certificate revocation

When an entity receives a certificate during the handshake, it must check that the cer-tificate’s signature is valid, that it has been issued by a trustedCA, that it is within its validity period, and that it has not been revoked. In order to check the revocation status of the cer-tificate, the entity can either retrieve the Certificate Revocation List (CRL) and check that the certificate in not included in it [54], or submit a query to the Online Certificate Status Protocol (OCSP) server, which will indicate whether the certificate is revoked [173]. Given that less information is exchanged and most of the processing is done by the (OCSP) server, it is suggested to use this mechanism instead ofCRLs.

6.2.4. Certificate Request

Distinguished names

The number of trustedCAroot certificate names should be kept to a minimum. The names themselves should be kept as short as possible, e.g., following the optimization presented in Section 6.2.3. Furthermore, if a single trustedCAroot is supported by the server, then this field should be omitted altogether. Even when there is more than one supported trustedCAroot, this field can be omitted by configuring clients to implicitly signal the server which clientCAthey are planning to use, e.g., by using a certain port or a specific suffix in the url.

Key Exchange Algorithm

There are three key exchange mechanisms: RSA,DHandECDH. It is suggested to use

ECDHinstead ofRSAorDH given thatECDHis based inECC, whileRSAandDHare based in Finite Field Cryptography (FFC) [146]. The size ofECCkeys are smaller and the as-sociated public key operations take less time to compute than using comparableRSAor

DHkeys [103]. Thus, by usingECDHnot only the sizes of the❈❧✐❡♥t❑❡②❊①❝❤❛♥❣❡and

❙❡r✈❡r❑❡②❊①❝❤❛♥❣❡can be reduced (with respect toDH), but also the computation of the pre-master secret can be performed more efficiently using less resources.

6.2.5. Combining the handshake optimizations

A base handshake size can be estimated by adding the sizes of the messages exchanged during this phase and excluding those pertaining certificate exchanges and cryptographic related extensions, e.g.,ECCextensions [24]. The base handshake size (about 630 bytes) can be used to estimate the size of several handshake scenarios using different cryptosystems in the X.509 certificates. Table 6.2 shows these estimations under the following handshake scenarios (last four columns):

• Handshake (only server authentication, no chain): The client authenticates the server. The server sends its certificate. The server does not authenticate the client.

• Handshake (only server authentication, chain): The client authenticates the server.

The server sends its certificate and the certificate of its issuer. The server does not authenticate the client.

• Handshake (mutual authentication, no chain): The client authenticates the server.

The server sends its certificate. The server authenticates the client. The client sends its certificate.

• Handshake (mutual authentication, chain): The client authenticates the server.

The server sends its certificate and the certificate of its issuer. The server does au-thenticates the client. The client sends its certificate.

For calculating the certificate sizes, each of the two entities (i.e., client and server) are assumed to have a key of the size indicated in the first column. The signature of the cer-tificate uses a key of the size indicated in the first column of the next row. In practiceCAs

tend to have larger keys than the entities that they certify, so it makes sense incorporating this consideration in the size estimation model.

Table 6.2c compares the values in Table 6.2a and Table 6.2b showing the bytes saved withECCas a percentage relative to the baseRSA. Note that the savings in Table 6.2c in-crease with the security level in a similar way than the savings in Table 6.1. This is not surprising because the savings are directly related to the certificate, and ultimately to the differences of the key and signature sizes.