One of the major new features of TLS v1.3 is the 0-RTT handshake protocol. This variation of the handshake, using Pre-Shared Keys (PSKs), allows the client to send encrypted data to the server in the first flight. This is particularly useful for TLS on embedded devices. Take the example of IoT. There may be thousands or even millions of devices reporting back regularly to the central servers with small updates.
Using 0-RTT, the IoT device can send a ClientHello plus all the update data, known as “early data”, in one flight. Then, the server responds with the ServerHello, EncryptedExtensions, and Finished messages plus acknowledgement of the early data all in one flight. Finally the device responds with EndOfEarlyData and Finished messages in a final flight to close the loop on the security.
We can see that the data is offloaded, without having to wait for the server. The device stores a little state and goes back to its job ready for the interrupt on response. If the response times out then the server can resend with an updated ClientHello. On response, the device processes the handshake messages and responds closing the connection and the update can be discarded.
This is all very efficient in terms of processing and overall round-trip time. But, there are potential security issues including: replay attacks and no forward security.
An attacker can replay messages from a device. The server decrypts the early data using a key directly derived from the PSK and no other authentication is performed. Without the second flight from the client, the server would not recognize the copy is invalid. The recommended defense is single-use tickets. Each ticket contains a fresh PSK. This has the downside of requiring a shared database of tickets across servers. Alternatively, unique values from the ClientHello used with each PSK can be stored instead.
The attacker may also intercept the client’s first flight and spam the server with copies. If the early data contains “state modifying” data as in the example above, processing a copy would be disastrous. If the PSK is single-use, the client will get out of sync with the server and a full handshake will be required. The server may well interpret the attack as the client attempting to retry and therefore this must be handled at the application level.
When the PSK is reused for a number of messages, forward secrecy is lost. This means that if a device is compromised all messages encrypted using keys derived from the current PSK are exposed. The recommended defense is to use a short timeout with tickets to limit the period of vulnerability.
Using 0-RTT does require more careful architecture on the server side, the benefits at the client side are worth it.