Session resumption with a pre-shared key

A pre-shared key (PSK) is a shared secret that was previously shared between the two parties using some secure channel before it needs to be used. You can establish a PSK during one TLS handshake and then use it to establish a new connection in another handshake; this is called session resumption with a PSK.

The PSK corresponds to a unique key derived from the initial handshake. If the server accepts the PSK when establishing a new connection, then the security context of this connection is cryptographically tied to the original connection, and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of the full TLS handshake.

The following figures show two handshakes, the first establishes a PSK and the second uses it.

Figure 1. TLS 1.3 handshake that establishes a PSK
This image is described in the following text.
Figure 2. TLS 1.3 handshake that uses a PSK
This image is described in the following text.
  1. The client sends a ClientHello message with a key_share extension to the server. This extension lists which key exchange cryptographic methods that the client supports.
  2. The server responds with a ServerHello message with a key_share extension. This extension contains the cryptographic method it wants to use for the key exchange.
  3. The server sends its server parameters to the client.
  4. Both the server and client exchange authentication messages.
  5. The server sends a NewSessionTicket message to the client, which contains a PSK that the client then may use for future handshakes by including it in the pre_shared_key extension in its ClientHello message.
  6. The client and server can now exchange encrypted application data.
  7. In a future handshake, the client sends to the server a ClientHello message with the key_share and pre_shared_key extensions. The pre_shared_key extension contains a PSK sent in a NewTicketSession message.
  8. The server responds with a ServerHello message with the pre_shared_key and key_share extensions. The pre_shared_key extension contains the PSK the server as agreed to use.
  9. The server sends its parameters to the client.
  10. The server and the client send each other Finished messages. They don’t perform the authentication phase as the security context of this connection is cryptographically tied to the original connection.
  11. The client and server can now exchange encrypted application data.
Note: The following behaviors are not supported:
  • Resumption using PSK only: You must use PSKs with (EC)DHE key exchange, which provides forward secrecy in combination with shared keys. Resumption using PSK only is less secure with regards to forward and backward secrecy.
  • Zero Round Trip Time Resumption (0–RTT): This enables the client and server to send application data in the first messages (ClientHello and ServerHello) to each other. The client uses a PSK to encrypt the application data it initially sends with the ClientHello and to authenticate the server. This has the security issues of resumption using PSK only and some potential for replay attacks.
  • Stateless server PSKs: RFC5077: Transport Layer Security (TLS) Session Resumption without Server-Site State describes a mechanism that enables the server to resume sessions and avoid keeping per-client session state. This mechanism would reduce server memory usage at the expense of forward secrecy for resumption using PSK only.
  • Out-of-band PSK establishment: This means the production of PSKs other than through NewSessionTicket messages.