Day 12: Session Resumption and PSK

Phase 1 · May 25, 2026

Agenda (2–3 hours)

• Read (60 min): RFC 8446 §2.2 (Resumption), §4.2.11 (pre_shared_key), §4.6.1 (NewSessionTicket)
• Study (45 min): PSK-only vs PSK-DHE, forward secrecy implications
• Practice (30 min): Observe session resumption with openssl
• Challenge (30 min): Written security analysis

Why Session Resumption?

Full 1-RTT handshake requires ECDHE key generation and a full transcript.
For high-frequency clients (CDNs, APIs called thousands of times/sec),
this adds measurable latency and CPU cost.

PSK (Pre-Shared Key) mode: server sends a ticket after a full handshake.
Client presents the ticket on the next connection to skip the full auth flow.

NewSessionTicket (Post-Handshake)

Server sends after Finished:

struct {
    uint32 ticket_lifetime;   // seconds until ticket expires
    uint32 ticket_age_add;    // random value to obfuscate age
    opaque ticket_nonce<0..255>;
    opaque ticket<1..2^16-1>; // opaque blob (encrypted by server)
    Extension extensions<0..2^16-2>;
} NewSessionTicket;

The PSK value derived from the ticket:

PSK = HKDF-Expand-Label(resumption_master_secret, "resumption",
                          ticket_nonce, Hash.length)

PSK Handshake Modes

PSK-only (psk_ke):

• No new ECDHE exchange
• Fast but no forward secrecy for this session
• If PSK is compromised, all data encrypted under it is exposed

PSK-with-DHE (psk_dhe_ke):

• PSK is used for identity, ECDHE is still performed
• Forward secrecy is maintained
• Slightly slower but strongly recommended

RFC 8446 recommends PSK-DHE. Always prefer it in your provisioning services.

Practice Exercise

# Connect twice; second connection should resume
openssl s_client -connect google.com:443 -reconnect 2>&1 | \
  grep -E "Reused|Session-ID|TLSv"

# With session caching explicitly
openssl s_client -connect google.com:443 -sess_out /tmp/session.pem
openssl s_client -connect google.com:443 -sess_in /tmp/session.pem \
  2>&1 | grep "Reused"

Challenge Assignment

Write a security analysis (1–2 pages) answering:

PSK-only vs PSK-DHE: when does the choice matter?

Cover:

1. What "forward secrecy" means precisely in each mode
2. A concrete attack scenario where PSK-only is exploitable but PSK-DHE is not
3. In the context of a certificate provisioning service:
   • Should the service's clients use session resumption at all?
   • If so, which mode, and why?
   • What is the maximum ticket_lifetime you'd recommend, and why?

Resources

• RFC 8446 §2.2: Resumption and Pre-Shared Keys
• RFC 8446 §4.2.11: pre_shared_key extension
• RFC 8446 §4.6.1: NewSessionTicket message
• RFC 8446 §C.4: Implementation notes on 0-RTT (preview for Day 13)