← Back to Table of Contents

PSK and Session Resumption in TLS 1.3

TLS 1.3 unified session resumption under a single mechanism: Pre-Shared Keys (PSK). Session IDs and session tickets from TLS 1.2 are replaced by PSK-based resumption.

How It Works

After a successful handshake, the server sends a NewSessionTicket message containing an encrypted PSK identity. The client stores it. On reconnection, the client includes the PSK identity in the ClientHello’s pre_shared_key extension.

The server decrypts the ticket, recovers the PSK, and uses it in the key schedule. If the server also accepts a key_share from the client, the resumed session gets both PSK-based authentication and fresh ECDHE forward secrecy. This is called PSK with (EC)DHE, and it’s the recommended mode.

sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: PSK + ECDHE Resumption (1-RTT)
    C->>S: ClientHello + pre_shared_key + key_share
    S->>C: ServerHello + pre_shared_key + key_share
    S->>C: Finished (encrypted)
    C->>S: Finished (encrypted)
    Note over C,S: Resumed with forward secrecy

PSK-Only Mode

If the client sends a PSK but no key_share, and the server accepts, the session is resumed using only the PSK. No ECDHE. This is faster (no DH computation) but loses forward secrecy for the resumed session. If the PSK is compromised, the session can be decrypted.

PSK-only mode is generally discouraged for this reason. PSK with ECDHE is preferred.

Improvements Over TLS 1.2

• No separate session ID or ticket mechanism. Everything goes through PSK.
• Forward secrecy on resumption. PSK + ECDHE gives you fresh ephemeral keys even on resumed sessions. TLS 1.2 session tickets didn’t have this.
• Ticket lifetime and age. The server specifies a ticket lifetime, and the client reports the ticket age. This helps the server detect replayed tickets.

---

Next: 0-RTT: Speed vs Security