CNS - 31 - TLS v1.3

Lecture Info

  • Date: [2020-12-02 mer 11:30]

  • Lecturer: Giuseppe Bianchi

  • Slides: (27_tls_1_3.pdf)

  • Introduction: In this lecture we introduce the basic concepts introduced in the latest TLS version, that is, TSL v1.3.

1 Approval of TLS 1.3

The latest version of TSL, that is TLS v1.3 was approved in March 2018

The RCF was then released in August 2018.

1.1 Changes

The following improvements were made in the latest version:

  • Pruned all symmetric algorithms considered legacy like SHA-1, MD5, RC4, DES, etc.

  • All left ciphers are AEAD, which thus support authentication and encryption in a single algorithm. This means that in the new version the hash function present in the cipher suite is the hash algorithm that is only used for the hmac-key-derivation-function. Example of supported cipher suites are the following ones

    • TLS_AES_128_GCM_SHA_256

    • TLS_AES_256_GCM_SHA_384

    • TLS_CHACHA20_POLY1305_SHA256

    • TLS_AES_128_CCM_SHA256

    • TLS_AES_128_CCM_8_SHA_256

  • Perfect forward secrecy guaranteed in the new handshake, meaning that if a long-term private key is compromised at some point, the data delivered before this time is not affected. Notice that perfect forward secrecy is now becoming increasingly important because governments are able to do mass-scale surveillance and collect all the data for a long time.

Observation: Even without having powerful governments, perfect forward secrecy prevent software bugs like heartbleed to break all security. The commit which introduced this vulnerability was done on the 31 of december in 2011 time 23:00.

2 New Handshake in TLS 1.3

Notice that RSA key transport cannot guarantee perfect forward secrecy, because the pre-master secret is generated by the client and is then encrypted with the server's long-term public key. If the private key of the server is disclosed, an attacker may decrypt all data logged until that point. To guarantee perfect forward secrecy we also cannot use fixed DH, because if the private key is disclosed, all previous and future pre-master secrets are revealed.

Thus, the only way to go is with ephemeral DH, where the long term key is only used to sign the DHE public coefficients. In these cases a compromise on the private key of the CA or the server does automatically make the attacker able to read all the previous traffic.

With only DHE left there is no longer the need to negotiate the asymmetric algorithm to use during the new handshake. This means that the handshake can be closed in \(3\) messages instead of \(4\), because in the first Hello server message the client can include his EDH value.

Notice that after the first message the server is already able to start encryption, because it can compute the pre-master secret \((g^x)^y\) and then derive all the keys needed using the HKDF with the given nonces \(N_c\) and \(N_s\).

Observation: As a side effect of the fact that the server is able to encrypt starting from the first message we also get identity protection, meaning that the identity of the server can be hidden by the encryption mechanism.

2.1 Pre-Shared Key

In the TLS community there was a lot of discussion for adding the possibility of using a pre-shared key for some environments. That is, there are some places for which is not convenient to have asymmetric encryption. Since TLS v1.2 there is thus the support for pre-shared key.

This is used in various situations such as:

  • Limited and constrained environments.

  • When you connect to a site and then after a few hours or days you want to connect back using the same pre-master secret.

Notice however that like this we lose the perfect forward secrecy property. Thus, in TLS v1.3 an optional support was added to cover this issue by combining the pre-shared key with an anonymous DH.

When the server receives the value \(g^x\) it can generate dynamically a master key which depends on the pre-shared key, the nonce, and also the DH key generated on the fly. Notice that no certificates are needed, because the final key is not used for encryption but only as an extra nonce in the computation of the actual master secret.

\[\text{HKDF}_{\text{psk}}\bigg(N_c, \,\, N_s, \,\, (g^x)^y\Bigg)\]

Thanks to this we have achieved perfect forward secrecy with a static pre shared key (psk) and with no certificate.

2.2 Detailed Structure

The detailed structure of the new handshake is shown below

2.3 0-RTT Data

At some point Google tried to optimize the usage of HTTPS in order to remove all the waiting time from the moment a TCP connection is started to the moment the TLS handshake finishes. Even though this may seem impossible it was actually done by using pre-shared keys.

The basic idea is that the client can generate a new key by using the HKDF with the psk and by using as argument the Client-Hello-content message. This method is much faster in terms of speed, since with this approach when we open the TLS message inside the very first message we can already put the HTTP request, saving us a full RTT. The trade-off of this speed gain is lost in security however, since in the time window between the first and second message you are vulnerable to replay attack, since there is only the client nonce and thus the server is not able to tell if a request is being replied or not.

Observation: By combining the usage of a pre-shared key for sessions to the same server with the 0-RTT data transfer you save a lot of time. This however must come at the risk of a replay attack. In case of google this is not a big deal, but for other services the story might be different.

2.3.1 Mitigate the Replay Attack

The only way to truly solve a replay attack would be to include the server nonce, which is not the case. The possible mitigation then could be:

  • Control nonce reuse: the idea is to keep a record of all client nonces. While this solution is simple, it is also very hard to deploy in large scale systems.

  • Time window mitigation: in this case a maximum lifetime is defined for the usage of the pre-shared key after the first session. The standard default is \(7\) days.

3 Other Stuff in TLS 1.3

Other things which changed in TLS v1.3 are mentioned below:

  • No renegotiation anymore.

  • HKDF officialy included.

  • A few simplification in EC management.

  • Removal of compression (CRIME).

  • Exported key (intregates RFC 5705) which allows to export to applications a futher shared secret key.

The take home message is that, in security, less is more.