12. Session Resumption

PALISADE supports session resumption using short-lived, single-use resumption tickets. Resumption allows a client to establish a new session with reduced latency while preserving post-quantum security properties, forward secrecy, and replay protection.

Session resumption in PALISADE uses a fresh post-quantum key exchange and does not reuse traffic keys from a previous session.

12.1 Resumption Overview

A resumption attempt consists of:

• Presentation of a server-issued resumption ticket
• A fresh post-quantum KEM exchange
• Derivation of new session keys bound to the resumption transcript
• Optional transmission of 0-RTT early data, subject to strict restrictions

Resumption does not eliminate the cryptographic handshake; it reduces latency by avoiding certificate exchange and long-term authentication.

12.2 Resumption Ticket Semantics

A resumption ticket is an opaque, server-generated authorization artifact that enables a client to resume a previous session.

Each ticket is bound to:

• A specific server
• A specific prior session
• A finite validity interval
• A single permitted use

Tickets MUST be treated as bearer credentials and MUST be protected against replay.

12.3 Ticket Confidentiality and Authenticity

The server MUST ensure the following properties for all issued tickets:

• Confidentiality: Ticket contents are encrypted using AEAD with a server-controlled secret.
• Integrity: Ticket contents are authenticated and tamper-evident.
• Authenticity: Tickets are cryptographically bound to the issuing server.

Clients treat tickets as opaque byte strings and MUST NOT attempt to interpret or modify their contents.

12.4 ClientHelloResume

To initiate resumption, the client sends a ClientHelloResume message containing:

• The resumption ticket
• A fresh ephemeral KEM public key
• A fresh resumption nonce
• An indication of whether early data is offered

ClientHelloResume messages are cryptographically bound into the resumption handshake transcript.

Client authentication via certificate is not required during resumption. Possession of a valid resumption ticket serves as proof of authorization.

12.5 Server Validation of Resumption

Upon receipt of a ClientHelloResume, the server MUST:

• Verify the authenticity and integrity of the resumption ticket.
• Decrypt the ticket contents using the appropriate server secret.
• Verify that the ticket has not expired.
• Enforce single-use semantics by rejecting tickets that have already been used.
• Determine whether early data is permitted under server policy.

Atomic Ticket Validation: Ticket validation and 'mark used' MUST be performed atomically with respect to replay detection. If a ticket is detected as replayed, the server MUST discard any buffered early data associated with that ticket and MUST NOT set accept_0rtt=1.

Implementation Note: Non-atomic implementations allow race conditions where two threads both validate a ticket before either marks it used, resulting in early data replay.

If any validation step fails, the server MUST reject resumption and fall back to a full handshake or abort the connection.

12.6 Resumption Key Establishment

Resumed sessions derive fresh traffic keys using:

• The pre-shared secret embedded in the resumption ticket
• A fresh post-quantum KEM shared secret
• Fresh nonces contributed by both endpoints
• The resumption handshake transcript

Key derivation MUST use the same key schedule structure defined in Section 6, with explicit domain separation between full handshakes and resumption handshakes.

Derived keys MUST NOT be cryptographically related to keys from the original session beyond the resumption PSK input.

12.7 ServerHelloResume

If resumption is accepted, the server responds with a ServerHelloResume message containing:

• A server nonce
• Fresh ephemeral KEM material
• An explicit indication of whether early data is accepted
• A digital signature over the resumption handshake transcript

The server signature authenticates the resumption handshake and binds all negotiated parameters.

12.8 0-RTT Early Data (Normative)

If permitted by the resumption ticket and server policy, a client MAY transmit early data frames (0-RTT) prior to completion of the resumption handshake.

Critical Restriction: Early data is permitted only for a strict allowlist of early-safe control frames. No application data is permitted in 0-RTT.

Early data MUST satisfy the following properties:

• Early data MUST be encrypted using keys derived exclusively for early data.
• Early-data keys MUST be cryptographically independent from all application traffic keys.
• Early data MUST be treated as replayable by both endpoints.
• Early data MUST NOT be required for protocol correctness.
• Early data MUST be non-authoritative: it MUST NOT directly cause durable protocol state transitions (including migration commits, epoch transitions, replay-window updates for non-early epochs, or session binding updates).

Permitted Early Data Frames: Early data MUST contain only the following frame types: {KEEPALIVE0, RESUME_INTENT}. All other frame types in early data MUST be silently ignored.

Migration Prohibition: CTRL_MIGRATE and related migration frames MUST NOT be accepted in early data. Migration frames received with epoch_id=0xFFFFFFFF MUST be ignored. See Section 13 for migration semantics.

Rationale: Migration causes durable state changes (path binding). Early data is replayable and must not cause durable state changes.

• KEEPALIVE0: Zero-payload keepalive for connection liveness
• RESUME_INTENT: Signals resumption attempt without state changes

Rationale: Allowlist approach prevents 'encrypted so it must be safe' feature creep. Only frames proven safe under replay are permitted.

Prohibited Effects:

• PROHIBITED: Early data causing epoch advancement
• PROHIBITED: Early data updating primary path binding
• PROHIBITED: Early data modifying replay windows for epochs other than 0xFFFFFFFF

Permitted Effects:

• PERMITTED: Early data updating last-seen timestamp (non-durable)
• PERMITTED: Early data being logged/metered (observational)

Epoch Field Prohibition: Early data MUST NOT contain any field that advertises or implies epoch advancement. Frames containing epoch hints (e.g., peer_epoch_observed) are prohibited in early data.

Rationale: Epoch hints under replay become epoch steering vectors. Banning them from early data eliminates this attack class.

Reserved Epoch Identifier

Early data packets MUST use a reserved epoch identifier:

epoch_id = 0xFFFFFFFF

The value 0xFFFFFFFF is RESERVED exclusively for early data and:

• MUST NOT be used for normal application traffic.
• MUST NOT be used after resumption handshake completion.
• MUST be rejected if received outside the early-data phase.

Early data MUST NOT advance the normal epoch counter.

Sequence Number Rules

• Early-data packets MUST use seq ≥ 1.
• Sequence numbers MUST be strictly monotonic within early data (sender invariant).
• Receivers MUST tolerate reordering of early-data packets; sequence monotonicity is a sender invariant, not an in-order delivery requirement.
• The tuple (epoch_id=0xFFFFFFFF, seq) MUST NOT be reused.
• Early-data sequence numbers are independent from application-data sequence numbers.

Rationale: Network reordering is common. Rejecting legitimate reordered packets creates a fragile DoS vector.

key_phase Restriction: key_phase=1 on early-data packets (epoch_id=0xFFFFFFFF) is invalid and MUST be rejected.

Rationale: Early data has a single key context; key_phase selection is not applicable. Rejecting key_phase=1 prevents confusion and potential implementation bugs.

12.9 Early Data Restrictions (Normative)

Early data is subject to the following MANDATORY restrictions:

• Early data MUST NOT perform non-idempotent operations.
• Early data MUST NOT perform security-sensitive operations.
• Early data MUST NOT modify authentication or authorization state.
• Early data MUST be safe to replay without causing harm.

Examples of PROHIBITED early-data operations include (non-exhaustive):

• State-changing writes
• Resource creation or deletion
• Credential updates
• Authorization changes
• Financial or irreversible actions

Servers MUST enforce the maximum early-data size encoded in the resumption ticket and MUST ignore any client-offered value.

If early data is rejected, the server MUST discard it without side effects.

12.10 Early Data Acceptance and Replay Protection (Normative)

Ticket Replay Protection

Servers MUST implement replay protection for resumption tickets.

Replay protection MUST ensure:

• Each ticket is accepted at most once.
• Replayed tickets are reliably detected and rejected.
• Replay tracking persists for a bounded duration sufficient to cover the ticket's validity window.
• Replay protection mechanisms are time-bounded and MUST NOT grow without limit.

Atomic Ticket Validation: Ticket validation and 'mark used' MUST be performed atomically with respect to replay detection. If a ticket is detected as replayed, the server MUST discard any buffered early data associated with that ticket and MUST NOT set accept_0rtt=1.

Implementation Note: Non-atomic implementations allow race conditions where two threads both validate a ticket before either marks it used, resulting in early data replay.

Early Data Handling Semantics

Servers MAY receive and cryptographically process early-data packets before resumption handshake completion.

However:

• Servers MUST NOT deliver early data to the application until:
  • The resumption ticket is validated and marked used, and
  • The server sends ServerHelloResume with accept_0rtt = 1.
• If accept_0rtt = 0:
  • All buffered early data MUST be discarded.
  • No side effects MUST occur.

Early-Data Replay Window

• Early data MUST be protected by a replay window keyed to (epoch_id=0xFFFFFFFF, seq).
• This replay window MUST be independent from application-data replay windows.
• Upon completion of resumption, the early-data replay window MUST be discarded.
• Early data MUST NOT affect replay protection for application traffic.

12.11 Domain Separation (Normative)

All cryptographic derivations performed during resumption MUST use explicit domain separation distinct from full handshakes.

Domain separation MUST ensure:

• Resumption keys cannot be confused with full-handshake keys.
• Early-data keys cannot be substituted for application-data keys.
• PALISADE keys cannot be reused in other protocols.
• Cryptographic contexts remain isolated across:
  • full handshakes,
  • resumptions,
  • early data,
  • ticket encryption.

Domain separation labels MUST be protocol-specific, version-specific, and context-specific.

12.12 Security Properties

The resumption mechanism provides the following guarantees:

• Post-Quantum Security: All cryptographic operations rely on post-quantum primitives.
• Forward Secrecy: Each resumed session derives fresh traffic keys.
• Replay Resistance: Tickets are single-use and replay-protected.
• Transcript Binding: All keys and signatures are bound to the resumption transcript.
• Controlled Risk Exposure: Early data risks are explicitly constrained and minimized.