Post-Quantum Secure Transport (PQST)

1.1. The Problem

Mobile and edge devices change networks constantly: wireless to cellular, address translation rebinding, gateway failover, coverage gaps, and outright disconnection in denied, degraded, intermittent and limited-bandwidth environments. The secure transports in use today accommodate part of this, each by its own mechanism. QUIC keeps a connection across a change of address or port by its connection identifiers, may hold the connection while no validated path exists, and lets both endpoints disable the idle timeout that would otherwise end it (Sections 9 and 10.1 of [RFC9000]); a connection that did end is replaced by a new one, with or without resumption. IKEv2 with MOBIKE moves a security association to new addresses ([RFC4555]); whether an association outlives a period with no path is a liveness decision the implementation makes ([RFC7296]), and an association that was deleted can be resumed from a ticket, as a new IKE SA ([RFC5723]). WireGuard keeps a configured peer, its static key and its allowed addresses, across any change of that peer's address, and replaces short-lived traffic keys underneath that relationship by a handshake it repeats as needed [WireGuard]. These mechanisms accomplish precisely what they were built for.¶

The problem that PQST engages begins where the live cryptographic and transport state is gone. After a process restart, after a dormancy long enough that keeping the state was not worth its cost, or when another endpoint instance, a second gateway, must take the session up. Existing deployments answer with application-level continuity, session resumption, re-authentication of the peer or reconstruction of the association, each with its own state, cost and semantics, and none of it defined as the transport's own behaviour.¶

PQST defines the logical session independently of its paths and of its live key state: a continuity record keeps what a fresh post-quantum re-anchor needs, so that the session identifier, the authorization it holds and the bindings above it survive the loss of everything else, and the recovery, persistence, erasure and failure behaviour of that mechanism are specified rather than left to the deployment.¶

On constrained links the cost of recovery is bytes, round trips, retransmissions and the cryptographic work of restoring authorization, paid at the worst possible moment. PQST is designed to make that cost small relative to rebuilding the equivalent session state. How small is a property of an implementation under a given network and security configuration; it is measured, not asserted (Section 27).¶

1.2. The Thesis

PQST inverts the layering: identity, then cryptographic session, then current network path. The session is the primary, long-lived object. Paths attach to it, detach from it, and may disappear entirely while the session stays meaningful. Recovery re-establishes a path and fresh key material and keeps the session: while the continuity record is recoverable and authorization permits, a re-anchor creates the next generation of the session's secrets without replacing the session identifier or anything bound to it, and when it cannot, the session is replaced by a new FRESH exchange, as Section 16.10 states. The falsifiable form of the claim is the first sentence of the Abstract, and the protocol is justified only if that sentence holds and the protocol is self-contained and post-quantum from the ground up.¶

Five consequences follow and organise this document:¶

1. Everything above the path is owned by the session (Section 3). A path event, by itself, changes neither the authenticated identity, nor the committed generation, nor authorization or upper-layer bindings; it selects which path the session uses. Losing every path starts a transition of the session's own, RECOVERING and then DORMANT, which discards live keys, identifiers and replay windows as Section 12 and Section 16 require and keeps the continuity state a re-anchor needs; a session with zero paths is a defined state, not an error.¶

2. One exchange establishes and recovers (Section 9). Performed from nothing it is the handshake; performed from an existing session it is a re-anchor, which creates the next generation of the session's secrets from the previous one plus a fresh post-quantum secret. Re-anchor is the one mechanism for recovery after path loss, survival across a restart, the post-compromise ratchet, identity re-proof, identifier renewal and lineage renewal. With a prekey exchanged in advance it costs no round trip.¶

3. Identity is a KEM key (Section 6 and Section 9). Long-term identities are ML-KEM-1024 keys and a peer proves its identity by decapsulating. No signature is computed online in any exchange; ML-DSA-87 certifies identity keys offline where a deployment needs that.¶

4. Nothing unauthenticated changes authoritative state (Sections 11 to 14). The epoch and sequence number travel header-protected inside the routing slot, a receiver performs at most one AEAD operation per packet, replay and epoch state move only after that operation succeeds, and no error is ever signalled to an unauthenticated sender. What an unauthenticated datagram may cause before that is bounded and named: reassembly state within fixed limits, one cached key derivation, and three answers that repeat or commit nothing.¶

5. Nothing is signalled that can be derived (Section 8, Section 15 and Section 19). Packet identifiers, recovery identifiers and epoch keys are derived by both endpoints; what must be delivered is a small set of versioned state objects with one reliability rule.¶

1.3. What PQST Is and Is Not

PQST carries datagrams, typically IP packets, between two authenticated endpoints over UDP, with confidentiality, integrity, replay protection, and forward secrecy and post-compromise security at the granularity of its re-anchors, against adversaries with quantum computers: a generation's epochs share one lineage secret, and session-scoped exporter material lasts the session (Section 23.1). It is a self-contained secure datagram encapsulation and session-management protocol: handshake, data plane, key management, path management, recovery and authorization are one protocol with one state machine (Section 18). It provides neither reliable delivery nor congestion control: the traffic it carries brings its own, and the UDP guidelines of [RFC8085] apply to the application and the deployment. It assumes nothing from below but datagram delivery, and nothing from the deployment but that each endpoint holds its own identity key and knows the identity key of the peers it talks to, which is the deployment model of WireGuard. It needs no public key infrastructure, no load balancer that understands it, no ticket store, and no synchronised clock beyond the loose agreement a gateway group's sealed records need (Section 16.6.3).¶

PQST is not a traffic-analysis countermeasure beyond hiding header contents and permitting padding and dummy packets. It is not a group protocol: it is the pairwise substrate on which one can be built, and it reserves what such a layer needs (Section 3.9 and Section 26); the cohort layer built on it is specified in a companion Experimental document [PQST-COHORT]. Unlike MLS and IPsec, a removal from a cohort closes that member's sessions with the sequencer and not its pairwise sessions with other members, and a re-anchor, a restart or a path change of a session advances no membership epoch.¶

1.4. Relationship to Existing Work

Many of PQST's components are, deliberately, not new; its contribution is a transport in which the same KEM identity establishes, recovers and re-proves a session that the network path cannot end.¶

• The handshake is the KEM instantiation of the Noise IK pattern [Noise], as in PQ-WireGuard [PQWireGuard] and Rosenpass [Rosenpass], and shares its properties with KEMTLS [KEMTLS] and the AuthKEM proposal for TLS 1.3 [AuthKEM]. PQST differs in using the pattern for recovery as well as establishment, and in carrying an identity re-proof inside recovery.¶

• Header protection by an AES mask over a ciphertext sample is QUIC's ([RFC9001]). PQST protects the full epoch and sequence number rather than a truncated packet number and a key-phase bit, and needs no packet-number reconstruction.¶

• Zero-round-trip recovery with single-use prekeys descends from X3DH [X3DH] and PQXDH [PQXDH]. PQST exchanges the prekeys inside the session and uses them for transport recovery, which makes the recovery forward-secret and, toward a stateful receiver, not replayable by anyone else, two properties TLS early data lacks; what became of early data whose attempt a gateway group answered with a RETRY is unknown to its sender, and an application that sends it again accepts that it may arrive twice (Section 16.3.2 and Section 23).¶

• Identity and locator separation recalls HIP ([RFC7401]), and QUIC preserves a connection's identity across address changes by its connection identifiers ([RFC9000]). PQST builds on the same separation and adds what neither specifies: a durable continuity record and a cryptographic re-anchor that recover a logical session after its live state has been discarded, with authorization and exporter values owned by that session. The closest prior art for the record is IKEv2 session resumption ([RFC5723]), a ticket from which a deleted association is resumed as a new IKE SA (Section 1.1), where PQST's record restores the same session, its identifier, grants and exporter values with it. These are protocol mechanisms; an application or session layer above another transport could implement their like, at its own cost in state and coordination.¶

• Post-quantum key agreement is standardized for TLS 1.3 ([RFC10024]) and for IKEv2 ([RFC9370]). PQST is not distinguished by using a post-quantum KEM but by using KEM identities and fresh post-quantum contributions throughout establishment, continuity, re-proof and recovery, with no signature online; the relative cost depends on the authentication profile and on the recovery operation compared.¶

• MASQUE proxies UDP and IP through HTTP/3 and QUIC ([RFC9298], [RFC9484]), and a session layer above it could keep its own identity, authorization and continuity state across connections. It is the architectural alternative to a new transport: mature HTTP infrastructure, proxy traversal and congestion control on one side; a compact purpose-built protocol, direct control of cryptographic recovery, fewer layers to coordinate and a state model built for severe intermittency on the other. Nothing here makes either impossible; the question is which is simpler, cheaper and more predictable for the environments of Section 1.1, and PQST can itself be carried through such a proxy where direct connectivity is absent.¶

• Group continuity above PQST relates to MLS ([RFC9420]), GDOI and sender-key designs; PQST contributes the transport-aware part they lack and is positioned against them in the companion document [PQST-COHORT].¶

The comparison, scenario by scenario, as the mechanisms stand:¶

• address or port change while live. QUIC: supported; WireGuard: roaming supported; IKEv2 with MOBIKE: supported; PQST: supported¶

• a period with no path. QUIC: the connection may be retained; WireGuard: the peer persists; traffic keys expire; IKEv2 with MOBIKE: the association may be retained, by liveness policy; PQST: RECOVERING, then DORMANT, both specified¶

• process restart. QUIC: not resumed as the same connection; WireGuard: the peer persists; a new handshake; IKEv2 with MOBIKE: the association re-established, or resumed from a ticket; PQST: re-anchored from the continuity record¶

• the same cryptographic session identity after a restart. QUIC: not a base guarantee; WireGuard: not its abstraction; IKEv2 with MOBIKE: not a general guarantee; PQST: a design objective, within the limits of Section 16.10¶

• post-quantum key establishment. QUIC: through TLS ([RFC10024]); WireGuard: not in the baseline; IKEv2 with MOBIKE: [RFC9370]; PQST: native ML-KEM¶

• authorization carried by the transport. QUIC: the application's; WireGuard: the peer configuration; IKEv2 with MOBIKE: IPsec policy; PQST: session-owned grants¶

Where another row reads "supported" or "may be retained", the other protocol has it and PQST claims no novelty; the rows that distinguish PQST are the ones its remaining sections specify and Section 27 measures.¶

1.5. Applicability

These statements bound what this document claims.¶

• PQST starts every path at a 1,200-octet datagram MTU and searches only upward from it (Section 15.5). A path with a smaller datagram budget is served by configuring a lower start, not below 576 octets, for the endpoints that use it; PQST does not discover such a budget by itself, and a deployment on such paths tests one.¶

• PQST gathers no candidate addresses and traverses no NAT. An address learned elsewhere, from the host, from discovery or from another session, is a hint; validation is still the probe of Section 15, and a peer behind an address translator that no probe reaches is not reached.¶

• Authorization of a session's own traffic is this document's: the grants of Section 17, which Section 5.2 requires. Membership is not: it belongs to the deployment and to the companion document [PQST-COHORT], which specifies the properties of the authority a cohort needs and does not include one.¶

• No UDP port is assigned or requested (Section 25). A deployment configures the port its endpoints listen on as it provisions their identities and addresses; two endpoints that have not agreed one cannot reach each other.¶

• The continuity claim holds while the continuity record is recoverable and the recovery of Section 16 completes as a re-anchor. When a recovery FRESH wins the race of Section 16.10, as it often does on a very slow, lossy link, the session comes back as a new session with the same peer: the layer above sees the old session closed with SUPERSEDED and the new one established, rather than a transition of one session.¶

• A conforming endpoint keeps its continuity record in storage that is durable, replaced atomically and protected as Section 16.6.2 requires, and writes it before the transmissions that depend on it (Section 16.4). That is an applicability boundary, stated in terms of those guarantees and not of a file system: an endpoint whose storage gives none of them, or gives durability without atomic replacement or protection, as some browser and constrained environments do, is outside this document except as a responder serving from sealed records (Section 16.6.3), whose state its peers carry for it.¶

1.6. Structure of This Document

Sections 2 to 5 define terms, the architecture, the threat model and conformance. Sections 6 to 8 define algorithms, encoding and the key schedule. Section 9 defines the anchor exchange. Sections 10 to 14 define the data plane: packet format, receiver processing, nonces, replay protection and epochs. Sections 15 to 17 define paths, dormancy and re-anchor, and authorization. Section 18 is the state machine; Section 19 the control frames and state objects; Section 20 error handling. Sections 21 to 25 cover extensibility, invariants, security, privacy and registries, and Section 26 points to the cohort layer of the companion document. The appendices give the identity binding statement, replay-window pseudocode, an informative signature-based profile, and test vectors.¶

2.1. Roles

Endpoint. A participant in a PQST session.¶

Grantor, grantee, issuer, holder. The endpoint that issues a grant or a state object, and the endpoint that receives it.¶

Initiator, responder. The session roles, fixed for the session's life: the initiator is the endpoint that sent the FRESH request that created the session. They name the traffic directions i2r (initiator to responder) and r2i. After establishment the roles are symmetric: either endpoint may advance an epoch, open a path, re-anchor, issue objects and close.¶

Requester, responder of an exchange. The roles within one anchor exchange. In the FRESH and DISCOVER forms the requester becomes the session's initiator; in the CONTINUE forms either session role may be the requester.¶

2.2. Objects

Continuity record. What an endpoint retains while DORMANT or across a restart.¶

Continuity secret. The session's root secret for a generation, from which everything of that generation is derived and which is the salt of the next.¶

Epoch. One set of traffic keys within a lineage, identified by epoch_id = lineage_gen || epoch_index. In this document, bare "epoch" always means the PQST epoch.¶

Fleet secret. An optional pre-shared secret among endpoints of one deployment, used for pre-authentication and as a hedge in the key schedule.¶

Generation. One continuity secret cs(g), numbered from 0. Each anchor exchange creates a generation.¶

Grant. The AUTHZ state object by which one endpoint authorizes the other's traffic, with its own lifetime.¶

Identifier (RID). The eight-octet routing key of a protected packet, derived by both endpoints from the lineage secret and prefixed by the receiver.¶

Identity. A long-term key pair of the suite's KEM (ML-KEM-1024 in suite 0x0001, Section 6) that authenticates an endpoint. Its fingerprint is the SHA-384 hash of the encapsulation key.¶

Lineage. The epochs under one generation. lineage_gen in the epoch identifier is the generation number.¶

Path. A pair of addresses currently carrying a session's packets; CANDIDATE until validated, VALIDATED after, LOST when liveness fails.¶

Path set. The paths a session holds; empty when DORMANT.¶

Prefix. The zero-to-two-octet value a receiver places at the front of identifiers it receives on.¶

Prekey. A single-use encapsulation key of the suite's KEM one endpoint issues to the other so that a later re-anchor needs no round trip.¶

Recovery identifier. The routing key of a re-anchor request, derived from the continuity secret.¶

Sealed record. A copy of a responder's record, sealed under its own key and held by the peer.¶

Session. The persistent cryptographic association between two identities. It owns generations, epochs, replay state, grants, exporter values and inner addressing, and it holds zero or more paths. It is named internally by its session identifier, an exporter value that never appears on the wire.¶

State object. A versioned value one endpoint owns and the other holds a copy of, delivered by OBJECT frames.¶

Tombstone. What a closed session leaves behind to answer a late re-anchor request.¶

2.3. Exchanges and States

Anchor exchange. The two-message exchange of Section 9 that creates a generation.¶

Commit. The point at which a new generation becomes the session's current one and the previous generation's secret is erased.¶

DISCOVER. The optional preliminary exchange that delivers a responder's identity key.¶

DORMANT. The session state with no usable path and no recovery attempt under way, in which only the continuity record is retained.¶

ESTABLISHED. A committed generation and at least one usable path.¶

Epoch advance. Moving to the next epoch within a lineage by key chaining, signalled only by the epoch field of the next packet.¶

Event class. Transport-class events change nothing above the session; security-class events may require a layer above to act (Section 3.7).¶

Handshake. The anchor exchange in its FRESH form, which creates a session.¶

Re-anchor. The anchor exchange in a CONTINUE form, which creates the next generation of an existing session.¶

RECOVERING. The session state with no usable path and recovery attempts under way, in which all state is retained.¶

2.4. The Persistence Hierarchy

Five levels, each outliving the next: identity, cohort membership, session, generation and epoch, path. The persistence rule is that an event at a shorter-lived level never invalidates state at a longer-lived level (Section 3.2). Cohort, cohort epoch and member are reserved terms for the group layer defined outside this document; a cohort epoch is never a PQST epoch.¶

2.5. Notation

|| is concatenation. XOR is bitwise exclusive-or. H() is SHA-384. Extract and Expand are HKDF's functions with HMAC-SHA-384. label(X) is the octet string "PQST " followed by X. Encap(pk) returns (ct, ss); Decap(ct) returns ss. x(n) in a field list means a field of n octets; NOCTET in a structure definition means N octets; *OCTET means a variable number. Integers are big-endian and fixed-width. Bit 0 of an octet is its least significant bit. [x] marks a field present only when stated.¶

Identifiers in code and on the wire carry their layer: session_id, lineage_gen, epoch_id, path_id, rid, cohort_id, cohort_epoch. "Connection", "tunnel" (except for the inner IP tunnel), "client" and "server" are not used in normative text.¶

3.1. The Inversion

path-bound (incumbents)      session-primary (PQST)

  PATH                         IDENTITY
   +- CONNECTION                  +- SESSION
        +- SECURITY                    +- generations and epochs
                                       +- replay state
                                       +- grants
                                       +- exporter values
                                       +- inner addressing
                                       +- PATH SET {P1, ..., Pn}
                                          (n = 0 is DORMANT)

A session is created by an anchor exchange between two identities and ended only by a close. Paths are carriers; a session may hold any number, change any of them, or hold none. All state that PQST exposes to higher layers belongs to the session rather than to any particular path, and the session is reachable through whichever paths are available.¶

3.2. The Persistence Hierarchy and the Persistence Rule

The persistence rule. An event that originates at a shorter-lived level MUST NOT invalidate state at any longer-lived level. Invalidation cascades downward only.¶

• Losing a path does not end an epoch, a generation or the session; a re-anchor does not touch the session's identity, grants or exporter values; a session's end does not end cohort membership; none of these change an identity.¶

• Revoking an identity ends its memberships, sessions, generations and paths; closing a session erases its generations and releases its paths; retiring a generation discards its epochs.¶

• Each level's own state changes only through that level's events or a cascade from above. That is the testable form, and Section 22 lists it as an invariant.¶

Durable state above the session is keyed on the peer's identity, not on the session: a session may be superseded by another with the same peer (Section 9.6 and Section 16.7), and a layer above correlates through the fingerprint that every Established event carries.¶

3.3. The Object Model

3.4. The Ownership Rule

Everything above the path is owned by the session. No path event can, by itself, create, modify or destroy session-owned state; a path event can only select which path the session uses, and change the path set, including the previously validated addresses the record carries. The transitions that prolonged path loss causes, RECOVERING and DORMANT (Section 16.7), are the session's own: they discard live generation state as Section 12 and Section 16 require and keep the continuity and authorization state a re-anchor needs. Session-owned state changes only through cryptographic events (epoch advance, anchor exchange), policy events (grant versions, revocation, close) and the objects an endpoint issues. Replay windows and keys belong to the session and are shared by all paths; a path change never creates, resets or modifies a window. The budget toward an unvalidated address is the endpoint's, per remote address, shared by every session and path toward it (Section 15.4).¶

3.5. Lifecycle

A session is HALF_OPEN while its first exchange is in progress, ESTABLISHED while it has a committed generation and at least one usable path, RECOVERING while it has no usable path and is attempting to re-anchor with all its state retained, DORMANT while it has no usable path and retains only its continuity record, and CLOSED when ended. Section 18 is the authoritative transition table. DORMANT is the concrete form of "the path can disappear": other transports can hold a connection while no path exists (Section 1.1); what PQST specifies is exactly what is retained in that state, the continuity record and nothing else, and how the session returns from it.¶

3.6. Operations and What They Touch

• epoch advance (Section 14). Epoch and replay: new epoch, new window, same lineage¶

• opening a path, migration (Section 15). Paths: new path, new identifier index¶

• NAT rebind. Paths: address updated after validation, same identifier¶

• entering DORMANT. Generation: retained in the record; Epoch and replay: discarded; Grants: retained; Paths: none¶

• re-anchor (Section 16). Identity: re-proved if the policy asks; Session: same session; Generation: new generation; previous erased on commit; Epoch and replay: new lineage; Grants: unchanged, never extended; Paths: kept if the address is unchanged¶

• restart. Session: restored from the record; Generation: new generation by re-anchor; Epoch and replay: never resumed; Grants: held grant treated as expired until refreshed; Paths: new¶

• scheduled re-anchor (Section 16.8). Generation: new generation; post-compromise ratchet; Epoch and replay: new lineage; Paths: kept¶

• grant version, revocation (Section 17). Grants: changed¶

• close (Section 20). Session: ended; Generation: erased; Epoch and replay: erased; Grants: ended; Paths: released¶

3.7. Events and Their Classes

An endpoint reports the events of Section 18.5 to the layer above it; that table, rendered from the state table, is the inventory of the events and their classes, and this section summarises it. The classes are normative:¶

• Transport-class events (Established, PathAdded, PathChanged, PathLost, EpochAdvanced, ReAnchored, Recovering, Dormant{announced}, and the local reports EarlyDataUncertain{reason}, ReanchorFailed, OpenFailed, Discovered and DiscoverFailed) change no state above the session: none of them, by itself, touches the session's authenticated identity, its grants, its exporter values or the bindings a layer above keeps. A layer above MAY use them for connectivity, recovery and delivery-status decisions, as EarlyDataUncertain{reason} (Section 16.3.2) informs the retry of an operation that must not run twice; it MUST NOT read one as a security-class event, and MUST NOT read one as proof that data was not delivered unless the event's own definition says so.¶

• Security-class events (Closed{reason}, AuthzExpired, AuthzRevoked, ReproofFailed, and GrantHeld and CertReceived, which report new authorization or identity evidence held) are the only events after which a layer above may need to act on its own state.¶

• Data events (Delivered{stream_id}, ObjectHeld{kind}, InnerAddr) deliver application data, held objects and inner addresses after authentication, replay commit and the grant check.¶

No transport event closes a session; there is no transport class of close reason (Section 20.2). This split is what enables a group layer to mechanically apply its own continuity rule. A member's transport events never reach the group, only its security events do.¶

3.8. Symmetry, Multiplexing and Capacity

After establishment the protocol is symmetric: every mechanism is written for either endpoint, and the only asymmetries are the names of the directions and two tie-break rules: by fingerprint before a session exists (Section 9.6.1) and by handshake role within one (Section 16.4). Any number of sessions, in either role, share one UDP port; the routing key is the only demultiplexer, and an endpoint that is responder in one session may be initiator in another on the same port. Per-session state is bounded by the inventory of Section 16.6 while DORMANT and by that plus per-generation, per-epoch and per-path state while active; the per-endpoint state that grows with the number of peers is the session table and, per peer identity, the freshness high-water mark and the half-open count of Section 9.4; what grows with the number of addresses heard from is bounded apart from the peers, the reflection budget table of Section 15.4 and the reassembly pools of Section 9.4, each with the bound its section states.¶

3.9. Composition Upward

PQST is written so that a group layer can be built on it without a wire change: reserved stream identifiers, frame types, object kinds, capability bits, close reasons and exporter labels (Section 25); an exporter at session and lineage scope (Section 8.6); events keyed on identity; symmetric roles; paths through forwarding members (Section 10.1.2); and a reserved packet type for a group-keyed packet, which an extension may define (Section 21.1). Section 26 lists the reservations, and the companion document [PQST-COHORT] specifies the cohort layer. The group layer, its membership state, its ordering of changes and its keys are outside this document. The only statement this document makes about it is the one its design enforces: a member's transport events never need to reach the group.¶

3.10. Design Principles

4.1. System Model

Two endpoints hold ML-KEM-1024 identity keys and each knows the other's, either by provisioning, pinning or the optional DISCOVER exchange followed by certification. They communicate over a network that provides datagram delivery and nothing else. Either may be mobile; either may be behind address translation; either may lose connectivity for hours and may restart. A responder may be one of a group of gateways sharing an identity (Section 16.9).¶

4.2. Adversaries

Network adversary. Observes, drops, delays, reorders, duplicates, injects and modifies any packet; spoofs addresses; manipulates routing and address translation; induces path changes. This is the full Dolev-Yao attacker and PQST assumes it everywhere.¶

Quantum-capable cryptographic adversary. Has a cryptographically relevant quantum computer and large classical resources. PQST assumes ML-KEM-1024 is IND-CCA2 secure, AES-256-GCM is a secure AEAD within the limits of Section 12.4, HKDF-SHA-384 is a pseudorandom function, and ML-DSA-87 is EUF-CMA secure where it is used offline, all against such an adversary.¶

Malicious authenticated peer. Holds a valid identity and a live session, and uses it against the other endpoint or third parties: claims addresses it does not hold to make the endpoint send there; re-anchors, migrates and probes at a rate meant to exhaust resources; replays its own traffic; sends ill-formed frames and objects; announces false suspension. PQST treats the authenticated peer as untrusted beyond its identity.¶

Holder of a storage image. Has a copy of an endpoint's persistent storage, including its continuity records, but not its hardware keystore.¶

Holder of a continuity secret. Has the current cs(g) of a session, by memory compromise, without the identity key.¶

Compromised gateway in a group. Holds the group's replicated identity key and sealing key.¶

Denial-of-service adversary. Sends at line rate: garbage, replayed handshakes, fragments, probes.¶

4.3. Security Goals

4.4. What Each Adversary Can and Cannot Do

• Network adversary: can deny service, observe the metadata of Section 24, and retransmit or reroute any packet; cannot read or forge traffic, cannot have a replayed packet delivered as fresh data (Section 13) or move a session to an address no probe has validated (Section 15), cannot end a session by any packet, cannot make an endpoint send to any address more than the reflection budget of Section 15.4 allows, what it received from that address beyond a floor of k_probe x 56 octets, and cannot learn the initiator's identity key or fingerprint from the handshake without the responder's identity secret (Section 9.8); it sees which network address initiated, and the protocol claims no anonymity against traffic analysis (Section 4.5).¶

• Malicious authenticated peer: can make the endpoint send toward a claimed address at most the reflection budget of Section 15.4, what it sent from that address beyond the probe floor; can cause at most the work the budgets of Section 9.4, Section 15.4 and Section 19.2 allow before it is rate-limited and closed (Section 20.3); cannot replay its own traffic past the window; cannot affect any other session; cannot exhaust identifiers; learns nothing of the endpoint's other peers from this protocol's messages or from the session state it is shown, timing and traffic analysis being outside scope (Section 4.5).¶

• Holder of a storage image: cannot recover any session or re-anchor as the endpoint if the identity key is in hardware (Section 16.6.2); otherwise holds the identity and is the endpoint.¶

• Holder of cs(g): can re-anchor as the endpoint until the re-proof deadline of Section 16.3.3 or the grant's expiry, and the ratchet heals the leak once the legitimate endpoint re-anchors first (Section 16.10). Cannot produce a transferable proof of anything.¶

• Compromised gateway: holds the group identity; this is the stated containment cost of session portability across a group (Section 16.9).¶

• Denial-of-service adversary: can prevent new sessions from being established at a saturated responder and can consume the receiver's per-packet budget; cannot modify established sessions, because recovery is authenticated symmetrically before any public key operation and reassembled in a pool of its own (Section 9.4); how fast their recovery proceeds under a flood is a capacity property of an implementation (Section 23).¶

4.5. Out of Scope

Compromise of an endpoint's memory beyond the bounds stated above; side channels below the protocol (power, electromagnetic, microarchitectural), beyond the constant-time requirements of Section 11.8; traffic analysis of packet sizes, timing and volumes beyond what padding and dummy packets allow a deployment to blunt; attacks on routing and name resolution; bandwidth exhaustion of a link; the correctness of the group layer above; the security of the provisioning channel that delivers identity keys and fleet secrets.¶

4.6. Summary

5.1. A Session's Life in One Page

1. Establishment. The initiator, holding the responder's identity key, sends a FRESH request: a fresh ephemeral ML-KEM-1024 key, an encapsulation to the responder's identity key, and, sealed under the resulting secret, its own identity, a freshness counter, its capabilities and its receive prefix. The responder decapsulates, checks the counter, encapsulates to the ephemeral key and to the initiator's identity key, derives generation 0, and answers with both ciphertexts and a sealed part carrying its capabilities, prefix and grant. The initiator derives generation 0 and sends its first protected packet, which authenticates it. One round trip to initiator data; about 3.3 KB each way; no signature (Section 9).¶

2. Data. Each protected packet carries a derived identifier as routing key, a header-protected block with the epoch and a 64-bit sequence number, and an AEAD-protected payload; 44 octets of overhead. The receiver looks up the identifier, unmasks, filters, performs one AEAD operation, and only then commits replay and epoch state (Sections 10 to 13).¶

3. Epochs. Either endpoint advances to the next epoch by naming it in a packet; the keys are chained; a successful AEAD under the next keys is the authentication of the advance. Nothing is negotiated and nothing is signalled (Section 14).¶

4. Paths. A packet from a new address on a new identifier index is a new path; the endpoint validates it with a probe, sending no more than it received until then. A session may hold several validated paths and send on any of them (Section 15).¶

5. Objects. Grants, prekeys, sealed records and inner addresses are versioned state objects, delivered by OBJECT frames and acknowledged by version (Section 19).¶

6. Dormancy. When every path is lost the session is RECOVERING with its state retained, and then DORMANT with only its continuity record. It is not closed; it is closed only by policy or by its peer (Section 16.7).¶

7. Re-anchor. The session's next generation is created by a CONTINUE request on the recovery identifier, authenticated under the current continuity secret, with a fresh KEM secret; with a prekey it carries data at zero round trips. The same exchange runs on a schedule as the post-compromise ratchet, after a restart, and whenever an identity proof is wanted (Section 9 and Section 16).¶

8. Close. A CLOSE frame with a classed reason; a tombstone answers late re-anchors (Section 19.6 and Section 20).¶

5.2. Conformance: PQST CORE

An implementation conforms to PQST CORE if it implements, as this document specifies:¶

• the suite of Section 6 and the key schedule of Section 8;¶

• the anchor exchange in its FRESH, CONTINUE and CONTINUE_0RTT forms, including RETRY, the freshness counter, the identifier window, fragmentation with parity recovery, and the reflection bound (Section 9 and Section 10.4);¶

• the packet format, receiver pipeline, nonce rules, replay protection and epoch advance of Sections 10 to 14, including the one-AEAD rule and the state-mutation rule;¶

• paths with validation, the byte-counted budget, active liveness, and the ability to hold and receive on several validated paths (Section 15);¶

• dormancy, recovery, the continuity record with its at-rest protection, write-ahead and commit rules, and the scheduled re-anchor (Section 16);¶

• grants in both directions (Section 17);¶

• the state machine of Section 18 with its event classes;¶

• the six frames and the NEXT_EK, AUTHZ and RECORD object kinds as holder, NEXT_EK and AUTHZ as issuer (Section 19);¶

• the close reasons and error principles of Section 20;¶

• the exporter (Section 8.6).¶

A conforming implementation MAY omit sending parity fragments, initiating MTU probing, issuing sealed records, and opening more than one path; it MUST handle each when the peer does it.¶

5.3. Optional Features

There is no second conformance tier. A feature is either part of CORE or optional and discoverable through capabilities or configuration; an implementation that does not implement an optional feature behaves as this document specifies for an absent capability.¶

5.4. Dependencies

A conforming endpoint needs UDP sockets, AES-256-GCM, AES-256 block encryption, HMAC-SHA-384, ML-KEM-1024 (key generation, encapsulation, decapsulation, and seeded key generation if it regenerates prekeys), a cryptographically secure random source, a monotonic clock, and persistent storage for the continuity record and the freshness state. It does not need ML-DSA-87 online, ASN.1 or X.509 parsing unless it verifies certificates, TLS, HTTP, a synchronised clock, a load balancer that understands the protocol, a ticket store, or negotiated parameters of any kind.¶

6.1. The Suite

PQST version 0x14 defines one suite, identifier 0x0001, aligned with CNSA 2.0:¶

Every function is at NIST security category 5 or the symmetric equivalent. The suite is implied by the identity key the requester encapsulates to and is bound into every transcript (Section 8.3); a future suite is a new identity key type and a new registry entry (Section 21).¶

Suite parameters. The wire formats are written with two lengths of the suite's key encapsulation mechanism: L_ek, the octets of an encapsulation key (identity keys, ephemeral keys and prekeys alike), and L_ct, the octets of a ciphertext. For suite 0x0001, ML-KEM-1024, both are 1568, and the figures and examples of this document use those values. Every other length, the AEAD, the hash and the key schedule are the same in every suite of this version; only L_ek, L_ct and the lengths derived from them change, which are DISCOVER's pad (L_ek + 16, Section 9.2.1), the bound of NEXT_EK (Section 19.4) and the key field of the binding statement (Appendix A). A suite whose KEM has other lengths, ML-KEM-768 (L_ek 1184, L_ct 1088, NIST security category 3) for deployments on constrained links being the expected one, is defined by its own document with its identifier, its values and its test vectors; it needs no change to this one, since the suite is implied by the identity key and bound into every transcript (Section 21.2). Every implementation of this version MUST support suite 0x0001.¶

6.2. ML-KEM-1024

• Identity keys. An identity is an ML-KEM-1024 key pair; the encapsulation key is 1,568 octets, the decapsulation key 3,168, and the fingerprint is H(encapsulation key). The decapsulation key SHOULD be held in a hardware keystore or equivalent; Section 16.6.2 depends on it.¶

• Ephemeral keys are generated per anchor attempt and the decapsulation key is erased when the attempt completes or is abandoned.¶

• Prekeys are generated per issuance; the decapsulation key is used exactly once and erased. An issuer MAY generate the pair from a 64-octet seed with the deterministic key generation of [FIPS203] (ML-KEM.KeyGen_internal(d, z) with d the seed's first 32 octets and z its last 32) so that only the seed, or the secret it derives from, need be stored (Section 16.3.2).¶

• Implicit rejection. Decapsulation of a malformed or mismatched ciphertext returns a pseudorandom secret and no error; PQST relies on this so that no decapsulation oracle exists (Section 9.3.2). Implementations MUST NOT short-circuit decapsulation on ciphertext validity checks in a way that is observable to the sender.¶

• Shared secrets are 32 octets and enter the key schedule only through Extract (Section 8.4).¶

6.3. AES-256-GCM

Keys are 32 octets, nonces 12, tags 16. Traffic nonces are the construction of Section 12.1 and are never reused under a key by the rules of Section 12. Sealing keys (Section 8.4) and record-wrapping keys (Section 8.7) carry their nonce in the derived 44 octets and are used for exactly one encryption. The per-key confidentiality limit is 2^23 packets (Section 12.4). The integrity limit of 2^52 forgery attempts is not approached because the pre-authentication filter rejects almost all forgeries before the AEAD (Section 11.3).¶

6.4. Header Protection

The mask is one raw AES-256 block encryption, under a 32-octet header-protection key, of the first 16 octets of the AEAD output (Section 10.3). The key is per generation and direction. This is the construction of Section 5.4.3 of [RFC9001] applied to a full 16-octet block.¶

6.5. HKDF and SHA-384

Extract(salt, ikm) = HMAC-SHA-384(salt, ikm); Expand(prk, info, L) as [RFC5869] with HMAC-SHA-384, producing at most 255 x 48 octets. Implementations MUST use HMAC, never a keyed hash substitute. Every derivation in this document uses a distinct label() and, where a transcript or index is relevant, includes it in info; Section 8 is exhaustive, and no other derivation from PQST secrets is permitted except through the exporter (Section 8.6). SHA-384 is used for transcripts, fingerprints and the pre-authentication tag.¶

6.6. ML-DSA-87, Offline Only

No PQST message carries a signature and no endpoint signs or verifies anything during an exchange. ML-DSA-87 certifies identity keys offline, in one of two formats delivered as a CERT object after establishment (Section 19.4.5) or out of band at provisioning:¶

1. the binding statement of Appendix A: an ML-KEM-1024 encapsulation key, a subject, validity, and an ML-DSA-87 signature by an issuer the relying endpoint trusts;¶

2. an X.509 certificate whose subject public key is an ML-KEM-1024 key, as profiled by the IETF LAMPS working group ([RFC9935] for the ML-KEM subject key, [RFC9881] for the signature algorithm), with an ML-DSA-87 signature.¶

Verifying either requires a clock for validity and trust anchors for the issuer, both of which are policy of the relying endpoint; CORE requires neither, because CORE trust is by provisioning or pinning (Section 9.1).¶

6.7. Randomness, Constant Time, and Hedges

• Every nonce, ephemeral key, prekey, handshake identifier, probe value and freshness counter contribution that this document calls random MUST come from a cryptographically secure random source. Padding octets need not (Section 10.2.2).¶

• Operations on secret key material MUST be constant-time with respect to the secrets (Section 11.8); the replay bitmap and the filter MUST NOT branch on key material.¶

• The optional fleet secret (Section 9.3.4) enters the continuity secret alongside the KEM secrets and is the only hedge CORE provides against a failure of the KEM; there is no classical key exchange and no classical fallback in the security-critical path.¶

6.8. Test Vectors

Appendix D gives test vectors for the key schedule, the mask, a protected packet, a FRESH exchange and a CONTINUE exchange. An implementation MUST reproduce them to claim conformance.¶

7.1. Rules

• All integers are unsigned, big-endian and fixed-width. There are no variable-length integers.¶

• Structures are the concatenation of their fields in the order written, with no alignment, padding or tags. A structure's encoding is therefore a function of its field values alone: the same values always produce the same octets, and parsing is a function of the octets and the lengths they carry.¶

• Variable-length fields are preceded by their length in a fixed-width field of the size stated; the length counts octets. A length that would extend beyond the enclosing structure, or beyond a bound this document states for the field, MUST cause the message to be dropped before any allocation sized by it.¶

• Where this document writes x(n), x is a field of exactly n octets; NOCTET in a definition means N octets; *OCTET means the number of octets the enclosing length implies; [x] means a field present only under the stated condition and otherwise absent entirely, not zero-filled.¶

• Bit 0 of an octet is its least significant bit. Reserved bits and octets MUST be zero when sent and MUST cause the packet or message to be dropped when non-zero, as each section states.¶

• Octet strings written as labels are UTF-8 with no terminator; label(X) is the string "PQST " (five octets, the last a space) followed by X. Labels whose X begins with "group " are reserved for the cohort layer (Section 26), so that no key it derives can coincide with one this document derives.¶

7.2. Structures Defined in This Document

7.3. Sealed Parts

A sealed part is AES-256-GCM output over a plaintext structure, under a 44-octet sealing key whose first 32 octets are the key and last 12 the nonce (Section 8.4), with the stated transcript hash as associated data. On the wire it is ciphertext || tag(16), and its length is the plaintext length plus 16; the enclosing message's msg_len bounds it. A sealed part is opened exactly once per message and never retried under another key, with one exception: a responder that holds two identity keys during a rotation opens a FRESH request whose rk_hint is 0 under each in turn (Section 9.3.2).¶

7.4. Transcript Inputs

Transcript hashes (Section 8.3) are computed over octets exactly as transmitted, in order: the whole cleartext of a message from msg_len to the last cleartext field, then the sealed part with its tag. Nothing is re-encoded, canonicalised or omitted. A receiver that reassembles a message from fragments hashes the reassembled message, not the fragments; fragment headers are not part of any transcript.¶

7.5. Parsing Discipline

A parser reads each field once, in order, checking each length against the remaining octets before using it. A message with octets remaining after its last field is malformed and MUST be dropped; a message shorter than its fixed fields likewise. These checks are pure functions of the octets and are performed before any cryptographic operation that the field would feed (Section 11.6). Parsers MUST be exercised against the negative test vectors of Appendix D.¶

8.1. Overview

anchor exchange for generation g
  ss_fresh, [ss_peer], [ss_req], [psk_cs]
      |
      v
  cs(g)        continuity secret of generation g; the salt of g + 1,
      |        erased on commit of g + 1
      +--> rec(g, dir)           recovery identifiers (16.2)
      +--> k_tomb(g) -> resp_rid(g, dir, nonce)
      |                          response routing keys (9.3.8) and
      |                          tombstone replies (19.6)
      +--> k_resp                this exchange's response (9)
      +--> k_retry               a RETRY to a request for g + 1
      +--> session_root          g = 0 only; kept for the session
      |
      v
  lineage_secret(g)
      +--> hp_i2r(g), hp_r2i(g)  header protection (10.3)
      +--> rid(g, dir, j)        packet identifiers (15.1)
      +--> Export(lineage, ...)  lineage-scope exporter (8.6)
      |
      v
  epoch_secret(g, 0) -> epoch_secret(g, 1) -> ...      (14.3)
      |
      v
  key_i2r, iv_i2r, key_r2i, iv_r2i, per epoch and direction (10.2.2)

A generation g is one continuity secret. Generation 0 is created by the handshake; each re-anchor creates generation g + 1 from generation g. A lineage is the set of epochs under one generation; lineage_gen in the epoch identifier (Section 12.2) is g.¶

8.2. Inputs

Shared secrets are concatenated in the order given. Both endpoints must agree on which optional inputs are present; the request's form and flags (Section 9.2) determine ss_peer and ss_req, and the fleet secret is configuration. A disagreement makes the sealed response unopenable, which is the failure mode intended.¶

8.3. Transcript

The transcript hashes bind each message of an anchor exchange into the key that seals it, and the request into the lineage and the session root; the continuity secret itself takes the shared secrets of the exchange and no transcript hash (Section 8.4). With RequestCleartext the octets of the request from msg_len up to but not including the sealed part, and ResponseCleartext likewise for the response:¶

th_0 = H(label("anchor") || version(1) || suite(2) || fp_peer(48))
th_1 = H(th_0 || RequestCleartext)
th_2 = H(th_1 || sealed_req || tag_req)   ; DISCOVER: th_2 = th_1
th_3 = H(th_2 || ResponseCleartext)
th_4 = H(th_3 || sealed_resp || tag_resp)

• version is the wire version (0x14). suite is the cipher suite identifier, 0x0001 for the suite of Section 6 (ML-KEM-1024, AES-256-GCM, HKDF-SHA-384); it is never transmitted, because the suite is implied by the identity key the requester encapsulates to (Section 21), and it is in the transcript so that a future suite cannot share keys with this one.¶

• fp_peer is the fingerprint H(peer_pk) of the peer identity key the requester encapsulates to, or intends to, in every form in which the requester knows it. In the DISCOVER form it is 48 zero octets.¶

• A FRESH exchange that follows a DISCOVER exchange carries the DISCOVER exchange's th_4 as the cleartext field prior of its request (Section 9.7), which therefore enters th_1 and everything derived after it.¶

th_4 is retained only until the next message is processed; the lineage is derived from th_2 so that a requester in the CONTINUE_0RTT form can derive it before the response exists (Section 8.5). The response is bound by k_resp, which is derived from th_3, and by the shared secrets it carries, which enter cs(g).¶

8.4. Continuity Secret and Sealing Keys

salt(0)   = label("cs")
salt(g)   = cs(g - 1)                     ; g >= 1
ikm(g)    = ss_fresh || [ss_peer] || [ss_req] || [psk_cs]
cs(g)     = Extract(salt(g), ikm(g))      ; 48 octets

; only when a fleet secret is configured (Section 9.3.4)
prk_fleet = Extract(label("fleet"), psk)
psk_cs    = Expand(prk_fleet, label("cs input"), 48)
k_pre     = Expand(prk_fleet, label("preauth"), 48)

; FRESH
k_req     = Expand(Extract(label("init"), ss_peer),
                   label("seal req") || th_1, 44)
; CONTINUE, CONTINUE_0RTT
k_req     = Expand(cs(g - 1), label("seal req") || th_1, 44)
; the DISCOVER response
k_disc    = Expand(Extract(label("discover"), ss_fresh),
                   label("seal disc") || th_3, 44)
k_resp    = Expand(cs(g), label("seal resp") || th_3, 44)
k_retry   = Expand(cs(g - 1), label("seal retry") || th_3, 44)

A 44-octet sealing key is an AES-256-GCM key (the first 32 octets) and nonce (the last 12). Each sealing key is derived from a transcript that includes a fresh nonce and is used for exactly one message, so the nonce is never reused. The associated data of a sealed request is th_1; of a sealed response, th_3.¶

8.5. Lineage, Epochs, Traffic Keys, Identifiers

lineage_secret(g) = Expand(cs(g),
                           label("lineage") || g(2) || th_2, 48)
session_root = Expand(cs(0), label("session root") || th_2, 48)
               ; at g = 0 only, and retained

hp_i2r(g) = Expand(lineage_secret(g), label("hp i2r"), 32)
hp_r2i(g) = Expand(lineage_secret(g), label("hp r2i"), 32)

; Section 14.3
epoch_secret(g, 0) = Expand(lineage_secret(g), label("epoch 0"), 48)
epoch_secret(g, k + 1) = Expand(epoch_secret(g, k),
                                label("epoch step"), 48)

key_i2r(g, k) = Expand(epoch_secret(g, k), label("key i2r"), 32)
iv_i2r(g, k)  = Expand(epoch_secret(g, k), label("iv i2r"), 12)
key_r2i(g, k) = Expand(epoch_secret(g, k), label("key r2i"), 32)
iv_r2i(g, k)  = Expand(epoch_secret(g, k), label("iv r2i"), 12)

rid(g, dir, j) = prefix(dir) ||
    Expand(lineage_secret(g), label("rid") || dir(1) || j(4),
           8 - len(prefix(dir)))
rec(g, dir) = prefix(dir) ||
    Expand(cs(g), label("recovery") || dir(1), 8 - len(prefix(dir)))
resp_rid(g, dir, nonce) = prefix(dir) ||
    Expand(k_tomb(g), label("response") || nonce(32),
           8 - len(prefix(dir)))

• dir is 0x00 for i2r and 0x01 for r2i. prefix(dir) is the zero-to-two-octet prefix chosen by the endpoint that receives packets in that direction and delivered in its sealed part of the FRESH exchange (Section 9.2); it is fixed for the session. j is the identifier index (Section 15.1).¶

• rid(g, dir, j) is the routing key of protected packets sent in direction dir under generation g on the path that was assigned index j. rec(g, dir) is the routing key of a re-anchor request sent in direction dir while generation g is current (Section 16.2). resp_rid(g, dir, nonce) is the routing key of the response to a re-anchor request whose cleartext nonce is nonce, sent in direction dir (the responder's direction) while generation g is current. It exists for that attempt only: the requester listens on it until the attempt ends, so a response to an attempt it has abandoned matches nothing and is dropped before any public key operation (Section 9.3.8). It is derived from k_tomb(g) (Section 8.7) rather than from cs(g) so that a tombstone, which holds k_tomb and not cs, can route its reply (Section 19.6). None of the three is ever transmitted other than in its role.¶

• resp_rid takes its direction only through prefix(dir): the nonce, fresh per attempt, already separates the keys of different attempts, and an endpoint never answers its own request.¶

• The traffic keys of Section 10.2.2 are key(direction, epoch_id) and iv(direction, epoch_id) with epoch_id = g || k.¶

• The keys of generation g are derivable only from cs(g) or lineage_secret(g); compromise of a later generation reveals nothing about an earlier one, because cs(g - 1) is erased on commit of g (Section 16.4) and Extract is one-way in its salt.¶

8.6. Exporter

Upper layers obtain keys bound to the session through the exporter and in no other way; PQST consumes no upper-layer keys.¶

Export(session, ulabel, context, L) =
    Expand(session_root, label("export session") || x, L)
Export(lineage, ulabel, context, L) =
    Expand(lineage_secret(g), label("export lineage") || x, L)

x = len(ulabel)(1) || ulabel || len(context)(2) || context

• Session scope is stable for the session's life, across every epoch and re-anchor, because session_root is derived once and retained (it is part of the continuity record, Section 16.6). Export(session, "session id", "", 16) is the session identifier, the handle by which upper layers and both endpoints name the session; it is never transmitted by PQST.¶

• Lineage scope changes at every re-anchor. It is for bindings that must be re-presented after recovery and that should not survive a compromise healed by a re-anchor.¶

• Compromise. A re-anchor changes the lineage-scoped root and not session_root: an adversary that obtains session_root, or the generation-0 secrets it derives from, keeps deriving session-scoped exports after every later re-anchor, and only a new session, by FRESH, gives exports independent of it; lineage-scoped exports are healed by a re-anchor whose fresh KEM input the adversary does not hold (Section 23.1). Material that must rotate with post-compromise recovery belongs in lineage scope.¶

• ulabel is at most 255 octets. Two namespaces are distinct: the strings this document passes to label() for its own derivations are internal to the key schedule, fixed by it and not registered; exporter labels are the application's, chosen freely except that a label MUST NOT begin with the octets "PQST", which this document reserves for itself and for the layers it specifies, the group layer's labels beginning "PQST group" among them (Section 26). Because the exporter's own label precedes ulabel in info, no application label can collide with a key PQST derives for itself; applications avoid collisions among themselves by their own naming, and no IANA registry of exporter labels is established (Section 25).¶

8.7. Other Derived Values

; Section 16.6, the record at rest
k_wrap   = Expand(Extract(label("record wrap"), ss_w),
                  label("wrap key"), 44)
; Section 19.6, kept after close
k_tomb   = Expand(cs(g), label("tombstone"), 48)
; Section 19.6, the CLOSED response
k_closed = Expand(k_tomb, label("seal closed") || th_3, 44)
; Section 16.3, prekey regeneration
nek_seed = Expand(local_secret, label("nek seed") ||
                  session_id(16) || version(4), 64)

8.8. Erasure

Each secret is erased as soon as the protocol no longer needs it: ss_* once the commit of the generation they feed is durable (Section 9.3.8), a requester's ss_peer being kept with its write-ahead state until the response (Section 16.4); an ephemeral dk when its exchange completes or is abandoned; a prekey's decapsulation key in the write that serves the request consuming it, or, for a prekey regenerated from local_secret (Section 16.3.2), when that secret is rotated; cs(g - 1) on commit of generation g (Section 16.4); lineage_secret(g) when lineage g is retired; epoch_secret(g, k) as Section 14.3 requires; sealing keys after their one message; a DISCOVER requester's dk, ss_fresh and k_disc when the response opens or the attempt ends (Section 9.7.1). Between exchanges the continuity record keeps session_root, cs(g) for the current g, and the prekey decapsulation key or local_secret; while an exchange is in flight it also keeps the write-ahead state of Section 16.4 (Section 16.6.1). A close erases them all; the tombstone keys k_tomb are the only secrets derived from a session that survive it, for tombstone_ttl (Section 19.6). Keys outside the key schedule have their own erasure rules: the retiring identity key (Section 23.4), the previous record key (Section 16.6.3) and the cohort layer's keys by its own (Section 26).¶

9.1. Overview

Roles. Within one exchange there is a requester, which sends the request, and a responder. In the FRESH and DISCOVER forms the requester becomes the session's initiator and the responder its responder; these session roles name the traffic directions i2r and r2i for the session's life. In the CONTINUE forms either session role may be the requester.¶

Forms.¶

• 0. Name: FRESH; Creates: generation 0; Fresh secret: encapsulation to the requester's ephemeral key; Peer proved: always; Requester proved: always; Round trips to requester data: 1¶

• 1. Name: CONTINUE; Creates: generation g + 1 from g; Fresh secret: encapsulation to the requester's ephemeral key; Peer proved: by flag; Requester proved: by responder policy; Round trips to requester data: 1¶

• 2. Name: CONTINUE_0RTT; Creates: generation g + 1 from g; Fresh secret: encapsulation to a prekey the responder issued earlier; Peer proved: by flag; Requester proved: not possible; the responder answers RETRY if it requires it; Round trips to requester data: 0¶

• 3. Name: DISCOVER (OPTIONAL, Section 9.7); Creates: nothing; delivers the responder's identity key; Fresh secret: encapsulation to the requester's ephemeral key; Peer proved: no; Requester proved: no¶

Messages. Two message types, carried in HANDSHAKE packets (FRESH, DISCOVER) or RECOVERY packets (CONTINUE forms) under the framing of Section 10.4:¶

msg_type 0x01  AnchorRequest
msg_type 0x02  AnchorResponse

The routing key of a FRESH or DISCOVER request is a handshake identifier: eight octets chosen at random by the requester for this attempt, and its response carries the same key.¶

The routing key of a CONTINUE request is the recovery identifier rec(g - 1, dir) of the current generation (Section 16.2); its response carries resp_rid(g - 1, dir', nonce) (Section 8.5), derived from the request's nonce and the responder's direction dir', a key that exists for that attempt only.¶

Generations. Throughout this section and Section 16, g names the generation an exchange creates: 0 for FRESH, and the current generation plus one for the CONTINUE forms, whose requests are sent under generation g - 1 and authenticated with cs(g - 1).¶

Prerequisites. In FRESH, the requester holds the peer's identity key (pinned, provisioned, or obtained by DISCOVER); the responder holds, or receives in the request, the requester's identity key. Identity keys are ML-KEM-1024 encapsulation keys; an identity's fingerprint is H(pk). Certification of identity keys is offline and optional (Section 6; Section 9.7.3).¶

Two Illustrated Exchanges (informative). The ladders illustrate the FRESH exchange and the zero-round-trip re-anchor as Section 9.2 and Section 9.3 specify them; they omit fragmentation, retransmission, the reply cache, the RETRY answers other than the one shown and the crash rules of Section 16.4.¶

requester                                            responder
    |  AnchorRequest FRESH, in a HANDSHAKE packet         |
    |  ek, ct_peer = Encap(resp_pk), init_counter,        |
    |  the sealed part under k_req                        |
    |---------------------------------------------------->|
    |               Decap(ct_peer); open the sealed part; |
    |               ct_e = Encap(ek); ct_req = Encap(req_pk)
    |               arm generation 0 (write-ahead)        |
    |  AnchorResponse: nonce_r, ct_e, ct_req,             |
    |  the sealed part under k_resp (grant, objects)      |
    |<----------------------------------------------------|
    |  Decap(ct_e), Decap(ct_req); cs(0); commit (write)  |
    |                                                     |
    |           PROBE under generation 0, repeated        |
    |<----------------------------------------------------|
    |  the first packet under generation 0:               |
    |  data, or PROBE_ACK                                 |
    |---------------------------------------------------->|
    |               it authenticates: generation 0 commits|
    |               at the responder; established         |

requester (holds the prekey nek, version v)          responder
    |  AnchorRequest CONTINUE_0RTT, in a RECOVERY packet  |
    |  on rec(g-1, dir): record, nek_version v,           |
    |  ct_n = Encap(nek), the sealed part under k_req     |
    |  derived from cs(g-1)                               |
    |---------------------------------------------------->|
    |  cs(g) derived at once; protected packets under g   |
    |  may follow in the same or later datagrams          |
    |  (early data, Section 16.3.2)                       |
    |---------------------------------------------------->|
    |               open under cs(g-1); Decap(ct_n) with  |
    |               the prekey, now consumed; cs(g);      |
    |               arm g (write-ahead), or answer RETRY  |
    |               PROOF_REQUIRED when proof is required |
    |  AnchorResponse: nonce_r, no ciphertext,            |
    |  the sealed part under k_resp                       |
    |<----------------------------------------------------|
    |  commit g (write)                                   |
    |           PROBE under generation g, repeated        |
    |<----------------------------------------------------|
    |               the early data, or a later packet,    |
    |               authenticates under g: generation g   |
    |               commits at the responder              |

9.2. Message Formats

All fields are fixed-width and big-endian (Section 7). [x] marks a field present only when stated.¶

AnchorRequest = msg_len form flags target_gen nonce form_fields
                [sealed_req tag]

msg_len     = 2OCTET     ; octets in the message, including msg_len
form        = OCTET      ; Section 9.1
flags       = OCTET      ; bit 0: prove_peer (ct_peer present); bit
                         ; 1: offer_proof (the requester asks to be
                         ; proved: the responder SHOULD set
                         ; prove_req); bits 2-7 reserved, MUST be 0
target_gen  = 2OCTET     ; generation this exchange creates; 0 in
                         ; FRESH and DISCOVER
nonce       = 32OCTET    ; fresh randomness

FRESH:          rk_hint(1) preauth_len(1) preauth(0|16) prior_len(1)
                prior(0|48) ek(L_ek) ct_peer(L_ct)
CONTINUE:       record_len(2) record(0..472) ek(L_ek) [ct_peer(L_ct)
                if prove_peer] [proof_pad(L_ct) if offer_proof and
                not prove_peer]
CONTINUE_0RTT:  record_len(2) record(0..472) nek_version(4)
                ct_n(L_ct) [ct_peer(L_ct) if prove_peer]
DISCOVER:       ek(L_ek) pad(L_ek + 16)

FRESH:            id_type(1) identity(48|L_ek) init_counter(8)
                  capabilities(2) prefix_len(1) prefix(0..2)
                  hint_len(1) authz_hint(0..64) objects_len(2)
                  objects(*)
CONTINUE forms:   attempt(2) objects_len(2) objects(*)
DISCOVER:         no sealed part and no tag

AnchorResponse = msg_len form flags target_gen nonce_r form_fields
                 sealed_resp tag

form        = OCTET      ; the request's form, or 4 = RETRY, or 5 =
                         ; CLOSED (Section 19.6)
flags       = OCTET      ; bit 1: prove_req (ct_req present); bits 0,
                         ; 2-7 reserved, MUST be 0
target_gen  = 2OCTET     ; echoes the request
nonce_r     = 32OCTET    ; random, chosen by the responder for each
                         ; response

FRESH:          ct_e(L_ct) ct_req(L_ct)   ; prove_req MUST be 1
CONTINUE:       ct_e(L_ct) [ct_req(L_ct) if prove_req]
CONTINUE_0RTT:  (none)                    ; prove_req MUST be 0
DISCOVER:       ct_e(L_ct)
RETRY, CLOSED:  (none)

FRESH:            capabilities(2) prefix_len(1) prefix(0..2)
                  objects_len(2) objects(*)
CONTINUE forms:   objects_len(2) objects(*)
DISCOVER:         peer_pk(L_ek)
RETRY, CLOSED:    reason(1) detail(1)

9.3. Processing

Checks are listed in the order they MUST be performed: each is cheaper than the next, and no public key operation precedes a check that could reject the message without one.¶

preauth = HMAC-SHA-384(k_pre, th_0 || nonce)[0:16]
          ; k_pre from Section 8.4

9.4. Fragmentation, Retransmission, Parity, and Limits

• Size. An anchor message MUST NOT exceed MAX_MESSAGE = 8192 octets. Reassembly buffers are bounded by it.¶

• Fragments. A message is sent as fragments of a frag_size the sender chooses (Section 10.4), default MAX_FRAGMENT. A requester on a path of known small MTU chooses a smaller frag_size; the responder mirrors it.¶

• Parity. A sender MAY add the parity fragment of Section 10.4 to any flight of two or more source fragments. It SHOULD add it to every retransmission, a cached reply to the request's original address included (toward any other address the cached reply is within the reflection budget, which the parity fragment would exceed), and whenever the session's observed loss exceeds 2 %, on the first transmission of a request too; it MAY omit it otherwise. Observed loss is the fraction of sequence numbers missing among the protected packets received under the current generation, taken over windows of 64 packets and averaged with weight 1/4 for the newest window; it is kept in memory only, so that the first exchange after an outage benefits from the loss seen before it. Receivers MUST implement recovery.¶

• Retransmission. The requester retransmits the whole request, byte-identical, when no response has been accepted after a retransmission interval: initially 1 s, or twice the path's smoothed round-trip time or twice the session's last anchor exchange time (Section 16.7) when either is longer, doubling to a cap of 16 s. While a fragment of the response is being reassembled the request is not retransmitted: the answer is on its way, and a copy of the request would only queue ahead of the rest of it on a slow link; the reassembly's own deadline, anchor_timeout, bounds the wait, and so does the attempt's life (Section 16.7): a response completed after the attempt ended commits nothing, and a response that fails to open restarts the timer. A FRESH or DISCOVER attempt is abandoned after 5 transmissions; CONTINUE attempts follow Section 16.7. A responder never retransmits on its own; a retransmitted request elicits the cached response.¶

• Reply cache. The responder keeps the last response it sent for a session for reply_cache_ttl (Section 16.1), keyed by the request's bytes, with the request's source address, and persists it with the armed generation (Section 16.4). A cached response is sent on the routing key the original was sent on: to the recorded address without condition; to any other address only within the reflection budget of Section 15.4 toward that address, the retransmission credited to it and the reply debited, so that a requester that changed address during the exchange is answered where it now is and a replay from a third address obtains no more than the network already carried. Commit does not end the cache: a CONTINUE_0RTT requester that crashed after sending may need the response after the responder has committed on its early data, and a byte-identical retransmission is the only thing a cached response ever answers (Section 16.4).¶

• Abandonment. A requester that abandons an attempt erases dk and treats the attempt's nonce and handshake identifier as consumed.¶

The bounds on the state these messages may hold before anything is authenticated are the following; Section 23 states the costs they bound.¶

9.5. Reflection Bound

A responder MUST NOT send, in reply to an unauthenticated request, more octets than it received in that request. Specifically:¶

• A FRESH response is never larger than its request: the fixed parts of the response are smaller than those of the request, and objects that would exceed the bound are deferred (Section 9.3.7). A responder adds a parity fragment only under the rule of Section 10.4.¶

• A DISCOVER request carries pad so that the response, which carries the responder's identity key, is no larger than the request.¶

• No response of any kind is sent to a request that fails before its sealed part opens (FRESH) or before the message is complete (DISCOVER).¶

• A CONTINUE request is authenticated under cs(g - 1) before any response, so its sender holds the session's secret, or replays one who does; its source address proves nothing (Section 23). Its response is no larger than the request toward an address the responder has not validated: proof of the requester adds ct_req, for which a request that offers the proof carries proof_pad and a request with prove_peer carries ct_peer, and a request with neither is answered RETRY PROOF_REQUIRED there. Replays of a CONTINUE request obtain at most the cached response, to the original source address or within the budget of Section 15.4 elsewhere, and nothing after reply_cache_ttl.¶

Together with the budget for unvalidated paths (Section 15.4) this bounds what an endpoint sends toward an address it has not validated to what it received from it, beyond the probe floor of Section 15.4 and apart from the anchor requests it initiates on its own schedules (Section 9.4 and Section 16.7); a validated path, and a previously validated address within validated_ttl (Section 15.3), send unbudgeted, so the bound against third-party reflection rests on path validation, on the expiry of previous validation and on the endpoint-wide budget, not on a ratio alone.¶

9.6. Simultaneous Open and Concurrent Sessions

9.7. DISCOVER: First Contact with an Unknown Responder Key (OPTIONAL)

A requester that does not hold the responder's identity key MAY perform a DISCOVER exchange and then a FRESH exchange bound to it. Support is signalled by configuration, not by negotiation; a responder that does not implement it drops DISCOVER requests like any other unknown form.¶

9.8. Properties

Stated here; argued in Section 23.¶

• Mutual authentication by decapsulation. The responder is authenticated by ss_peer, the requester by ss_req; no signature is computed online in any form.¶

• Key-compromise impersonation resistance. Each party's authentication rests on the other party's identity key through its own decapsulation, so compromise of one identity key does not allow impersonating the other party to its owner.¶

• Forward secrecy from ss_fresh: the decapsulation key it was produced with (the ephemeral dk, or a single-use prekey) is erased after one use. Later compromise of both identity keys reveals ss_peer and ss_req but not ss_fresh.¶

• Identity hiding. In FRESH the requester's identity is sealed under a key only the holder of the responder's identity key can derive, so it is hidden from passive observers and from active attackers without that key; the responder's identity is never transmitted except in DISCOVER. Limits: a later compromise of the responder's identity key reveals the identities in captured requests; flight sizes reveal that an exchange took place.¶

• Transcript binding. The wire version, the suite, the intended peer identity, any preceding DISCOVER exchange (as prior) and the request cleartext are in th_1, which keys the request's sealing key and is its associated data; the sealed request and its tag extend the transcript to th_2, which enters the lineage secret and, for generation 0, the session root; the response cleartext extends it to th_3, which keys the response's sealing key and is its associated data; the sealed response and its tag extend it to th_4, which a FRESH exchange following a DISCOVER exchange carries as prior (Section 8.3). The continuity secret cs(g) takes the shared secrets of both messages' ciphertexts and no transcript hash (Section 8.4), so what the lineage confirms is the request and the secrets, not the response's cleartext: a response altered in its cleartext fails to open under k_resp, and a captured ciphertext cannot be reused with a different ephemeral key, but the lineage key confirms the response only through the secrets it carried. A request cannot be reinterpreted under another form.¶

• Replay. A replayed FRESH request costs the responder one decapsulation, two during a rotation when rk_hint is 0, and obtains no response, unless it is byte-identical to one answered within reply_cache_ttl, in which case the cached response is resent at no public key cost, or it was never confirmed and its exchange has expired, in which case it is served again at the cost of a forged request (Section 9.3.5), to the original address without condition and to another within the reflection budget of Section 15.4; a replayed CONTINUE request likewise obtains at most the cached response under the same bound. A replayed or late response matches no attempt and costs the requester nothing (Section 9.3.8).¶

• Reflection bounded by the budget of Section 15.4, the probe floor included (Section 9.5).¶

• Deniability. No transferable proof of participation exists, since nothing is signed online.¶

• Downgrade. One suite per version, implied by the identity key; the version and suite are in the transcript; an attacker who drops a higher-version request can only make the requester retry at a version it is configured to accept (Section 21).¶

• Agility is by identity-key provisioning: a new suite is a new identity key of the new type, selected by rk_hint.¶

10.1. Common Header

Every PQST packet begins with a 12-octet common header:¶

CommonHeader = magic version type routing_key

magic       = 2OCTET     ; 0x5150
version     = OCTET      ; 0x14
type        = OCTET      ; packet type and reserved bits
                         ; (Section 10.1.1)
routing_key = 8OCTET     ; type-dependent (Section 10.1.2)

bits 0-1   packet_type   0 = PROTECTED, 1 = HANDSHAKE, 2 = RECOVERY,
                         3 = reserved for the cohort layer's
                         group packet (Section 26); defined only
                         by an extension enabled by capability
                         bit 0 (Section 21.1)
bits 2-7   reserved      MUST be 0

10.2. Protected Packets

A protected packet carries application data or control frames under the session's current traffic keys.¶

ProtectedPacket = CommonHeader masked_block ciphertext tag

masked_block = 16OCTET     ; PacketNumberBlock XOR mask
                           ; (Section 10.3)
ciphertext   = *OCTET      ; AEAD output over the plaintext
                           ; (Section 10.2.2)
tag          = 16OCTET     ; AEAD authentication tag

CommonHeader.packet_type is PROTECTED and CommonHeader.routing_key is a RID of the receiving endpoint (Section 15.1).¶

PacketNumberBlock = epoch_id seq stream_id pflags padding_len

epoch_id    = 4OCTET     ; lineage_gen (16 bits) || epoch_index (16
                         ; bits); Section 12.2
seq         = 8OCTET     ; sequence number within (direction,
                         ; epoch_id); Section 12.3
stream_id   = OCTET      ; 0x00-0xDF application-defined; 0xE0-0xFD
                         ; reserved for protocol-defined upper layers
                         ; (Section 25); 0xFE = STREAM_CONTROL
                         ; (Section 10.5); 0xFF = STREAM_DUMMY
pflags      = OCTET      ; reserved; MUST be 0
padding_len = 2OCTET     ; number of padding octets at the end of the
                         ; plaintext

key       = AEAD key for (direction, epoch_id)
            ; Section 8
nonce     = iv(direction, epoch_id) XOR (epoch_id || seq)
            ; Section 12.1
aad       = magic || version || type || PacketNumberBlock
            ; 20 octets, plaintext form; the routing key is excluded
plaintext = payload || padding
ciphertext || tag = AEAD-Encrypt(key, nonce, aad, plaintext)

MIN_PACKET_SIZE   = 12 + 16 + 16 = 44 octets
                    ; a protected packet with an empty payload
INITIAL_PATH_MTU  = 1200 octets
                    ; a sender's bound on a path until probing
                    ; raises it
MAX_PAYLOAD(path) = path_mtu - 44 - padding_len

10.3. Header Protection

Header protection hides PacketNumberBlock from observers. It provides confidentiality for the block only; integrity comes from the block's inclusion in the associated data.¶

sample       = the first 16 octets of (ciphertext || tag)
mask         = AES-256-Encrypt(hp_key, sample)
               ; one raw block encryption of the 16-octet sample
masked_block = PacketNumberBlock XOR mask

10.4. Handshake and Recovery Packets

Handshake packets (Section 9) and recovery packets (Section 16) carry anchor messages (Section 9.1) that may exceed one datagram. They share one framing:¶

MessagePacket = CommonHeader message_header fragment

message_header = msg_type frag_index frag_count msg_id
                 ; 5 octets
msg_type       = OCTET      ; message type; values in Sections 9
                            ; and 16
frag_index     = OCTET      ; 0-based index of a source fragment; the
                            ; value frag_count denotes the parity
                            ; fragment
frag_count     = OCTET      ; number of source fragments of the
                            ; message, at least 1
msg_id         = 2OCTET     ; identifies the message among those the
                            ; sender has in flight on this routing
                            ; key; the same in every fragment and in
                            ; every retransmission of the message
fragment       = *OCTET     ; at most frag_size octets

MAX_FRAGMENT = 1183 octets      ; so that a message packet, 12 + 5 +
                                ; 1183, is at most 1200 octets
MIN_FRAGMENT = 512 octets

• Every anchor message begins with msg_len, a 2-octet count of the octets in the message including msg_len itself (Section 9.1), so that the zero padding a last fragment recovered through the parity fragment carries can be trimmed. That is the only padding a reassembled message has: otherwise msg_len equals the reassembled length, and a message whose msg_len is anything else is malformed and MUST be dropped.¶

• The sender chooses frag_size, with MIN_FRAGMENT <= frag_size <= MAX_FRAGMENT, and splits the message into frag_count source fragments of exactly frag_size octets, except the last, which carries the remainder (between 1 and frag_size octets). frag_count is the smallest count that holds the message, and at least 1. Every anchor request is longer than MAX_FRAGMENT, so every request has at least two source fragments and the responder learns frag_size from any fragment other than the last source fragment; a response may be a single fragment. Reassembly itself needs only the index order.¶

• A sender MAY add one parity fragment to a message of two or more source fragments, with frag_index = frag_count: the bitwise exclusive-or of all source fragments, each zero-padded to frag_size, so that it is exactly frag_size octets. A receiver holding all but one source fragment together with the parity fragment MUST recover the missing source fragment by exclusive-or, trimming the result with msg_len if it is the last. Receivers MUST implement recovery; whether to send a parity fragment is the sender's decision per flight (Section 9.4).¶

• frag_index MUST NOT exceed frag_count. A packet violating this, or whose fragment is longer than MAX_FRAGMENT, MUST be dropped.¶

• msg_id tells the fragments of one message from those of another on the same routing key and from the same source, which a receiver MUST reassemble separately (Section 9.4): a requester's consecutive attempts travel on one recovery identifier, and the fragments of an attempt it has abandoned may still be in flight when the next one is sent. A sender sets msg_id to the first two octets of H(message), SHA-384 over the complete message as sent, from msg_len on, so that a retransmission carries the same value; the receiver treats it as opaque. Without it, fragments of two messages of equal length combined through the parity fragment into a message that parsed but did not open, and cost the requester a decapsulation.¶

• A responder MUST NOT use a frag_size larger than the frag_size of the request it is answering, and MUST NOT add a parity fragment unless the request carried one or its reply is otherwise no larger than the request. A reply is therefore never larger than the message that elicited it (Section 9.5).¶

• Reassembly, retransmission and the limits on half-open state are defined in Section 9.4 and apply to both packet types.¶

• routing_key is the handshake identifier for HANDSHAKE packets and the recovery identifier for RECOVERY packets. All fragments of one message carry the same routing_key.¶

The 1200-octet bound is chosen so that a message packet fits the IPv6 minimum MTU with IP and UDP headers; the 512-octet floor lets a flight cross a link with a smaller MTU at the cost of more fragments. Message packets are never padded.¶

10.5. Control Frame Framing

Within a protected packet whose stream_id is 0xFE (STREAM_CONTROL), payload is one or more control frames:¶

ControlFrame = ctrl_type length ctrl_data

ctrl_type = OCTET
length    = 2OCTET     ; length of ctrl_data in octets
ctrl_data = *OCTET

A control frame MUST be fully contained in one packet. A control packet MUST carry at least one frame. Receivers MUST drop, after authentication and after the replay commit (Section 11.4, step 15), a control packet whose payload is empty or whose declared frame lengths do not exactly consume payload. Control frame types and their ctrl_data formats are defined in Section 19. Carrying control frames on a reserved stream identifier rather than signalling them with a flag keeps dispatch a function of stream_id alone and leaves every pflags bit free.¶

11.1. Processing Order

Receivers MUST process an incoming datagram in the following order and MUST stop at the first failing step. "Drop" means: discard the datagram, send nothing, change no protocol state, and at most increment a counter.¶

1. Size. Drop if shorter than 18 octets, the common header, the message header and one octet of a fragment, or longer than the receiver's local maximum (Section 10.2.3).¶

2. Common header. Parse the 12-octet common header. Drop on a magic or version mismatch, on non-zero reserved type bits, or on packet_type 3 unless the receiver implements the extension that defines it (Section 21.1); such a drop leaves no trace but a counter.¶

3. Dispatch by type. PROTECTED packets shorter than 44 octets (MIN_PACKET_SIZE, Section 10.2.3) are dropped; the others continue at Section 11.2. HANDSHAKE and RECOVERY packets continue at Section 11.5.¶

11.2. Protected Packets: The Single-Attempt Pipeline

1. Session lookup. Look up routing_key as a RID. The lookup yields the session, the lineage the RID belongs to, and the receive direction. On a miss, drop. Receivers MUST NOT attempt decryption, unmasking or any key derivation for an unknown RID. RIDs enter the lookup table only by derivation, at lineage establishment and as the window slides after authenticated use (Section 15.1), never because a packet carried them.¶

2. Unmask. With hp_key the header-protection key of the lineage and receive direction (Section 10.3.1): mask = AES-256-Encrypt(hp_key, (ciphertext || tag)[0:16]); block = masked_block XOR mask; parse block as PacketNumberBlock.¶

3. Pre-authentication filter (Section 11.3). Drop on any failure. This step reads state and MUST NOT write any.¶

4. Key selection. Select the AEAD key and IV for (direction, epoch_id). If epoch_id is the next epoch and its keys have not yet been derived, derive them now (Section 14.3). This is the only key derivation an unauthenticated packet can cause, it happens at most once per epoch, and its result is retained.¶

5. Nonce and AAD. nonce = iv XOR (epoch_id || seq); aad = CommonHeader[0:4] || block, the routing key excluded (Section 10.2.2).¶

6. AEAD. Perform exactly one AEAD-Decrypt(key, nonce, aad, ciphertext || tag). On failure, drop. Receivers MUST NOT retry with another key, epoch, sequence number or nonce. Every state change in the remainder of this section is conditional on this step succeeding.¶

7. Post-authentication processing (Section 11.4).¶

11.3. Pre-Authentication Filter

The filter rejects, before the AEAD, packets that cannot be valid. It is a cost filter, not a security boundary: a packet that passes it gains nothing, and a packet that fails it is merely dropped early. All checks are pure functions of the block and of receiver state.¶

• pflags MUST be 0; all eight bits are reserved.¶

• epoch_id MUST be in the receive direction's permitted set (Section 14.2): the current epoch, the next epoch, and the previous epoch while its overlap period is active.¶

• seq MUST satisfy WouldAccept(direction, epoch_id, seq) (Section 13.3), the non-mutating form of the replay check.¶

• padding_len MUST NOT exceed the plaintext length, which is the length of ciphertext.¶

Without hp_key, an attacker's block is uniformly random after unmasking, and the probability that a random block passes the filter is at most about 2^-80. The cost of a packet that fails the filter is one table lookup and one block-cipher invocation.¶

11.4. Post-Authentication Processing

After step 9 succeeds, in this order:¶

1. Replay commit. Check(direction, epoch_id, seq) (Section 13.4), the mutating form of the replay check. If it reports a duplicate, drop and count it (Section 12.5): at a receiver that serializes the packets of a direction it cannot, since step 6 dropped the duplicate before the AEAD; at one that processes them concurrently, a copy that passed step 6 before another committed is dropped here.¶

2. Epoch commit. If epoch_id is the next epoch, advance the receive epoch as defined in Section 14.4.¶

3. Path handling. If the datagram's source address differs from the path the RID was last seen on, apply Section 15.3 (candidate path). Path state is updated only here, after authentication.¶

4. Padding. Remove the last padding_len octets.¶

5. Dispatch by stream_id. 0xFF: discard the payload. 0xFE: parse and process the control frames (Section 19); a control packet whose payload is empty or whose frames do not exactly consume the payload is dropped at this point, after its replay commit. 0xE0 to 0xFD: deliver the payload to the upper layer registered for the value, or discard it if none is implemented. 0x00 to 0xDF: deliver the payload to the application for stream_id.¶

A control frame that fails its own validation (Section 19) MUST NOT affect session state; the packet's replay commit (step 11) stands.¶

11.5. Handshake and Recovery Packets

1. Framing. Parse message_header. Drop if frag_index > frag_count or if the fragment is longer than MAX_FRAGMENT (Section 10.4).¶

2. Association. HANDSHAKE: associate by (source address, routing_key). RECOVERY: look up routing_key as a recovery identifier (Section 16.2), as a stale identifier kept for the reply cache (Section 16.4), as a tombstoned recovery identifier (Section 19.6), or, for an AnchorResponse, as the resp_rid of an outstanding attempt (Section 9.3.8). On a miss, drop, with one exception: if the fragment is the first fragment of a request that carries a sealed record and the receiver is configured to serve from records (Section 16.6), the receiver unseals and verifies the record before allocating any state, and drops if that fails; a verified record permits reassembly state only, and the session is created once the complete request opens (Section 16.6.3). Receivers MUST NOT otherwise allocate state for a RECOVERY packet whose routing key is unknown. HANDSHAKE, at a responder requiring the pre-authentication tag (Section 9.3.4): a fragment of a request not yet verified that is not fragment zero, the parity fragment included, is dropped here without allocation; fragment zero is checked as Section 9.3.2 says before any state is allocated, and once it has passed, the request's other fragments are stored in any order. "First fragment" throughout means frag_index 0, not the first to arrive. Reassembly state is keyed by (routing_key, source address, msg_id) in both packet types (Section 9.4).¶

3. Reassembly. Store the fragment subject to the limits in Section 9.4: the handshake pool's per-source and global bounds, the recovery pool's per-identifier and global bounds, each pool separate, a bound reached refusing the new message and evicting none. The first fragment that is not the last source fragment fixes frag_size, in whatever order fragments arrive; a fragment inconsistent with it drops the reassembly: a source fragment other than the last, or the parity fragment, of any other length, or a last source fragment longer than frag_size, including one stored before frag_size was known. When all source fragments are present, or all but one together with the parity fragment, reassemble in index order, recovering a missing fragment by exclusive-or if needed (Section 10.4); trim a last fragment so recovered to msg_len, drop a message whose msg_len differs from its length otherwise, and process the message as defined in Section 9 (handshake) or Section 16 (recovery). A message is processed at most once.¶

The public key operations a handshake or recovery message causes are bounded by the message definitions themselves (Section 9 and Section 16) and are never performed on an incomplete message.¶

11.6. Resource Bounds

Implementations MUST enforce the following bounds. They are what make the receiver's cost per datagram bounded regardless of its contents.¶

11.7. The State-Mutation Rule

No unauthenticated datagram changes authoritative session state: the committed generation and the armed one, the committed receive epoch, the replay window, paths and their validation, routing identifiers, session allocation, grants, and the freshness marks of Section 9.3.5. Before the AEAD has succeeded on a datagram the receiver does only the bounded work this section and Section 9.4 name, and a datagram that fails the AEAD leaves no trace in authoritative state. The bounded work is: parsing, lookup and the one block-cipher and one AEAD operation of Section 11.2; the one-time derivation of the next epoch's traffic keys when a packet first names that epoch (Section 11.2, step 7), whose cached result advances nothing, the receive epoch moving only when a packet under it authenticates (step 12); reassembly state for a handshake or recovery message within the limits of Section 9.4, discarded at its deadline; and the three transmissions below. Processing an unauthenticated datagram never causes an unbounded increase in memory, retained state or cryptographic work.¶

A receiver MUST NOT, on the basis of an unauthenticated packet: advance an epoch; slide, clear or mark a replay window; create, promote, validate or retire a path; install or retire a RID; allocate session state; commit or discard a generation; move a freshness mark; issue, extend or revoke a grant; or send a response.¶

There are exactly three transmissions that an unauthenticated datagram may cause. The first is the cached reply to a byte-identical retransmission of an answered anchor request (Section 9.4), which repeats octets the network has already carried: to the request's original address, or to another address within the reflection budget of Section 15.4 toward it. The second is a tombstone's CLOSED answer to a request on a closed session's recovery identifier (Section 19.6), which is under a hundred octets (56 in Appendix D.11), commits no state and is sent only to the request's source. The third, at a responder configured to serve it, is the DISCOVER response (Section 9.7), which carries only the responder's public identity key, is no larger than its request, commits no state and is sent only to the request's source. Section 22 lists this rule as an invariant; Section 13 and Section 14 define the two-phase checks that implement it for sequence numbers and epochs. The invariant is testable as a comparison: the authoritative state of an endpoint before and after an unauthenticated datagram is the same, whatever the datagram contained and whatever bounded work it caused.¶

11.8. Constant-Time Requirements

Comparison of authentication tags is performed by the AEAD. The replay bitmap operations and the filter comparisons MUST NOT branch on secret key material. Timing differences between "dropped by the filter" and "dropped by the AEAD" reveal only whether the sender holds hp_key, which the sender already knows, and are acceptable.¶

12.1. Nonce

PQST uses a 96-bit AEAD nonce, constructed for each protected packet as:¶

nonce = iv XOR (epoch_id || seq)

• iv is the 12-octet IV for the packet's direction and epoch, derived from the key schedule (Section 8).¶

• epoch_id is the 32-bit epoch identifier (Section 12.2) and seq the 64-bit sequence number (Section 12.3), both big-endian, concatenated to 12 octets.¶

This construction is mandatory and MUST be implemented exactly as specified. Both endpoints construct the nonce from the same (epoch_id, seq): the sender from its allocation state, the receiver from the unmasked packet number block (Section 11.2). Nonce uniqueness is required independently for each direction, because each direction has independent keys and IVs.¶

12.2. Epoch Identifier

epoch_id = lineage_gen (16 bits, high) || epoch_index (16 bits, low)

• lineage_gen is the generation of the session's continuity secret (Section 16). It is 0 for the lineage created by the handshake and increases by exactly 1 at each successful re-anchor.¶

• epoch_index is the epoch within the lineage. It is 0 for the first epoch of a lineage and increases by exactly 1 at each epoch advance (Section 14).¶

Because lineage_gen occupies the high bits, epoch_id is strictly increasing over the life of a session across both epoch advances and re-anchors. Every rule in this specification that compares epochs compares the 32-bit value.¶

• The sender MUST NOT advance epoch_index beyond 0xFFFF. If epoch_index reaches 0xFFFF, the endpoint MUST perform a re-anchor (Section 16) before that epoch's sequence limit (Section 12.4) is reached, and MUST NOT send further packets in the lineage once the limit is reached.¶

• If lineage_gen would exceed 0xFFFF, the session MUST be closed with reason SESSION_LIFETIME (Section 20) and a new handshake performed.¶

12.3. Sequence Numbers

For each direction, the sender maintains (epoch_id, seq) for its current sending epoch.¶

• seq starts at 0 in every epoch and MUST increase by exactly 1 for each packet sent, including dummy packets and packets carrying only control frames.¶

• (epoch_id, seq) MUST NEVER repeat for a given direction. This is the sender's responsibility and the single most important rule in this specification: a repeat is an AEAD nonce reuse.¶

• Allocation of (epoch_id, seq) MUST be linearizable (Section 12.6): no two packets may be allocated the same pair, and no packet may be allocated a pair from an epoch whose keys it does not use.¶

• A future packet type in which several senders share one key (Section 10.1.1, type 3) will partition seq, for example by reserving its high 16 bits for a sender index, so that senders have disjoint nonce spaces. That reservation does not change the formula above for protected packets.¶

12.4. Per-Epoch Limits

The AEAD is AES-256-GCM, whose confidentiality bound degrades with the number of packets encrypted under one key (Section 6.6 of [RFC9001]; Section 5.5 of [RFC9846]).¶

• A sender MUST NOT encrypt more than 2^23 packets under one (direction, epoch_id).¶

• A sender MUST advance the epoch (Section 14.1) no later than seq = 2^23 - 2^20. The margin is the forward acceptance bound F of Section 13.2, so that every sequence number a receiver can accept lies within the epoch's limit.¶

• Epoch overlap (Section 14.4) does not increase the number of packets that may be encrypted under an epoch's keys.¶

• The integrity bound of AES-256-GCM is 2^52 forgery attempts per key, the limit Section 6.6 of [RFC9001] sets for QUIC from the analysis of Appendix B.1 of [RFC9001]. The pre-authentication filter (Section 11.3) rejects almost every forgery whose header an attacker had to guess, but not one made from a captured packet with its tag altered, which passes the filter as often as it is sent while the packet's sequence number is uncommitted (Section 23.2); a receiver therefore counts the failed verifications under each generation's receive keys and, should the count reach 2^52, retires the keys by a re-anchor and accepts nothing under them from that count on, whether or not the re-anchor that replaces them completes: a session whose re-anchor fails recovers by the schedule of Section 16.7, under new keys. The count is a bookkeeping of the bound, not a defence against the cost of the attack, which Section 23.2 states.¶

seq is carried as 64 bits on the wire so that the nonce formula is fixed-width; values at or above 2^23 are never valid and are rejected by the filter.¶

12.5. Duplicates at the Receiver

Nonce uniqueness is the sender's responsibility (Section 12.3, Section 12.6 and Section 12.7), and it is enforced at the sender, not detected at the receiver: a receiver cannot tell a sender's reuse from a duplicate the network made, and it does not try.¶

• A packet whose (epoch_id, seq) is already accepted in the replay window is dropped by WouldAccept before the AEAD (Section 11.2, step 6; Section 13.4), so a second packet under a nonce the receiver has accepted is never authenticated, whatever it carries. Receivers MUST discard it and SHOULD count it, as a replay or a duplicate.¶

• The mutating check of Section 11.4, step 11, reports a duplicate only at a receiver that processes the packets of one direction concurrently, where two copies passed WouldAccept before either committed; the later is dropped and counted the same way.¶

• A receiver retains no tags and compares no ciphertexts, and no count of duplicates closes a session: the duplicates are unauthenticated, so a close on them would let anyone who captured packets close the session by replaying them, and the retention that would detect a sender's fault after the fact would be paid on every packet for a fault a conforming sender cannot commit.¶

12.6. Linearizability and State Coupling

• allocate(direction) -> (epoch_id, seq) and install_epoch(direction, epoch_id, key, iv) MUST be linearizable with respect to each other: every packet is encrypted with the key, IV and (epoch_id, seq) of a single, consistent epoch snapshot.¶

• Implementations SHOULD bundle epoch_id, key, IV and the sequence counter into one immutable snapshot that is installed atomically, so that the coupling cannot be violated by construction.¶

• In multi-threaded implementations, epoch installation MUST be performed by a single owner (the session's I/O context); other components request an advance and never mutate epoch state directly.¶

• There MUST NOT be any window in which a packet could be encrypted with a nonce from one epoch and the key of another.¶

12.7. Fail-Closed on Loss of Sequence State

A sender that cannot prove continuity of its (epoch_id, seq) state, for example after a crash or an unclean shutdown, MUST NOT send any packet under any previously used epoch. The only permitted recovery is a re-anchor (Section 16), which creates a new lineage with fresh keys, or a new handshake. Persisting sequence counters in order to resume an epoch is not permitted; Section 16.6 defines the only state that survives a restart.¶

A generation re-created after its sending state was discarded, from the continuity record after a restart or from a kept attempt's state after entry to DORMANT (Section 16.3.2), is receive-only. A restart re-creates only an armed generation and one an outstanding CONTINUE_0RTT request had derived (Section 16.6.2), from the cs and lineage_secret the record keeps for them; the committed generation is kept as its continuity secret alone, its identifiers and keys not re-created, so that packets the peer sends under it are dropped as unknown until the re-anchor that follows the restart. A re-created generation is receive-only: the endpoint sends nothing under it, for the reason above, but keeps its receiving identifiers and keys so that packets the peer sends under it still authenticate, and so that a generation the peer holds committed is not lost. It delivers nothing under it either: its replay window is empty when it is re-created, so a packet the peer sent before, replayed, would be delivered a second time (Section 16.6.2).¶

As soon as such a generation commits, by a packet from the peer, by a request that opens under it or by the endpoint's own response opening, the session re-anchors (Section 16.6.2); the new generation is the first one that sends. Until it does, the session is RECOVERING whatever its paths, and the recovery schedule drives the re-anchor. Without this rule, a restored generation committed by a request that opened under it would leave a session ESTABLISHED and unable to send for the rest of its life, and a restored session whose one attempt failed would sit the same way. The rule is enforced where packets are built, for every kind of packet, and the lineage of a restored generation is never derived again as a sending one: the prekey a CONTINUE_0RTT request consumed is erased with the write that arms the generation (Section 16.4), and a restored generation is displaced by a re-served request only once that request's generation is written. Anchor messages are not packets under a generation and may be retransmitted after a restart.¶

13.1. Windows

• Each endpoint maintains, for each receive direction and each epoch in that direction's permitted set (Section 14.2), one replay window: the highest accepted sequence number last_seq, and a bitmap of W bits recording which of the W sequence numbers at or below last_seq have been accepted.¶

• Windows are per epoch. A window is created when its epoch first becomes permitted and discarded when the epoch leaves the permitted set (Section 14.5). Windows are never reset or copied between epochs.¶

• Windows belong to the session, not to a path. All paths of a session share one window per (direction, epoch); a path change never creates, resets or modifies a window (Section 3, ownership rule). This is also what makes redundant transmission on several paths safe: the second copy is a duplicate and is dropped.¶

13.2. Parameters

W   replay window size in packets   64 <= W <= 65536, default 4096
F   forward acceptance bound        default 2^20

• W bounds how far behind last_seq a late packet may arrive and still be accepted. It MUST be large enough to cover the reordering the session's paths can produce. When a session may hold several paths (Section 15), W MUST exceed the packet rate multiplied by the largest round-trip-time difference between those paths, so that packets on a slower path are not rejected as old. The default of 4096 covers about 4 ms of reordering at one million packets per second and several seconds at typical rates.¶

• F bounds how far ahead of last_seq the pre-authentication filter will pass a packet. It exists only to keep the filter's false-positive rate low; it is not a security boundary. A legitimate burst loss of up to F packets is tolerated without any recovery. F MUST be less than the per-epoch limit of Section 12.4; the default leaves a margin of 2^20 below 2^23.¶

Neither parameter is negotiated. Each endpoint chooses its own receive-side values.¶

13.3. WouldAccept: The Non-Mutating Check

WouldAccept(direction, epoch_id, seq) is evaluated in the pre-authentication filter (Section 11.3). It returns true if and only if:¶

• epoch_id is in the direction's permitted set, and¶

• seq < 2^23, and¶

• seq + W > last_seq (the packet is not too old; computed in this form to avoid underflow), and¶

• seq <= last_seq + F (the packet is not too far ahead), and¶

• if seq <= last_seq, the bit for seq is not set (the packet is not already accepted).¶

WouldAccept MUST NOT modify last_seq, the bitmap, or any other field. Implementations MUST be able to show, by test, that a sequence of WouldAccept calls leaves the window byte-for-byte unchanged.¶

For an epoch whose window does not yet exist (the next epoch, Section 14.3), WouldAccept is evaluated against an empty window with last_seq = 0 and no bits set, which accepts 0 <= seq <= F.¶

13.4. Check: The Authoritative Check

Check(direction, epoch_id, seq) is evaluated only after the AEAD has succeeded (Section 11.4, step 11). It MUST return the same decision WouldAccept returned for the same inputs with the same state, and on acceptance it mutates the window:¶

• If seq > last_seq: slide the bitmap forward by seq - last_seq positions (clearing it entirely if the distance is at least W), set last_seq = seq, and set the bit for seq.¶

• If seq <= last_seq: set the bit for seq.¶

Check MUST be called exactly once per authenticated packet and never for a packet that failed authentication.¶

13.5. The Two-Phase Rule

The split between WouldAccept and Check is a security requirement, not an optimisation. Because seq is carried on the wire, an attacker who could cause the window to advance before authentication could, with one forged packet carrying a large seq, slide the window past every legitimate in-flight packet and end the session. Therefore:¶

• Phase one (WouldAccept) MUST be side-effect free.¶

• Phase two (Check) MUST be reached only through a successful AEAD.¶

• Phase one MUST accept everything phase two would accept, so that no legitimate packet is dropped by the filter.¶

• A forged packet that fails the AEAD MUST leave last_seq, every bitmap, and every epoch-permission state byte-for-byte unchanged.¶

An authenticated forward jump of any size up to F is accepted: it is burst loss, and rejecting it would convert packet loss into session loss. Jumps beyond F cannot be accepted by the data plane; the session recovers by re-anchor (Section 16), which starts a new lineage.¶

13.6. Epochs and Overlap

• A packet is checked against the window of the epoch it names. Windows of different epochs are independent; the sequence spaces are disjoint by construction (Section 12.2).¶

• When the receive epoch advances (Section 14.4), the previous epoch's window is retained for the overlap period and continues to reject duplicates within it; the new epoch's window starts empty.¶

• When an epoch leaves the permitted set, its window is discarded together with its keys. No packet naming that epoch can be accepted afterwards, so nothing is lost by discarding the window.¶

13.7. Handshake and Recovery Messages

Replay protection for handshake messages is provided by the per-identity freshness counter and the single-use ephemeral key of Section 9.4; for recovery messages by the single-use recovery identifier and generation counter of Section 16.5. Neither uses the windows of this section.¶

14.1. Sender Rules

For each direction, an endpoint has a sending epoch e.¶

• An endpoint MAY advance its sending epoch from e to e + 1 whenever it holds the evidence below, and MUST do so before seq reaches 2^23 - 2^20 in epoch e (Section 12.4). Policy MAY also advance on a time or volume threshold.¶

• Evidence. An endpoint MUST NOT advance its sending epoch from e to e + 1 unless it holds a PROBE_ACK for a PROBE it sent in epoch e (Section 19.2). The acknowledgement proves that the peer accepted a packet of epoch e and therefore that the peer's receive epoch is at least e, so that e + 1 is in the peer's permitted set (Section 14.2). A packet the peer sent in epoch e is not sufficient evidence, because the peer may have advanced to e on its own without having accepted any packet of e; without this rule two unilateral advances with lost packets in between leave one direction unable to accept the other's epoch.¶

• First epoch of a generation. The evidence is asymmetric. For the responder of the anchor exchange, the packet that committed the generation (Section 16.4) is the evidence: it proves the requester receives under g. For the requester, the response proves only that the responder derived g, not that it committed it, so the requester sends a PROBE in epoch (g, 0) as soon as it commits and repeats it at the probe interval until the PROBE_ACK arrives (Section 9.3.8); until then it holds no evidence and does not advance. The probe is also what commits the generation at a responder that has not yet seen requester data.¶

• An endpoint that accepts a packet in epoch e + 1 while its sending epoch is e MUST set its sending epoch to e + 1 before transmitting its next packet. Both directions therefore move together, and either endpoint can initiate.¶

• Probe on every advance. Whenever an endpoint's sending epoch changes, by its own decision or by following a received packet, it MUST send a PROBE in the new epoch, and MUST repeat it at the probe interval (Section 15) until acknowledged. The probe is at once the packet that confirms to the peer that the advance was followed and the evidence the endpoint needs before its own next advance. If every path is lost while the acknowledgement is owed, the probe resumes when the session has a usable path again, whether it returns by a path or by a re-anchor.¶

• If the per-epoch limit is reached without evidence, the endpoint MUST stop sending in that lineage and recover by re-anchor (Section 16).¶

• Advance within a lineage is by epoch chaining (Section 14.3). Advance to a new lineage is only by re-anchor (Section 16); epoch_index resets to 0 and lineage_gen increments there.¶

14.2. Receiver Rules and the Permitted Set

For each direction and each lineage it holds keys for (the current one, an armed or paused one, and a retiring one during lineage_grace, Section 16.4), an endpoint has a receive epoch r and a permitted set of epochs that the pre-authentication filter (Section 11.3) accepts:¶

permitted(direction) = { r }
                     U { r + 1 }   if epoch_index(r) < 0xFFFF
                     U { r - 1 }   while the overlap of r - 1 lasts

• A packet naming r + 1 is decrypted with the keys of r + 1, derived on first need (Section 14.3). AEAD success advances the receive epoch (Section 14.4).¶

• A packet naming an epoch outside the permitted set is dropped by the filter. No key is derived for it.¶

• A receiver MUST NOT advance its receive epoch on any basis other than a successful AEAD under the keys of r + 1. In particular, observing r + 1 in an unmasked block is not evidence of anything (Section 11.7).¶

14.3. Key Derivation

epoch_secret(lineage, 0) =
    HKDF-Expand(lineage_secret, label("epoch 0"), 48)
epoch_secret(lineage, k + 1) =
    HKDF-Expand(epoch_secret(lineage, k), label("epoch step"), 48)

Traffic keys and IVs for each direction are derived from epoch_secret as defined in Section 8. Header-protection keys are per lineage and are not re-derived at an advance.¶

• Keys for r + 1 MAY be derived in advance or on first need. They MUST be derived at most once and retained until the epoch leaves the permitted set.¶

• epoch_secret(lineage, k) MUST be erased as soon as epoch_secret(lineage, k + 1) has been derived and epoch k has left the permitted set. Compromise of the value epoch_secret(lineage, k + 1) alone, without lineage_secret, then reveals nothing about epoch k. Compromise of the endpoint reveals lineage_secret, which is retained until the lineage is retired (Section 8.8) and from which every epoch secret of the lineage is derived, so the erasure of an epoch secret does not hide that epoch's traffic from a later compromise of the endpoint. Forward secrecy of a generation's traffic against compromise of the endpoint begins when that generation is retired and its cs and lineage_secret are gone.¶

• Epoch chaining does not protect later epochs from compromise of an earlier one. Post-compromise security within a session comes only from the fresh KEM secret of a re-anchor (Section 16); policy MAY perform a re-anchor on a live path for that purpose.¶

14.4. Receive Epoch Advance and Overlap

When a packet naming r + 1 authenticates:¶

1. Commit the packet's replay check in the window of r + 1 (Section 13.4).¶

2. Set the receive epoch to r + 1.¶

3. Start the overlap period for the previous epoch, ending first any overlap still active for the epoch before it, whose keys and window are erased (Section 14.5). During it, packets naming r (now r - 1) remain in the permitted set, so that in-flight packets reordered across the advance are not lost.¶

4. Apply the sender rule of Section 14.1: set the sending epoch to r + 1 if it is lower, and confirm.¶

The overlap period is local to the receiver, is not negotiated, and MUST be bounded by time or by a packet count. A RECOMMENDED bound is the larger of two round-trip times and W packets received in the new epoch. Longer overlap periods extend the lifetime of the old keys and nothing else.¶

14.5. Erasure

When the overlap period ends, or immediately if no overlap is used:¶

• the previous epoch's keys, IV and epoch_secret MUST be securely erased;¶

• its replay window MUST be discarded (Section 13.6);¶

• it leaves the permitted set, and no packet naming it can be accepted again.¶

Keys of an epoch that has not yet been reached (r + 1) are retained until that epoch is reached and then subject to the same rules.¶

14.6. Properties

• Zero cost. An advance is signalled by the epoch field of the next packet, which is masked. An observer cannot see when it happens (Section 24).¶

• Bounded divergence. A sender is never more than one epoch ahead of the peer's receive epoch, the peers' sending epochs differ by at most one, and a receiver holds keys for at most three epochs per lineage. A new lineage's first epoch is entered by the commit of its generation (Section 16.4), not by the advance rule.¶

• No negotiation. There is no rekey frame, no arming step and no overlap extension; the only control traffic involved is one PROBE and its acknowledgement per epoch and direction.¶

• Symmetric. Either endpoint advances; neither is authoritative.¶

15.1. Identifiers

Every protected packet carries, as its routing key, an identifier of the endpoint that receives it (Section 10.1.2). Identifiers are derived, not issued:¶

rid(g, dir, j) = prefix(dir) ||                      ; Section 8.5
    Expand(lineage_secret(g), label("rid") || dir(1) || j(4),
           8 - len(prefix(dir)))

• Prefix. prefix(dir) is zero to two octets chosen by the endpoint that receives in direction dir, delivered once in its sealed part of the FRESH exchange (Section 9.2) and fixed for the session. It is the operator's routing hook: a gateway group gives each gateway its own prefix so that an external balancer can route by it without state (Section 16.9). Identifiers that share a prefix are known to reach the same receiver, an anonymity set of that receiver's sessions (Section 24). A single endpoint uses no prefix. A prefix also sizes the namespace the sessions behind it share: with a two-octet prefix the random part of an identifier is 48 bits, with the collision rates given at the end of this section.¶

• Index. j is a 32-bit index. When the sender opens a new path it assigns the lowest index it has not yet used in this generation and direction; the identifier stays with that path for the path's life. A path's identifier is never reused on another path, and a NAT rebind (Section 15.3) keeps the identifier. When a new generation is installed, armed or committed (Section 16.4), the sender assigns that generation's indices to the paths that exist at that moment, from 0 in the order of their previous indices, and continues from there for paths opened later; the assignment stands when the generation commits, so that nothing sent under the generation while it was armed (early data, the confirmation probe) is renumbered and no index is used twice within a generation. The receiver learns the index the peer uses on each path from the packets that arrive on it, generation by generation: at a new generation every path's peer index is unknown again until a packet arrives, because the two endpoints' views of which paths still exist can differ. A receiver MUST NOT infer the peer's new numbering from the old; a wrong inference takes a packet from a new address for a rebind of the wrong path and sends that path's identifier to an unrelated address (Section 24.3).¶

• Window. When a generation is installed, and after each use of an index, the receiver installs in its lookup table the identifiers of the k = 8 lowest unused indices for its receive direction, so that the next eight paths the sender may open are always resolvable. Because the sender always takes the lowest unused index, the receiver's installed set is exactly the set the sender may use next. An identifier whose path has been lost or abandoned is removed from the table path_retire after the loss; an index below the lowest in use is never reinstalled.¶

• Within the window. The sender keeps within that window: an index with eight or more lower indices on which the peer has never acknowledged a packet could not be resolved there, so a sender that would need one re-anchors instead, which assigns the live paths indices from 0 again, and repeats that re-anchor on the recovery schedule until a generation commits, through an attempt that fails or one that could not start while another was outstanding; a path that is LOST when a generation is installed receives no index under it and takes the next one if it revives. The check applies to the numbering a generation commits with as well as to a new path: a path opened while a generation is armed takes the generation's next index, and if at the commit that index has eight or more unacknowledged indices below it, the sender re-anchors then. It does so only when fewer than eight live paths precede that path, since otherwise the new numbering would give it an index just as far out, and the paths' liveness (Section 15.3) has to retire some first. Reusing the index of a retired path was considered and not adopted: the identifier would be sent to a new address after an old one, which Section 24 forbids.¶

• Installation. Identifiers enter the table only at installation, never because a packet carried them (Section 11.2). Each entry maps to the session, the generation (which selects the header-protection key) and the direction.¶

• Collision. A derived identifier that is already present in the receiver's table, for any session, is never installed: the generation that would carry it is replaced before it is used, by whichever endpoint can replace it at no cost on the wire. The responder of a FRESH or CONTINUE request, whose encapsulation fixes the lineage, encapsulates again before arming (Section 9.3.2 and Section 9.3.3). The responder of a CONTINUE_0RTT request, whose lineage the requester fixed, answers RETRY IDENTIFIER_COLLISION, which consumes the prekey, and the requester repeats with a new request (Section 16.3.2). A requester that finds the collision when a FRESH or CONTINUE response opens adopts nothing and sends a new request for the same generation, which the responder serves afresh (Section 9.3.8 and Section 16.4); a CONTINUE_0RTT requester finds it before sending and encapsulates again. The same rule covers the recovery identifier (Section 16.2).¶

• Collision in a live generation. An identifier that collides as the window slides, or in a generation restored from the record (Section 16.6.2), is skipped and the session re-anchors at once, which derives a new set (repeated until a generation commits); the peer's packets on that index are lost until the new generation, which the inner transport absorbs. Re-anchoring only once the colliding generation had committed would wait on the peer's recovery schedule: when the colliding index is the peer's only path, the commit needs a packet on that very index.¶

• Recovery identifiers are the separate derivation of Section 16.2 and follow its rules.¶

Nothing is signalled to allocate, retire or replace an identifier, there is no exhaustion, and after a restart an endpoint recomputes every identifier of the generations it re-creates from the record (Section 12.7).¶

Rates. With a two-octet prefix the derived part of an identifier is 48 bits. A population that installs eight receive identifiers per session has, by the birthday bound, about one chance in 90,000 of a collision somewhere among 10,000 sessions, about one in 900 among 100,000 and about one in nine among 1,000,000; a large gateway installing 10^8 identifiers a year meets one about once in three years; with no prefix it does not happen in practice. A collision is detected and resolved as above and costs one exchange, so these are rates of that event, not failures of a session or of confidentiality. A deployment with very large populations distributes receiver prefixes so that no one 48-bit namespace carries them all, and measures the collision rate in its scale tests.¶

15.2. Path State

Per path, an endpoint holds: the local and remote addresses; the identifier index in use for sending and the identifier last seen from the peer; a state, CANDIDATE, VALIDATED or LOST; a local handle path_id (one octet, carried in PROBE frames and echoed by the peer; Section 19.2); the liveness timer and unanswered-probe count; a smoothed round-trip estimate; the path's MTU (Section 15.5); and the outstanding probes, each with its challenge, the time it was sent and the sending epoch it went out in (Section 14.1), MTU probes apart from liveness probes. The budget of Section 15.4 is held per remote address, not per path. Each endpoint numbers and validates paths independently; the same pair of addresses is, to each endpoint, its own path object.¶

Path state is created, changed and discarded only after a packet has authenticated (Section 11.4, step 13) or by local decision; no unauthenticated input touches it.¶

15.3. Candidate Paths and Validation

A candidate path arises when:¶

1. an authenticated packet of the session arrives from an address pair not currently a path. If its identifier's index has been seen in this generation on another path, this is a rebind of that path (the peer's address changed under it, as a NAT does); if the index has not been seen in this generation, it is a migration or an additional path the peer opened (Section 15.1);¶

2. a local source supplies an address: configuration, the previously validated addresses, or an upper layer acting as rendezvous (externally supplied hints);¶

3. a CONTINUE request arrives from a new address (Section 16.3);¶

4. an anchor response arrives from an address pair other than the one its request was transmitted to (Section 9.3.8).¶

Validation. An endpoint validates a candidate by sending a PROBE on it; the matching PROBE_ACK, on whichever path it arrives, proves that the peer receives at that address and answers. On validation the path becomes VALIDATED and joins the session's set (Section 15.7); a rebind replaces the old address of its path, which stays in use until then, and a candidate whose rebind address validates becomes VALIDATED at it. A packet owed to the rebind address, such as the PROBE_ACK to a probe from it, is sent through that path. Each endpoint validates in its own direction; the peer's PROBE on the same addresses is the peer's validation, and answering it is required by Section 19.2 regardless of the local path's state.¶

Probes. The probe is repeated at the probe interval, doubling to probe_max, until the acknowledgement arrives or k_probe probes have gone unanswered, after which a new path is discarded and a rebind keeps the old address (Section 18.3); a probe that cannot be sent, because no generation can send yet, counts for nothing. The probe interval is at least twice the path's smoothed round trip and at least twice the session's exchange floor (Section 16.7), the time its last anchor exchange took, since a probe's acknowledgement waits in the same queue as that exchange did.¶

Revival. A LOST path whose address sends an authenticated packet or an anchor message is a candidate again and earns one probe per packet received, keeping its count, so that an address that sends but never answers costs at most one probe per packet. A LOST path whose address pair a local source supplies again (a link that came back) is a candidate again with a full probe count and is probed at once: a locally supplied address earns its probes, unlike one revived by a packet.¶

Previously validated addresses. Each session keeps a bounded set of peer addresses it has validated, with validated_ttl. A candidate whose address is in the set is VALIDATED immediately. This is what lets both directions of a CONTINUE_0RTT re-anchor flow at once when a device returns to a known network. The lifetime is short because the set weakens the reflection bound for exactly its duration: an authenticated peer could claim an address it recently held. The set is part of the continuity record (Section 16.6.1), so it survives dormancy and a restart, and a session that supersedes this one inherits it (Section 16.7). Only a validated address becomes the address the peer was last seen at, which recovery attempts and anchor requests are sent to (Section 16.7); a candidate's address is relied on for nothing but the budgeted probe toward it and its place in the recovery rotation (Section 16.7).¶

Until validated, sending on a candidate is limited by Section 15.4. Receiving on it is not limited: authenticated packets are processed normally whatever path they arrive on, because the replay window and the keys belong to the session (Section 13.1).¶

A NAT rebind keeps the identifier and is therefore linkable by an observer to the path it rebinds; a migration uses a new identifier and is not. Section 24 states both.¶

15.4. Budget for Unvalidated Paths

Until an address is validated, an endpoint MUST NOT send toward it more octets than it has received from it, and MUST NOT send more packets toward it than it has received from it, with one exception, the probe floor: k_probe probes of 56 octets toward the address outside the budget. The budget belongs to the endpoint, per remote address: every session, path and rebind toward that address shares one budget and one probe floor, because the bound protects the address, not the path or the session, and Section 22 states it for the endpoint (two sessions with one peer would otherwise each spend the floor). It applies to whatever path a packet toward the address is sent on; only a VALIDATED path to its own address, or a previously validated address within validated_ttl, sends unbudgeted. It is lifted when any path to the address validates, and forgotten after budget_ttl (default validated_ttl) without use, so the floor is k_probe probes per address and interval; the table is bounded (max_budgets, default 65,536) and the least recently used entry is forgotten beyond the bound.¶

Forgetting is an accounting boundary. An address forgotten for room, rather than for its interval ending, with its floor spent, obtains no second floor before its interval ends; an endpoint keeps the floors it has spent for such addresses, bounded like the table, and grants no floor to a new address while that memory is full, so that churning the table with claimed addresses yields no floor an address would not otherwise have had.¶

PROBE_ACK frames owed under Section 19.2 and the endpoint's own PROBE are sent first within the budget; application data follows only if budget remains. Anchor requests an endpoint initiates, a first FRESH to a configured address or a recovery attempt to an address of the rotation (Section 16.7), are outside the budget: their number and spacing are bounded by the retransmission schedules of Section 9.4 and Section 16.7, and only a holder of the request's keys can make the request draw a response. The floor exists because two endpoints that are each other's candidates, as after a migration on both sides, have each received nothing from the other's new address and could otherwise never send the first probe.¶

The reflection ratio toward any address a peer claims is therefore at most one beyond the floor of k_probe x 56 octets, by the same accounting as the anchor exchange (Section 9.5). An authenticated but malicious peer that claims a victim's address can make the endpoint send the victim at most what the peer itself sent from that address, beyond that floor. The cost is that a peer that moves without keeping its old path waits one round trip before it receives more than it sends; with the old path still live, or with the previously validated addresses, there is no wait.¶

15.5. Path MTU

Every path starts at initial_path_mtu, 1,200 octets by default (INITIAL_PATH_MTU, Section 10.2.3), which crosses the IPv6 minimum MTU with room for outer encapsulation. The procedure below only raises a path's MTU from that start and returns it there; it never searches below it. A deployment whose paths carry less, an encapsulation or a radio link with a smaller datagram budget, configures a lower initial_path_mtu for its endpoints (Appendix F), not below 576 octets, so that its protected packets fit from the first; the anchor messages cross such paths in fragments of MIN_FRAGMENT (Section 10.4), and a receiver accepts any size up to its local maximum, so the start is each sender's own choice and no negotiation. Section 1.5 states this as a limit of applicability.¶

An endpoint MAY raise a validated path's MTU by probing: it sends a PROBE in a protected packet padded (Section 10.2.2) to a candidate size; the matching PROBE_ACK confirms that the candidate size traverses the path, and the path's MTU becomes that size. A probe that is not answered within the probe interval, twice, means the size does not traverse; the endpoint tries a smaller one. A reasonable search is the local interface MTU less headers (1,452 octets on Ethernet), then halfway between the last failure and the last success, stopping when the gap is under 32 octets. The MTU never exceeds what the local interface can send, and an endpoint that does not know its interface MTU does not probe. MTU probes are accounted apart from liveness probes: an MTU probe that goes unanswered twice at a size fails that size and says nothing about the path, and no other packet disturbs the search.¶

An endpoint confirms a raised MTU every mtu_reprobe with one probe at the current size; after k_probe consecutive failed confirmations at that size while the path's liveness is intact (its small packets are still answered), it returns the path to INITIAL_PATH_MTU and may search again later. This is the model of [RFC8899], implemented with the frame of Section 19.2 and no other mechanism; receivers need nothing, because they accept any size up to their local maximum.¶

The MTU is per path and survives a re-anchor on the same address (Section 16.4). Raising it from 1,200 to 1,452 octets increases the payload per packet from 1,156 to 1,408 octets, about 22 % fewer packets for bulk traffic.¶

15.6. Liveness

Liveness is a per-path policy with two modes.¶

• Active. If no authenticated packet has arrived on the path for T_idle, send a PROBE on it. If k_probe consecutive probes go unanswered, spaced by the probe interval, the path is lost: state LOST, event PathLost. Any authenticated packet on the path resets the timer and the count. Under the defaults a path is lost about 22 s after the last packet.¶

• Passive. No probe is sent for silence alone. When the endpoint sends on the path after a silence longer than T_idle and nothing arrives within the probe interval, it probes as in the active mode; loss is detected only when there is something to send. A battery-powered device chooses passive; a gateway active.¶

Receipt refreshes liveness in both modes, so a path that carries traffic in either direction is never probed. A peer that has gone DORMANT answers nothing, because it holds no keys under which to authenticate what arrives (Section 16.7); its silence is what liveness detects, and the session recovers by re-anchor.¶

Network address translation. An endpoint that wants to remain reachable inbound through a translator sends on each such path at least once per binding lifetime, 25 s being the customary bound; a PROBE serves. An endpoint that does not need inbound reachability lets the path idle, in either mode. The session is unaffected by the choice: at worst the path is lost and the session recovers on the next send (Section 16.7). Keepalive traffic is a reachability choice, never a session requirement.¶

Consequences of loss. Losing a path discards that path's state after path_retire and nothing else. If it was the session's last usable path, candidate or validated, the session enters RECOVERING (Section 16.7); otherwise sending continues on the remaining paths. A lost path is the ordinary case in the environments this protocol is for; it is never an error.¶

15.7. Multiple Paths and the Sender's Choice

A session holds any number of validated paths up to max_paths, each with its own identifier index. Which path carries which packet is the sender's policy and outside this document: a primary with the others as standby, round-robin, lowest round-trip time, or redundant transmission, in which the same packet is sent on several paths. Redundant copies are one encryption of one packet, identical in every octet except the routing key, which is each path's own identifier; the associated data excludes the routing key for exactly this purpose (Section 10.2.2), so no second AEAD operation and no second nonce is involved.¶

The receiver accepts the first copy and discards the rest through the replay window (Section 13.1), and no further mechanism exists or is needed. When paths with different latencies are in use, the window sizing rule of Section 13.2 applies. A sender that treats one path as primary moves the primary to another validated path when the peer's packets arrive on that path while the primary has received nothing for longer than a probe interval and a probe on the primary is unanswered.¶

Adding a validated path reports PathAdded, the first time and again when a path that was lost is revived and validated once more, so that a layer above learns that a RECOVERING session is back on a path; a change of the path the sender treats as primary reports PathChanged; loss reports PathLost. All are transport-class events (Section 3) and change nothing above the path. Four rules shape the set a sender chooses from:¶

• The new generation's path is preferred. Once a path is validated on which the peer has sent under the current generation, a sender that keeps a primary SHOULD prefer it over a primary that has received nothing since that generation committed: the peer re-anchored from there, after a restart on a new port or a migration, and is there now. The condition is checked when the path is validated and again when the generation commits, since either can come second: a CONTINUE_0RTT responder commits on a PROBE_ACK that has just validated the path while the previous generation was still current (Section 16.4). Between two validated paths the same preference applies when the peer's packets arrive on one while the primary has received nothing for longer than a probe interval and a probe on the primary is unanswered: the peer has moved, and the sender follows it (PathChanged) rather than sending into silence until the old path's liveness fails.¶

• A response validates the address its request was sent to. An anchor response validates, at the requester, the address pair the request was transmitted to, when the attempt went to one pair only: the request is the challenge and the response its answer, as a PROBE_ACK answers a PROBE, with a transcript only the peer could complete (Section 9.3.8). The response's source address is not validated by the response: an authenticated response proves possession of the exchange's secrets, not that the peer receives at the address the datagram claims to come from, which any sender on the path can set. A source that differs from the request's destination is a candidate, probed and budgeted (Section 15.3). The responder's side is unchanged: the request's source stays a candidate until its probe is answered, since a request can be replayed from any address.¶

• A path is an address pair. Two paths may share the peer's address and differ in the local one (two interfaces toward one server); the local address a packet arrived on selects among them, before the peer's address alone.¶

• A path is also lost by local decision. An endpoint whose interface or address goes away withdraws the paths from it at once, with no probes, since the host knows what no probe can tell it sooner; an address whose path has been lost leaves the previously validated set, so that a recovery attempt toward it makes no validated path without proof.¶

15.8. Paths and Everything Above Them

• A path through a third party that forwards datagrams by their routing key is, to both endpoints, an ordinary path (Section 10.1.2); an endpoint may give such a forwarder its next identifiers in advance, since it can compute them.¶

• A path that survives a re-anchor with its address unchanged keeps its validation, MTU and liveness state (Section 16.4); only the identifiers used on it change.¶

• When both endpoints have moved, neither can reach the other without an externally supplied address (candidate source 2 in Section 15.3); how an upper layer supplies one is outside this document.¶

• No path event creates, extends, revokes or refreshes authorization, generation, exporter values or any upper-layer binding.¶

16.1. Overview

Lifetimes. Five levels of state, each outliving the next (Section 3):¶

An event at a shorter-lived level never invalidates state at a longer-lived one. Losing every path starts the session's recovery, and, if recovery does not reach the peer, makes it DORMANT; it does not end it.¶

Re-anchor is the anchor exchange performed from an existing session. It is one mechanism with six uses: recovery after the last path is lost; survival across a restart; the post-compromise ratchet (Section 16.8); identity re-proof on demand; renewal of identifiers; and renewal of the lineage when epoch_index is exhausted (Section 12.2). It costs one round trip, or none with a prekey, and about 1.7 KB of anchor messages in each direction; the measured cost of a recovery, with fragmentation, retransmission, confirmation and path validation, is a matter for Section 27.¶

Policy parameters used in this section, with defaults. None is negotiated; each endpoint applies its own.¶

16.2. Recovery Identifiers

rec(g, dir) = prefix(dir) ||                         ; Section 8.5
    Expand(cs(g), label("recovery") || dir(1), 8 - len(prefix(dir)))

• Both endpoints compute both directions' recovery identifiers when generation g is installed, and each installs in its lookup table the one for the direction it receives on. The entry is retained while the session is live and while it is DORMANT: it is how a dormant session is found. It is removed when generation g is committed as superseded (Section 16.4) or the session is closed.¶

• A recovery identifier is the routing key of a CONTINUE or CONTINUE_0RTT request sent in direction dir while generation g is current. The response travels on resp_rid(g, dir', nonce) (Section 8.5), a key that exists for the attempt only. Neither is used for any other packet: a recovery identifier is never a data identifier, it is not transmitted before its use, and it cannot be linked to the session's data identifiers by anyone without cs(g).¶

• It is single-use. Once a request on rec(g, dir) has created generation g + 1 and that generation is committed, the identifier is stale: it stays in the table for reply_cache_ttl, answers a byte-identical retransmission of the request it served with the cached response, and answers nothing else (Section 16.4). Any other request on it is handled by Section 16.5.¶

• A receiver that finds a recovery identifier already present in its table on installation applies the collision rule of Section 15.1.¶

16.3. The CONTINUE Forms

16.4. Commit, Crash Consistency, and Simultaneous Re-Anchor

This section states the rules of an anchor exchange after the request is built: what is written before what is sent, when a generation becomes usable, what happens to an attempt that is overtaken, and how two endpoints that re-anchor at once settle on one generation.¶

• Write-ahead, requester. Before transmitting a CONTINUE request the requester persists everything needed to retransmit it byte-for-byte and to continue afterwards: target_gen, nonce, the request's octets and transcript hashes, ss_peer when it carries prove_peer, and either dk (CONTINUE) or cs(g) and lineage_secret(g), which a CONTINUE_0RTT request derives before it is sent, and the time of the request's first transmission, from which the attempt's life is measured (Section 16.7), across a restart too. cs(g - 1) is kept until generation g is committed. Every record written while the request is outstanding, for whatever reason, carries it, so that no later write loses the attempt; a restart retransmits it.¶

• Write-ahead, responder. Before transmitting a response, FRESH or CONTINUE, the responder persists the armed generation and the response it is about to send (the reply-cache entry of Section 9.4), so that a restart neither loses a generation the requester may have committed nor fails to answer the requester's retransmission. In FRESH the freshness counter (Section 9.3.5) is not advanced by this write but by the one that commits generation 0, on confirmation.¶

• The write's cost. The write is the cost of a request that opens, one decapsulation deep and bounded by the half-open table per source and per claimed identity (Section 9.4 and Section 23), and it stays: without it a responder restarting between its response and the confirmation loses an exchange the requester has committed, and the requester's recovery from a generation its peer never held is the slow path of Section 16.7.¶

• A failed write at the responder. If the write fails, the responder sends nothing and discards the generation it was about to arm and every piece of state the arming changed: the armed slot, the reply cache, the served attempt number and a prekey the request consumed; it serves the request when it is retransmitted. Each generation holds its own copies of cs and the lineage secret, and a discarded generation is referenced by nothing. A generation that a new request displaces (re-serving, below) goes only once its replacement is written. The prekey a CONTINUE_0RTT request consumed is erased in the same write (Section 16.3.2), and an issuer that regenerates prekeys records it consumed in that write, so that a restart cannot bring it back or regenerate it; a later request naming it is answered PREKEY_UNAVAILABLE.¶

• Durable commit. A generation is committed at an endpoint only when the record that resumes it is durable; the cryptographic work that precedes the write, opening a response or authenticating a confirming packet, prepares the generation and commits nothing. Keys and identifiers derived before the write are provisional: no packet is processed under them, nothing is sent under them, and nothing externally visible depends on them until the write holds; an implementation whose dispatch could reach them before then defers the packet.¶

• A failed commit write. When the write fails, the endpoint keeps or rebuilds what it needs to attempt the commit again, in memory or from the write-ahead record, and does not activate the generation. The requester keeps its attempt outstanding and its decapsulation key, uninstalls the provisional identifiers, and commits on the cached response its retransmission obtains (Section 9.3.8). The responder, whose armed generation was already durable, keeps it armed and drops the confirming packet undelivered, its sequence number consumed, so that the next packet under the generation, the requester's repeated confirmation probe or its data, commits; a failed write therefore consumes one packet, never the only event that could complete the commit.¶

• Delivery before durability. Nothing is delivered under a generation whose commit is not durable, except the early data of a CONTINUE_0RTT, whose standing Section 16.3.2 gives. The reference implementation is one serialized state machine, so the interval between deriving and committing is never observed; the rule is stated for implementations that are not.¶

• Arm, then commit. The responder installs generation g armed when it sends the response: its keys and identifiers exist, generation g - 1 is untouched. It commits, by the write of the durable-commit rule above, on the first packet of any kind that authenticates under g, data, a PROBE, a PROBE_ACK or an OBJECT, except under a generation a CONTINUE_0RTT request armed, which only a PROBE_ACK to a probe sent under g commits (below), and on a request on rec(g, .) that opens under cs(g) (the peer has committed g and asks for g + 1; the responder commits g first and then serves). On commit it persists cs(g) and the new record, for generation 0 of a FRESH with the requester's freshness mark (Section 9.3.5), then erases cs(g - 1), removes rec(g - 1, .) from the live table (it becomes stale, below), and retires lineage g - 1 after lineage_grace.¶

• Evidence for an armed generation. Only a packet that authenticates under the armed generation is evidence for it: early data under a generation a CONTINUE_0RTT request armed is delivered but commits nothing, since the requester may have abandoned that request and may hold another generation with the number; an acknowledgement that opens under the current generation says nothing about the peer's lineage, whichever probe it answers. A session with no committed generation, as after dormancy, sends its probes and their answers under the peer's armed generation for the purpose. The confirmation probe goes on the path the request arrived on, candidate or validated.¶

• The requester's commit. The requester commits, by the same write, when the response opens, or, in CONTINUE_0RTT, on any packet that authenticates under the armed generation; it persists cs(g) and the new record before erasing cs(g - 1). A commit that cannot be persisted adopts nothing: the responder keeps the generation armed and the requester keeps the attempt outstanding, and each is retried on the next packet or response.¶

• One armed generation. A session holds at most one armed generation at a time, whichever role created it, together with at most one paused generation of its own (simultaneous re-anchor, below). While the peer's generation for the next number is armed, the endpoint makes no request of its own for that number: the attempt waits for the peer's generation to commit on the peer's packets, or to expire unconfirmed, and proceeds then. While its own 0-RTT generation is armed, the peer's request for the same number is resolved by the simultaneous rule below.¶

• Retirement. Retiring a lineage discards its epoch keys, replay windows and data identifiers after lineage_grace. Paths survive: a path whose address is unchanged is the same path under the new generation, keeps its validation and MTU state, and changes only the identifiers used on it, assigned when the generation was installed, from index 0 in the order of the previous indices (Section 15.1). A re-anchor on a live path never re-validates anything.¶

• Idempotent retransmission. A byte-identical retransmission of an answered request is answered from the reply cache (Section 9.4) on the attempt's resp_rid, for reply_cache_ttl, before and after commit: from the original source address without condition, from another address within the reflection budget of Section 15.4 toward it.¶

• Stale identifiers. After the commit the identifier the request arrived on, rec(g - 1, dir) or the handshake identifier, is stale: it stays in the table for the same period and answers that retransmission and nothing else; any other datagram on it is dropped without a response, a public key operation or a state change, because on a stale identifier an unauthenticated datagram may cause no transmission but the cached reply (Section 11.7). A requester that crashed after receiving the response but before persisting cs(g) recovers this way: it rebuilds the request from its write-ahead state and receives the same response.¶

• Re-serving an uncommitted generation. A request on rec(g - 1, dir) with target_gen = g, different contents and a higher attempt (Section 9.3.3), arriving while generation g is armed but not committed, replaces the armed generation once it has opened under cs(g - 1): the responder discards the earlier cs(g), which no one else can use, and serves the new request. An unauthenticated request never displaces an armed generation, because the peer may already hold it committed and an observer of the identifier could otherwise strand the session. A committed generation is never re-served; such a request is dropped (Section 16.5). This keeps the no-forking invariant in its usable form, no two usable generations with the same number, while giving a requester whose first attempt was lost a way to continue.¶

• Abandoned attempts. A requester that abandons an attempt, including by yielding under the simultaneous rule, discards its write-ahead state for it and writes the record without it, so that a restart does not resurrect the attempt beside the exchange it yielded to; a CONTINUE_0RTT attempt sent under is abandoned only by yielding to a crossing CONTINUE_0RTT, the one exception (Section 16.3.2), an abandonment written out of the record like any other.¶

• The life of an armed generation. The responder's armed generation lives exactly as long as the cached answer that creates it, and every retransmission the cache answers renews both: anchor_timeout for the generation of a CONTINUE, whose attempt ends within that time by the rule of Section 16.7, replaced by the schedule or abandoned at the end of its own life, across pauses and restarts, and reply_cache_ttl for the generation of a CONTINUE_0RTT, whose attempt is kept and retransmitted. An unconfirmed generation and its answer therefore go together, when the requester has been silent for that long.¶

• The reserved number. The answer to a CONTINUE_0RTT may outlive them, held in the network, and still complete the kept attempt it answers: a responder whose generation armed by a CONTINUE_0RTT request expires unconfirmed therefore keeps the number reserved, making no request of its own for it, until it commits a generation with that number or serves a later attempt for it, which shows the requester gave the 0-RTT attempt up. The reservation is kept in the record. It never holds recovery: a session that may not request the number follows its recovery schedule, whose FRESH attempts take no number (Section 16.7).¶

• Superseded attempts. A commit of generation g while the endpoint's own request for g is outstanding supersedes that attempt: the request and any generation it armed are discarded, because the number is taken by a generation both sides hold. The superseded attempt is reported as ReanchorFailed{superseded} only if it carried prove_peer or offer_proof, since the proof it sought was not obtained; otherwise ReAnchored for the committed generation is the whole report.¶

• Simultaneous re-anchor. Both endpoints may request the same generation g at once. The roles of the handshake decide, so that no comparison and no message is needed:¶

  • The initiator whose own attempt is a CONTINUE yields to the peer's request, in either form: once the peer's request has opened under cs(g - 1), and before any of its own write-ahead state is replaced, it abandons its own attempt, cancels its retransmissions, and serves the peer's request. An initiator whose own outstanding attempt is CONTINUE_0RTT does not yield: the requester of a CONTINUE_0RTT fixed the lineage of g itself and has sent under it, so the peer may hold that generation already or commit it on the next acknowledgement; it drops the responder's crossing request unopened and keeps retransmitting its own.¶

  • The responder does not yield while its own attempt is young: it drops the peer's request before opening it and keeps retransmitting its own. Once its requests for the number have been transmitted three times without an answer, the peer's request, which did arrive, is the one that can complete, and the responder serves it too. The count is per target number and survives the attempts the recovery schedule replaces; an attempt restored from the record after a restart counts as transmitted three times already, and keeps its age (Section 16.6.2). Serving a crossing CONTINUE, the responder pauses its own attempt rather than abandoning it: no further retransmission, but the response slot and the generation the attempt armed stay, receive-only, because the initiator may have served that request and its answer may still be in flight; the paused attempt completes if the answer arrives, is superseded by whichever commit settles the number first, and otherwise waits for anchor_timeout, the life of the generation it yielded to, within its own life (Section 16.7): a kept CONTINUE_0RTT attempt is then retransmitted, a CONTINUE attempt is abandoned when its life ends and the next attempt is a new one. Serving a crossing CONTINUE_0RTT, the responder abandons its own attempt instead, its generation with it: the initiator never serves a crossing request while a 0-RTT attempt of its own is outstanding, so nothing can complete the responder's attempt and nothing holds its generation.¶

  • Whichever answer arrives first completes the surviving attempt; a commit of g supersedes the other attempt and discards the generation it armed, as above. Requests for different generations are not simultaneous: one of them commits a generation the other targeted, and the superseded rule applies.¶

• Response routing. A response travels on resp_rid(g - 1, dir', nonce) (Section 8.5), which the requester installs for the attempt and removes when the attempt ends. A response to an attempt that has ended, a replayed response, and a response from a tombstone (Section 19.6) are all routed, or not, by that key alone.¶

16.5. Generation Rules

• target_gen in a request MUST equal the responder's current generation plus one, except as Section 16.4 allows for an uncommitted generation. A request with target_gen at or below the current generation is answered from the reply cache if it is byte-identical to a cached request (Section 9.4; from another address within the budget of Section 15.4), and dropped otherwise. A request with target_gen more than one ahead is dropped.¶

• A responder never regresses: having committed generation g, it never again accepts a request that would create g or any lower generation, and it refuses any sealed record whose generation is lower than one it knows for that session (Section 16.6).¶

• lineage_gen in the epoch identifier is the generation. If a re-anchor would make it exceed 0xFFFF the session is closed with SESSION_LIFETIME (Section 12.2) and a new handshake performed; at the default reanchor_interval this is seven and a half years.¶

16.6. The Continuity Record

16.7. Dormancy and Recovery

The next recovery transmission. For an endpoint that is RECOVERING or DORMANT and whose next attempt is due, the transmission is decided in this order. The paragraphs that follow give the reasons and the details, citing these steps, and Section 9.3, Section 9.4, Section 16.3 and Section 16.4 the mechanisms each step relies on; Section 18 names the states and does not repeat this list.¶

1. A CONTINUE_0RTT attempt under whose generation the endpoint has sent is kept and retransmitted by the schedule, in DORMANT too and across a restart, with the FRESH attempts of the schedule proceeding beside it; it ends only when the responder answers it, with RESPONSE, RETRY or CLOSED, when it yields under the simultaneous rule of Section 16.4, or when the session closes (Section 16.3.2).¶

2. A CONTINUE attempt whose response has begun to arrive, a fragment of it reassembled, is granted up to two further intervals for the rest of it and no more than its life: anchor_timeout from its first transmission, across pauses and restarts. A response completed after that life commits nothing (Section 9.4).¶

3. Any other outstanding CONTINUE or FRESH attempt is abandoned without a report when the next attempt is due, and a CONTINUE attempt is abandoned at the end of its life whatever the schedule's interval; a paused attempt (Section 16.4) waits for its answer for anchor_timeout, and an attempt withheld because the peer's generation for the number is armed waits for that generation to commit or expire, at most anchor_timeout, the attempts refused meanwhile counting as failed.¶

4. The next attempt is CONTINUE_0RTT when it is the first of a run of the schedule, a prekey of the peer is held and the peer has not asked for proof; every later attempt of the run is CONTINUE, except that at the session's initiator the third and fifth attempts of a run are FRESH unless, within the current interval, a protected packet from the peer authenticated or a request of the peer's opened with an attempt above every earlier one. At the responder every attempt is CONTINUE. A re-anchor the protocol requires while RECOVERING or DORMANT is the schedule's attempt like any other; one whose number is reserved counts as a failed attempt.¶

5. An attempt restored from the write-ahead record at a restart is retransmitted while it is younger than its life, and a restored CONTINUE attempt older than its life is abandoned at the restart, the endpoint then re-anchoring afresh (Section 16.6.2).¶

6. The attempt goes to the next address of the rotation below, as a pair with the local address that belongs to it, the FRESH attempts rotating on a count of their own, and a hint probed first and then tried ahead. Silence is judged as Section 16.3.3 says: only an exhausted attempt sent toward the address the peer has since been heard from counts toward a failed proof; silence on an attempt sent elsewhere is the network's.¶

Entering DORMANT. A session enters DORMANT when the recovery schedule that follows the loss of its last path is exhausted and recover_hold has then passed without its return (Section 18.2, S15), when the peer announces suspension with SUSPEND (Section 19), or by local decision.¶

What DORMANT discards and keeps. It discards everything but the continuity record and the recovery-identifier table entry, the current generation's keys and identifiers included, and with the paths every record that names one, the outstanding probes above all, since a probe record that outlives its path lets a late acknowledgement validate the dead path and send on it with an identifier a new path has taken; a generation armed by the peer's request stays installed, with its keys and its sending state, because the record carries it and its confirmation probes may already have been sent under it (Section 9.3.9), and the packet that commits it leaves DORMANT (Section 18.2, S17).¶

What a DORMANT session receives. A DORMANT session therefore receives nothing under its old generation: the peer's packets, its probes and even its CLOSE are dropped as unknown identifiers, the peer detects the silence by liveness and recovers by re-anchor, and a CLOSE the dormant endpoint missed is answered later by the closer's tombstone (Section 19.6). Retaining the receive keys while DORMANT was considered and not adopted: dormancy would then not bound memory, and keys the protocol no longer needs would stay in place (I-14).¶

What DORMANT reports and leaves untouched. The session reports the transport-class event Dormant, with announced set when a SUSPEND caused it. Entering and leaving DORMANT change nothing above the session (I-6): identity, authorization, the generation's number and lineage, exporter values and upper-layer bindings are untouched; the live keys and identifiers they discard are the session's own and are re-created from the record.¶

Bounds. A DORMANT session is closed when it has been DORMANT for max_dormancy, with reason DORMANCY_EXPIRED, or when its authorization expires (Section 17), with AUTHZ_EXPIRED; both are policy-class closes and security-class events. Nothing a path does can close a session.¶

RECOVERING. When the last path is lost, on restart (Section 16.6.2), and whenever an application send is attempted while DORMANT or, once per outage, in recover_hold, the session enters RECOVERING, or stays in it, and runs the recovery schedule afresh (the hold that follows a schedule so restarted ends in DORMANT whatever is sent, so that an active sender does not keep its keys for the whole outage): one attempt at a time, toward one address at a time, until a generation commits, a FRESH establishes a replacement session, or the schedule is exhausted. The schedule has three parts.¶

1. The attempts. An attempt is a CONTINUE request (Section 16.3) carrying the session's next attempt number (Section 9.3.3), one higher per attempt and persisted, so that a responder never serves an abandoned attempt after its successor.¶

   • Step 4, the first attempt. The zero-round-trip form is used only for the first attempt of a run because its response carries no ciphertext, about half of the exchange on the wire, and data the application sends while it is outstanding is early data with the properties of Section 16.3.2, forward-secret and not replayable; every later attempt of the run is CONTINUE, so that a prekey a lost answer consumed is not tried twice.¶

   • Step 4, the FRESH attempts. A peer that has lost all state and a peer that is unreachable both answer CONTINUE with silence, and a FRESH request is the only message that distinguishes them: hence the initiator's third and fifth attempts, unless the hearing rule says the peer holds the session and is reachable.¶

   • Hearing. Opening is not enough for a request to count as hearing: one recorded earlier and replayed still opens under the session's secret, and once the reply cache has let it go, or after a later attempt was served and it is dropped as stale (Section 9.3.3), nothing else stops it; counted, it would hold back the FRESH, the only attempt that recovers from a peer that has lost its state, for as long as the replays went on. The peer's attempt numbers only increase, so a new request always counts and a replayed one never does; the highest number seen is kept in memory only, so after a restart the first replay counts once.¶

   • One schedule probes. Both ends recover by CONTINUE and only one needs to probe with FRESH: two schedules sending FRESH on a slow link crowd out the CONTINUE that would recover the session and often supersede it. An initiator that has itself lost all state holds no session to recover and opens a new one. A recovery FRESH carries a SUPERSEDE object (Section 19.4.6) naming the session it replaces, because concurrent sessions with one peer are permitted (Section 9.6.2) and the responder cannot otherwise know which session to close.¶

   • Steps 1 to 3, replacement and life. An attempt is replaced when the next is due so that one unanswered address never holds recovery for anchor_timeout; a CONTINUE attempt ends at anchor_timeout from its first transmission because that is the life of the generation it created at the responder (Section 16.4), whatever the schedule's interval, a pause or a restart; and the grace for a response that has begun to arrive, to a CONTINUE attempt or to a recovery FRESH, stays within that life because a response completed after the attempt ended would commit a generation the responder has let go. The kept CONTINUE_0RTT attempt is not replaced because a new session takes no generation number of the old one; a paused attempt waits for its answer, and an attempt withheld for the peer's armed generation waits for its commit or expiry, the attempts refused meanwhile counting as failed, so that the schedule may run out during the wait and the session then recover from the hold or on dormant_retry.¶

   • The schedule also governs the next attempt whenever one ends without a commit: by yielding, by a failure to write the record, or because the generation the peer created in answer was discarded unconfirmed. Either endpoint may recover; Section 16.4 resolves both doing so at once.¶

2. The intervals. Attempts follow recover_schedule. A re-anchor the protocol makes at once while RECOVERING, after a restored generation commits (Section 16.6.2), is the schedule's current attempt and is given its interval. Any re-anchor the protocol requires is the schedule's attempt like any other while the session is RECOVERING or DORMANT: one that cannot be made, because its number is reserved (Section 16.4), counts as a failed attempt, and at the initiator the third and fifth attempts are FRESH as for every session, since a FRESH makes no generation of this session and takes no number. Waiting for an armed generation of the peer's counts the same way; it ends by itself, by the generation's commit or its expiry within anchor_timeout.¶

   • Each interval is at least twice the last measured round trip and at least twice the session's exchange floor, the time its last anchor exchange took: at the requester from the request's last transmission to the response complete, at the responder from its last transmission of the response, a reply-cache answer to a retransmitted request included, to the requester's first packet that authenticates under the generation that response armed, so that neither measure includes the waits of lost copies; a response whose generation expired unconfirmed yields no measure. The floor is kept in the record so that the first attempt after a restart has it too, and it bounds the retransmit timer of Section 9.4 and the probe intervals of Section 9.3.9 and Section 15.3 as well, which never exceed probe_max under it, so that a generation's confirmation is probed several times within anchor_timeout whatever the exchange took.¶

   • After the schedule's last attempt has had its interval, the session stays RECOVERING for recover_hold, sending nothing, that attempt abandoned (a kept CONTINUE_0RTT attempt excepted, Section 16.3.2) and no further one made, and keeping its current generation; a wait that completes the count (above) leaves an attempt outstanding its interval, and the hold begins when that interval ends. The session keeps its generation so that a path that returns within it validates with a probe and the session resumes without a re-anchor (Section 18.2, S14); then it enters DORMANT and retries on dormant_retry, doubling to one hour, until max_dormancy; a session made DORMANT by SUSPEND{expected} makes its first retry no earlier than expected seconds after the announcement (Section 19.5).¶

3. The rotation. Each CONTINUE attempt goes to the next address of an ordered list, as a pair with the local address that belongs to it: the local address of the candidate path whose address it goes to, else the local address the peer's address was last validated from, else the session's.¶

   • The list is, in order:¶

     • the addresses supplied to the session while it had no usable path (Section 15.3, source 2), newest first, which stay in the list after a candidate path made from one is lost to unanswered probes, since a supplied address is knowledge about where the peer is and a peer that cannot answer a probe can still answer an attempt;¶

     • the addresses at which the same peer identity is reached by this endpoint's other established sessions, the freshest evidence of where the peer is;¶

     • the addresses of the session's candidate paths, newest first;¶

     • the address the peer was last validated at;¶

     • the other previously validated addresses;¶

     • the configured hints.¶

   • The rotation advances with every CONTINUE attempt actually transmitted, retransmissions included. The FRESH attempts rotate over the same list on a count of their own, which the CONTINUE attempts do not advance and which does not advance them: the first FRESH attempt of an outage goes to the head of the list, the address the peer is most likely at, and each later one to the next address, across the runs of the schedule the outage takes, because a FRESH attempt is the only one that heals a peer holding a different lineage, as a responder whose armed generation expired (Section 16.4) after this endpoint committed it does, and the CONTINUE attempts reach such a peer but it can open none of them. While the CONTINUE attempts are withheld, the FRESH attempts take the CONTINUE count instead, being the only attempts sent.¶

   • A schedule that starts afresh, on the loss of the last path, on a send while DORMANT or in recover_hold, or on a hint, starts the CONTINUE rotation at the head; the FRESH count starts at the head on the loss of the last path and on a hint, and continues across a send while DORMANT or in recover_hold and across dormant_retry, which bring no knowledge of where the peer is.¶

   • A RECOVERING session that still has a validated primary path, as one whose committed generation was re-created from the record has (Section 12.7), makes the run's first attempt on it and rotates from the head after it, since an address validated from the set of Section 15.3 may answer nothing.¶

   • A hint (Section 15.3, source 2) given to a RECOVERING session that still holds a generation is probed at once and, if the probe is not answered within three measured round trips (at least 100 ms, at most the probe interval, which applies when no round trip is known), is the address of the next attempt, ahead of a candidate path the attempt would otherwise go to first; a re-anchor made at once because a packet from a candidate address committed a restored generation (Section 12.7) goes to that address first.¶

Supersession. If a FRESH attempt made during recovery completes and is confirmed (Section 9.3.9), the new session supersedes the old one at both endpoints: the responder closes the session named by SUPERSEDE with SUPERSEDED when the new one is confirmed (Section 9.3.9), never before, because a replayed FRESH request can never be confirmed; the requester closes it when the exchange completes. The new session inherits the previously validated addresses of the old one (Section 15.3).¶

The old session preferred. If a delayed CONTINUE response for the old session arrives first, the endpoint keeps the session confirmed most recently and abandons the FRESH attempt; so does a path of the old session validating while the FRESH is outstanding, and so does a path hint from the host, which restarts the schedule with the hinted pair as its first address, so that a FRESH completing a moment after a link returns does not supersede a session that is recovering on its own path.¶

Above the session. Durable state above the session is keyed on the peer's identity, not on the session, so that it survives supersession: the layer above sees Closed{SUPERSEDED} on the old session and Established on the new one, with the same peer fingerprint (Section 3).¶

Events. Recovering on entry to RECOVERING; ReAnchored on commit of a new generation; Dormant as above; EarlyDataUncertain{reason} when a CONTINUE_0RTT attempt under whose generation data was sent is answered with a RETRY (Section 16.3.2); Closed{reason} for the closes above. All but Closed are transport-class.¶

16.8. Scheduled Re-Anchor

A session re-anchors on its live path every reanchor_interval, using CONTINUE_0RTT when a prekey is held and CONTINUE otherwise. The handshake initiator schedules it; the handshake responder initiates its own only if the initiator is late by more than a quarter of the interval, so that the two do not routinely collide. Epoch chaining limits how many packets one traffic key encrypts and hides earlier epochs from an attacker who obtains only a later epoch secret; it does not hide them from one who obtains lineage_secret (Section 14.3). The scheduled re-anchor is the post-compromise ratchet. It heals a passive theft of the lineage's secrets: the successor secret folds in a fresh KEM secret the thief does not hold, so the thief loses the session at the first re-anchor it took no part in, within reanchor_interval. It does not by itself evict a thief who re-anchors first, since an ordinary CONTINUE authenticates by possession of cs(g - 1) alone; that thief is bounded by the identity re-proof deadline of Section 16.3.3, not by this interval. Because the address is unchanged, a scheduled re-anchor validates nothing and stalls nothing (Section 16.4).¶

16.9. Gateway Groups

A session recovered at a different gateway of the same operator is the same session only if that gateway holds the same identity key and the same records or the key that unseals them. Session portability across a gateway group therefore implies one gateway-group identity key, replicated to every gateway and preferably held in hardware at each, with the consequence that compromise of one gateway is compromise of the group identity. The sealed-record key, the tombstones of closed sessions (Section 16.6.3) and the receiver prefix convention (Section 15.1) are replicated the same way. Closure state is negative authority and the inverse of the cohort's freshness rule: a gateway restores a session from a record only with closure state it knows to include every closure of the group, and one that cannot establish that serves no record, so that a closure made at one gateway cannot be undone at another. Prekeys need no coordination: a prekey's decapsulation key is never in a record, so only the gateway that issued it can serve a CONTINUE_0RTT under it, and a gateway serving from a record answers PREKEY_UNAVAILABLE (Section 16.6.3). A single gateway is the degenerate case. This is a deployment decision and is stated as such; Section 23 states its containment cost.¶

16.10. Stated Limits and Exercised Scenarios

Limits (restated in Section 23).¶

• A holder of cs(g). A holder of cs(g) can re-anchor as the session's endpoint until the identity re-proof deadline of Section 16.3.3, at most max_reproof_interval after the last proof, after which nothing above the session moves and the session closes when a proving exchange is given up unsatisfied (Section 16.3.3); the ratchet heals a one-time leak once the legitimate endpoint re-anchors first, and the race is real. Neither reanchor_interval nor max_dormancy bounds the holder: the first is the ratchet's period, the second bounds dormancy.¶

• Records. A copy of a record at rest is bounded by Section 16.6.2, and a sealed record by its record key (Section 16.6.3).¶

• Closure state. An endpoint that loses its closure state with the rest of its state cannot tell a closed session's record from a live one; it serves no record until the state is recovered or the record key retired (Section 16.6.3), at the cost of FRESH for every session it would have restored, and a gateway group that replicates its closure state is not exposed. A storage failure followed by a crash before the closure write could be retried leaves the session's record where a tombstone should be; the restart restores the session DORMANT, and a holder of its secret can re-anchor it, which is the residual the write-ahead rule of Section 19.6 leaves.¶

• Early data. The CONTINUE_0RTT form at a stateless responder degrades to one round trip and never to replayable data; in a gateway group whose members serve the same session one from state and another from a sealed record, early data of an attempt the second refuses may have been delivered by the first, so a RETRY leaves its fate unknown (Section 16.3.2).¶

• Authorization. Dormancy keeps the session and not its authority: a re-anchor never extends authorization.¶

• The session identifier. A requester that commits g on a CONTINUE response, after which every packet it sends is lost for the life of the responder's armed g (anchor_timeout, Section 16.4), is a generation ahead of a peer that holds g - 1, and has erased cs(g - 1): the session recovers by the schedule's FRESH attempt, which supersedes it (Section 16.7). The case is safe and live, and costs the session identifier.¶

• The identifier under two schedules. An outage that ends while both endpoints run their recovery schedules can also cost the identifier although both kept the session: the initiator's third and fifth attempts are FRESH (Section 16.7), and one that completes before a CONTINUE of the responder supersedes the session. Because only the initiator makes them, and only when it has not heard from the peer within the interval (Section 16.7), and because recover_hold keeps the generation after the schedule's last attempt, this is uncommon even on a slow link, where the endpoint that detects the loss by liveness runs its schedule late. It too is safe and live: the layer above sees Closed{SUPERSEDED} and Established with the same peer fingerprint (Section 16.7).¶

• Declining a FRESH. A responder that still holds the session could decline such a FRESH and keep the identifier, but declining is safe only while both ends can re-anchor at once, which a lossy link often prevents for a moment; this version does not decline.¶

17.1. Grants

A grant is the AUTHZ object of Section 19.4.2, issued by one endpoint to the other:¶

AUTHZ = ttl(4) ref_len(1) ref(0..255)

• The grantor is authoritative for the grants it issues; the grantee holds a copy. Each endpoint issues its own grant to the peer, so a session carries two independent grants, one per direction. In a client-and-gateway deployment the gateway's grant is the one that matters and the client's is unbounded; between peers of equal standing both matter.¶

• A grant states that the grantor will accept the peer's application data and provide its services to the peer until the grant expires. It governs delivery of application data (stream_id 0x00 to 0xDF and upper-layer streams), not control frames, probes or anchor exchanges, which a session needs in order to exist at all.¶

• ttl is in seconds. The grantee counts it from its first receipt of that version; ttl = 0xFFFFFFFF means until revoked; ttl = 0 revokes (Section 17.4). ref is opaque to PQST: it names the grant to the grantor's own policy or to an upper layer, which may use it to look up what the grant covers.¶

• An endpoint that performs no authorization of its own MUST still issue a grant, with ttl = 0xFFFFFFFF and an empty ref, at establishment. The absence of a current grant means nothing from the peer is delivered.¶

17.2. Issuance and Delivery

Each endpoint issues version (0, 1) of its grant in its sealed part of the FRESH exchange, the initiator in the request and the responder in the response (Section 9.3.7), or, if that would exceed the reflection bound, as an OBJECT immediately after establishment. The exchange's objects belong to generation 0, whose counters continue after it commits (Section 19.3.1). Later versions travel as OBJECT frames with the reliability of Section 19.3. The grantor's own decisions use the grant it issued from the moment of issuance, whether or not it has been acknowledged; acknowledgement tells the grantor that the grantee knows the terms.¶

The three inputs to the grantor's decision at establishment is: the peer's identity (Section 9.3.6), the authz_hint the peer sent in its sealed request (Section 9.2.1), and the grantor's policy. The hint is at most 64 octets and proves nothing: a deployment that needs a verified token binds it to the identity through its own policy, for example by accepting a token only from the fingerprint it was issued to.¶

17.3. Expiry

• The grantor stops delivering the peer's application data when, by its own clock, the grant it issued has been expired for longer than authz_delivery_bound (delta, default 5 s), which covers the grantee's later receipt of the version and clock drift between two monotonic clocks. It then closes the session with AUTHZ_EXPIRED (Section 20), a policy-class close reported as the security-class event AuthzExpired.¶

• The grantee stops sending application data when its copy expires, and, if no newer version arrives within delta, closes with AUTHZ_EXPIRED as well. Under normal delivery the grantor's CLOSE arrives first. When the grantor cannot deliver the renewal, because it holds no path or is DORMANT, the grantee's copy expires first and the grantee closes; the grantor learns of it from the tombstone when it re-anchors, or closes on its own expiry. A short grant therefore bounds how long a session survives unreachability as well as how long it lives; a deployment that wants sessions to survive outages issues grants longer than the outages it expects.¶

• A grantor that intends the session to continue renews before expiry: a new version with a new ttl, RECOMMENDED at half the previous lifetime, so that one lost renewal and its retransmissions fit before expiry.¶

• A grant's lifetime bounds the session as effectively as max_dormancy does: a session whose grant expires while DORMANT is closed when the expiry is noticed, and a re-anchor of a session whose grant has expired is refused with CLOSE{AUTHZ_EXPIRED} after the request authenticates. A deployment that wants sessions to survive long dormancy issues grants at least as long as max_dormancy.¶

• Nothing in expiry uses a synchronised clock. Both endpoints count seconds on local monotonic clocks; the grantor's count starts earlier, which is why the grantor's view is the authoritative one.¶

17.4. Revocation

The grantor issues a version with ttl = 0, then CLOSE{AUTHZ_REVOKED}. From the moment of issuance it delivers nothing from the peer and refuses any re-anchor of the session; the close reason is a policy-class close reported as the security-class event AuthzRevoked. Revocation of an identity, as opposed to a grant, is an authorization decision and not a cryptographic one: a revoked identity still holds its private key and completes any identity proof, and that success restores nothing. A revoked identity obtains no new session by FRESH, since the responder admits a FRESH only from an identity its policy authorizes (Section 9.3.6), and restores none by CONTINUE or from a sealed record, since restoration is verified against current authorization (Section 16.6.3); its sessions are closed with AUTHZ_REVOKED as a grant's are. Closing a session and revoking an identity are distinct: the first ends that session identifier for good, and the identity may open a new session while it is authorized; the second ends the identity's authorization until it is explicitly reauthorized.¶

17.5. Restart and Re-Anchor

• Grants are persisted in the continuity record as Section 16.6.1 states: the grant the endpoint issued, with its remaining lifetime at the time of writing, so that it can be enforced and re-issued, and with the time since the write counted against it on restore (Section 16.6.1); the grant held is not relied on after a restart: neither its terms nor its version number are restored, so that the peer's current version, which every re-anchor request and response carries (Section 9.3.7), is adopted whatever its number. Until it arrives the held grant is treated as expired, which stops the sending of application data and nothing else.¶

• A re-anchor never extends, refreshes or restores a grant; only a new version issued by the grantor does. Identity re-proof (Section 16.3.3) may be the grantor's precondition for issuing one, which is the grantor's policy, not a protocol rule.¶

• A session admitted with an unknown identity (Section 9.3.6) receives whatever grant the grantor's policy gives such sessions, which may be none.¶

17.6. Upper Layers

An upper layer that keeps its own authorization state binds it to the session through the exporter (Section 8.6) and to the identity through the fingerprint, and may place a reference to it in ref. PQST enforces only the grant; what the reference means is the upper layer's. A grant's class in the persistence hierarchy is the session's (Section 3): it is above paths and epochs and below identity.¶

18.1. States

Session.¶

Path (per path, Section 15): CANDIDATE, VALIDATED, LOST, then removed.¶

Generation (per generation, Section 16.4): ARMED, COMMITTED, RETIRED, then erased.¶

Exchange (per anchor exchange in progress, Section 9): REQUESTED (request sent, awaiting response) at the requester; RESPONDED (response sent, awaiting confirmation) at the responder.¶

18.2. Session Transitions

Triggers are authenticated packets, exchange completions, timers, or local decisions. No transition is triggered by an unauthenticated packet (Section 11.7). "Class" is the event class of Section 3.¶

• S1. From: NONE; Trigger: application opens a session; Guard: identity key and peer key held; Effect: write-ahead init_counter; send FRESH (or DISCOVER then FRESH); To: HALF_OPEN¶

• S2. From: NONE; Trigger: FRESH request accepted (Section 9.3.2); Guard: checks of 9.3.2 pass; Effect: respond; generation 0 ARMED; half-open timer; To: HALF_OPEN¶

• S3. From: HALF_OPEN; Trigger: response opens (requester); Guard: 9.3.8; Effect: commit generation 0; send confirmation packet; the pair the request was sent to VALIDATED when the attempt went to one pair, the response's source CANDIDATE when it differs (Section 9.3.8); To: ESTABLISHED; Event (class): Established (transport)¶

• S4. From: HALF_OPEN; Trigger: first protected packet authenticates (responder); Effect: commit generation 0; To: ESTABLISHED; Event (class): Established (transport)¶

• S5. From: HALF_OPEN; Trigger: anchor_timeout, attempts exhausted, or the session the peer initiated confirmed under 9.6.1; Effect: erase exchange state and dk; To: NONE; Event (class): OpenFailed (transport)¶

• S6. From: ESTABLISHED; Trigger: path becomes VALIDATED; To: ESTABLISHED; Event (class): PathAdded (transport)¶

• S7. From: ESTABLISHED; Trigger: sender's primary path changes; To: ESTABLISHED; Event (class): PathChanged (transport)¶

• S8. From: ESTABLISHED; Trigger: a path is lost; Guard: another path is CANDIDATE or VALIDATED; Effect: retire the path after path_retire; To: ESTABLISHED; Event (class): PathLost (transport)¶

• S9. From: ESTABLISHED; Trigger: a path is lost; Guard: no other usable path; Effect: start recover_schedule; retain everything; To: RECOVERING; Event (class): PathLost, Recovering (transport)¶

• S10. From: ESTABLISHED; Trigger: receive epoch advances (Section 14.4); To: ESTABLISHED; Event (class): EpochAdvanced (transport)¶

• S11. From: ESTABLISHED; Trigger: re-anchor commits (scheduled, on demand, or peer-initiated); Effect: new generation COMMITTED; previous RETIRED after lineage_grace; identifiers reinstalled; paths kept; unacknowledged objects sent again (Section 19.3.3); To: ESTABLISHED; Event (class): ReAnchored (transport)¶

• S12. From: ESTABLISHED, RECOVERING; Trigger: SUSPEND received; Effect: discard all but record, recovery entry and a peer-armed generation (Section 16.7); To: DORMANT; Event (class): Dormant{announced} (transport)¶

• S13. From: ESTABLISHED; Trigger: local decision to suspend; Effect: optionally send SUSPEND; discard as S12; To: DORMANT; Event (class): Dormant (transport)¶

• S14. From: RECOVERING; Trigger: authenticated packet creates a CANDIDATE path, or a re-anchor commits; Guard: the committed generation was created in this process (Section 12.7); Effect: stop the schedule; unacknowledged objects sent again (Section 19.3.3); To: ESTABLISHED; Event (class): PathAdded or ReAnchored (transport)¶

• S15. From: RECOVERING; Trigger: recover_schedule exhausted and recover_hold passed; Effect: discard as S12; start dormant_retry; To: DORMANT; Event (class): Dormant (transport)¶

• S16. From: DORMANT; Trigger: dormant_retry fires, application sends, or a hint arrives; Guard: within max_dormancy; Effect: start recover_schedule; To: RECOVERING; Event (class): Recovering (transport)¶

• S17. From: DORMANT; Trigger: peer's CONTINUE request accepted and committed, or a generation armed before dormancy commits (Section 16.7); Effect: rebuild from record; unacknowledged objects sent again (Section 19.3.3), except under a generation re-created from the record, after whose re-anchor they go; when the committed generation was re-created from the record, schedule the re-anchor it calls for; To: ESTABLISHED or RECOVERING; Event (class): ReAnchored (transport), then Recovering (transport) in the second case¶

• S18. From: DORMANT; Trigger: max_dormancy elapsed; Effect: erase record; keep tombstone; To: CLOSED; Event (class): Closed{DORMANCY_EXPIRED} (security)¶

• S19. From: any but NONE, CLOSED; Trigger: issued grant expired beyond delta, or held grant expired beyond delta with no renewal (Section 17.3); Effect: tombstone; send CLOSE if a path exists; erase record; To: CLOSED; Event (class): AuthzExpired, Closed{AUTHZ_EXPIRED} (security)¶

• S20. From: any but NONE, CLOSED; Trigger: grantor revokes (Section 17.4); Effect: AUTHZ with ttl = 0; tombstone; CLOSE; erase; To: CLOSED; Event (class): AuthzRevoked, Closed{AUTHZ_REVOKED} (security)¶

• S21. From: any but NONE, CLOSED; Trigger: required identity proof or CERT verification fails (Section 16.3.3 and Section 19.4.5); Effect: tombstone; CLOSE; erase; To: CLOSED; Event (class): ReproofFailed, Closed{REPROOF_FAILED} (security)¶

• S23. From: any but NONE, CLOSED; Trigger: lineage_gen would exceed 0xFFFF (Section 12.2), or attempt would (Section 9.3.3); Effect: tombstone; CLOSE; erase; the application may open a new session; To: CLOSED; Event (class): Closed{SESSION_LIFETIME} (security)¶

• S24. From: any but NONE, CLOSED; Trigger: a newer session that names this one in SUPERSEDE is confirmed (Section 9.6.1 and Section 16.7); Effect: tombstone; CLOSE; erase; To: CLOSED; Event (class): Closed{SUPERSEDED} (security)¶

• S25. From: any but NONE, CLOSED; Trigger: CLOSE received, or RETRY CLOSED opened; Guard: authenticated; Effect: tombstone; erase record and state; no reply; To: CLOSED; Event (class): Closed{reason} (security)¶

• S26. From: any but NONE, CLOSED; Trigger: application closes; Effect: tombstone; CLOSE up to three times; erase; To: CLOSED; Event (class): Closed{LOCAL_CLOSE} (security)¶

• S27. From: any but NONE, CLOSED; Trigger: persistent protocol violation after authentication (Section 20.3); Guard: threshold; Effect: tombstone; CLOSE; erase; To: CLOSED; Event (class): Closed{PROTOCOL_ERROR} (security)¶

• S28. From: NONE; Trigger: restart: the continuity record is loaded (Section 16.6.2); Guard: record present and within max_dormancy; Effect: re-create the record's armed generation, and one a kept CONTINUE_0RTT attempt derived, receive-only (Section 12.7), the committed generation as its continuity secret alone; retransmit an outstanding request younger than anchor_timeout from its first transmission, else abandon it and re-anchor toward the address the peer was last seen at; To: DORMANT or RECOVERING; Event (class): Recovering (transport) once an attempt is made¶

• S29. From: RECOVERING; Trigger: application sends, once per outage, in recover_hold, or a hint arrives (Section 16.7); Effect: restart recover_schedule; a hint starts the rotation at the head and probes its pair first; To: RECOVERING¶

A FRESH exchange started during recovery (Section 16.7) is a new session following S1 and S3; its SUPERSEDE object triggers S24 on the session it names when the new one is confirmed.¶

18.3. Path Transitions

• P1. Trigger: authenticated packet from a new address pair with an index not seen in this generation (Section 15.1); local supply; CONTINUE request from a new address; anchor response from a pair other than its request's destination (Section 9.3.8); Effect: create path; the address's budget applies; To: CANDIDATE¶

• P2. From: CANDIDATE or VALIDATED; Trigger: authenticated packet from a new address with an index seen in this generation on this path; Effect: rebind: the new address is recorded as the path's candidate address and replaces the old one on validation (P3); the old address stays in use until then; To: unchanged (same path, same identifier)¶

• P3. From: CANDIDATE, or any state with a rebind address pending; Trigger: matching PROBE_ACK for a PROBE sent toward the address, on whichever path it arrives; the address is in the previously validated set; or, at the requester, the pair the anchor request was transmitted to, alone, when its response opens and the exchange commits (Section 9.3.8); Effect: budget lifted; the address joins the session's validated set; a rebind adopts the new address, and a CANDIDATE path whose rebind address validates is VALIDATED there; To: VALIDATED; Event: PathAdded (transport) for a new path; PathChanged (transport) when the primary's address changes; none otherwise¶

• P4. From: CANDIDATE; Trigger: k_probe probes unanswered; Effect: discard a new path; for a rebind, keep the old address if it is still live, else LOST; To: removed or LOST; Event: PathLost if lost¶

• P5. From: VALIDATED; Trigger: k_probe probes unanswered (active), or after a send (passive); or the local address is withdrawn by the endpoint; Effect: identifier retired after path_retire; the address leaves the previously validated set; To: LOST; Event: PathLost (transport)¶

• P6. From: any; Trigger: session leaves ESTABLISHED or RECOVERING for DORMANT, or closes; Effect: discard, with every record that names the path (Section 16.7); To: removed¶

• P7. From: any; Trigger: re-anchor commits with the address unchanged; Effect: identifiers change; validation, MTU and liveness kept; To: unchanged¶

• P8. From: LOST; Trigger: authenticated packet or anchor message from the path's address; Effect: one probe (Section 15.3); To: CANDIDATE¶

Any authenticated packet on a path refreshes its liveness in every state.¶

18.4. Generation Transitions

• G1. Trigger: response sent (responder) or request sent in CONTINUE_0RTT (requester); Effect: keys and identifiers installed; previous generation untouched; To: ARMED¶

• G2. From: ARMED; Trigger: first packet authenticates under it (responder: a PROBE_ACK or a request under a CONTINUE_0RTT generation, any packet otherwise, Section 16.4); response opens (requester); Effect: persist cs(g), the commit standing only once the write holds (Section 16.4); erase cs(g - 1); remove rec(g - 1, .); To: COMMITTED¶

• G3. From: ARMED; Trigger: its lifetime elapses with its cached answer (anchor_timeout for CONTINUE, reply_cache_ttl for CONTINUE_0RTT, renewed by retransmissions, or anchor_timeout from a restart that restored it without an answer, Section 16.6.2); a different request re-serves the generation (Section 16.4); the number is settled by another commit; its own requester abandons it by yielding to a crossing CONTINUE_0RTT (Section 16.4); Effect: discard; To: erased¶

• G4. From: COMMITTED; Trigger: the next generation commits; Effect: keys, windows and identifiers kept for lineage_grace; To: RETIRED¶

• G5. From: RETIRED; Trigger: lineage_grace elapsed; Effect: erase; To: erased¶

18.5. Event Classes

Established carries the peer's fingerprint and the session identifier, which is how an upper layer keys its durable state on identity (Section 3). ReanchorFailed and OpenFailed are local reports of an attempt that ended without a commit; GrantHeld reports a grant object from the peer adopted (Section 17.5) and CertReceived a certificate (Section 19.4.5).¶

18.6. Properties Checkable from the Tables

1. Every trigger in Section 18.2 is an authenticated packet, an exchange completion that required authentication, a timer, or a local decision; none is an unauthenticated packet (Section 11.7).¶

2. Every transport-class transition leaves everything above the session unchanged: the identity, the grants, session_root and the session identifier (Section 3). The generation, the epochs and the paths are the session's own and may change; a re-anchor is transport-class for that reason. The two events that change what is held above the session, GrantHeld and CertReceived, are security-class.¶

3. CLOSED has no outgoing transition.¶

4. DORMANT retains only the continuity record, the recovery-identifier entry and a generation the peer's request armed (Section 16.7).¶

5. No path transition changes session state except S8, S9 and S14, and those change only the session's reachability state.¶

6. The only transitions that erase a committed generation's secret are G2 (the next commit) and the closes.¶

19.1. Frame Types and Registry Ranges

A receiver skips a frame whose type it does not implement, using its length, and continues with the next frame; it MUST NOT close the session because of an unknown type. Whether a peer implements an optional frame or object kind is known from capabilities (Section 21), not discovered by trial.¶

A frame whose ctrl_data is shorter than its fixed fields, or longer than its definition allows, is malformed; the packet's remaining frames are dropped and the event is counted. Frames already processed from the same packet stand, as does the packet's replay commit.¶

19.2. PROBE and PROBE_ACK

PROBE     = path_id(1) data(8)      ; data is fresh randomness from a
                                    ; cryptographically secure source
PROBE_ACK = path_id(1) data(8)      ; both fields echoed

path_id is the sender's local handle for the path on which it sends the PROBE (Section 15.2); the peer echoes it without interpretation, so each endpoint numbers its own paths.¶

Rules.¶

• A receiver MUST answer every PROBE with exactly one PROBE_ACK carrying the same fields, sent on the path on which the PROBE arrived, under its current sending generation and epoch; a PROBE that authenticates under an armed generation commits it first (Section 16.4), so the answer to a confirmation probe is under the probe's generation; a PROBE under a generation a CONTINUE_0RTT request armed commits nothing, and is answered under the current generation; when the PROBE came from an address being validated as a path's rebind, through that path to that address (Section 15.3). A PROBE_ACK packet is 56 octets, never padded, and never larger than the packet that elicited it, so it always fits the budget for an unvalidated path (Section 15.4).¶

• A PROBE_ACK is accepted only if data matches a PROBE the receiver sent and has not yet matched; otherwise it is ignored and counted. An endpoint keeps at most 8 outstanding probes per path and discards the oldest when it needs a ninth.¶

• Any authenticated packet refreshes the liveness of the path it arrives on (Section 15.6); a PROBE_ACK additionally validates the path the matching PROBE was sent on (Section 15.3), and if that PROBE was carried in a packet padded to a candidate size, confirms that size for the path (Section 15.5).¶

One frame pair therefore serves five purposes: liveness, path validation, confirmation of an epoch advance (Section 14.1, where the required PROBE_ACK answers a PROBE sent in the epoch being left, whatever epoch the acknowledgement itself arrives in), confirmation of a new generation by either side (Section 9.3.8 and Section 9.3.9), and path MTU discovery. The randomness is needed for validation, where the challenge must be unpredictable to a peer that claims an address it does not hold; it costs nothing to keep for the other uses.¶

19.3. OBJECT and OBJECT_ACK

A state object is a value one endpoint owns and the other must hold a current copy of. Objects replace per-purpose signalling frames with one reliable, idempotent delivery mechanism.¶

ObjectHeader = kind(1) version(4)
Object       = ObjectHeader body_len(2) body(*)
               ; the form used inside anchor messages (Section 9.2)

version      = lineage_gen(16) || counter(16)

OBJECT     = kind(1) version(4) total_len(2) offset(2) data(*)
OBJECT_ACK = kind(1) version(4)

19.4. Object Kinds

• 0x01. Name: NEXT_EK; Issuer: either; Body: nek(L_ek); Bound: L_ek (1,568 in suite 0x0001); Persisted by holder: yes¶

• 0x02. Name: AUTHZ; Issuer: either; Body: ttl(4) ref_len(1) ref(0..255); Bound: 260; Persisted by holder: yes, as Section 16.6 states¶

• 0x03. Name: RECORD; Issuer: a responder that issues sealed records; Body: opaque; Bound: 472; Persisted by holder: yes¶

• 0x04. Name: INNER_ADDR; Issuer: either, if capability bit 1; Body: Section 19.4.4; Bound: 512; Persisted by holder: yes¶

• 0x05. Name: CERT; Issuer: either; Body: cert_type(1) certificate(*); Bound: 16,384; Persisted by holder: no¶

• 0x06. Name: SUPERSEDE; Issuer: the requester of a recovery FRESH (Section 16.7); Body: session_id(16); Bound: 16; Persisted by holder: no; applied at confirmation¶

• 0x10-0x1F. Name: reserved for the cohort layer (Section 26), delivered to the layer above; Bound: 16,384 (MAX_OBJECT); Persisted by holder: neither the version nor the body, at this layer; the cohort layer persists what it needs (Section 19.3.4)¶

• 0x80-0xBF. Name: reserved for protocol-defined upper layers (Section 25)¶

• 0xC0-0xFF. Name: private use¶

INNER_ADDR = count(1) *( family(1) address(4|16) prefix_len(1)
             lifetime(4) )
family     = 4 (IPv4, 4-octet address) | 6 (IPv6, 16-octet address)
lifetime   = seconds from first receipt of this version; 0xFFFFFFFF =
             until revoked

19.5. SUSPEND

SUSPEND = expected(2)     ; seconds the sender expects to be
                          ; unreachable; 0 = unknown

Sent by an endpoint that is about to lose connectivity deliberately (radio off, sleep, a planned move), up to three times 1 s apart (the initial retransmission interval of Section 9.4), after which it stops transmitting and is DORMANT itself. The receiver stops probing the sender's paths, moves the session to DORMANT at once with the announced flag (Section 16.7), and makes its first recovery attempt after the larger of dormant_retry and expected seconds; an application send while DORMANT starts recovery at once (Section 16.7), announcement or not. SUSPEND carries no authority beyond the sender's own session: it cannot affect any other session, and a peer that keeps sending after announcing suspension is simply still reachable. For an upper layer that tracks membership this is the signal that distinguishes a deliberate absence from a lost one.¶

19.6. CLOSE

CLOSE = reason(1)         ; Section 20

Sender. Closure is durable before it is visible: the sender persists the tombstone below in place of the continuity record, atomically, before the first CLOSE leaves and before it reports the session closed; a transition to CLOSED is terminal for the session identifier, which neither endpoint ever restores by CONTINUE, CONTINUE_0RTT or a sealed record. If the write fails, the session is closed to the layer above at once, nothing is delivered or sent on it but CLOSE, no CLOSE leaves until the write succeeds, and the write is retried; while any closure write is pending the endpoint serves no sealed record (Section 16.6.3). Then send CLOSE up to three times 1 s apart (the initial retransmission interval of Section 9.4), if a path exists, and discard all session state except the tombstone: the session identifier (Section 8.6), under which the tombstone is stored and by which every sealed record of the session, of any generation, is recognised as closed (Section 16.6.3); the recovery identifier the peer would use to re-anchor toward this endpoint, rec(g, dir_in), derived from cs(g) at close so that a session closed while DORMANT or after a restart, which holds no live generation, leaves one too, and likewise rec(g + 1, dir_in) for a generation g + 1 armed but not committed at close, since the peer may hold it committed and re-anchor from it; the peer's receiver prefix, prefix(dir_out), needed to form the reply's routing key; the fingerprint of the identity key the session used, needed for the request's th_0 (Section 8.3), which during an identity rotation (Section 23.4) may be the retiring key's; the close reason; and, for each kept identifier, the key¶

k_tomb = Expand(cs, label("tombstone"), 48)

where cs is the continuity secret of the generation the identifier belongs to, cs(g) or cs(g + 1), derived at close, before the secrets are erased with the rest. The tombstone is kept for tombstone_ttl (Section 16.1) and persisted in place of the continuity record, so that it survives a restart; it holds no session secret. A tombstone can answer a re-anchor request but cannot open one, cannot create a generation, and cannot impersonate the session's traffic. A CLOSE sent to a peer that is DORMANT is dropped unread (Section 16.7); the tombstone is what answers that peer's later re-anchor.¶

Tombstone behaviour. A CONTINUE or CONTINUE_0RTT request arriving on a tombstoned recovery identifier is answered, without being opened, by an AnchorResponse with form = CLOSED (Section 9.2.2), reason = CLOSED, and detail set to the close reason, sealed under¶

k_closed = Expand(k_tomb, label("seal closed") || th_3, 44)

which the peer derives from its cs(g) (cs(g + 1) and g + 1 throughout, on the identifier of an armed generation), and sent to the request's source address on resp_rid(g, dir_out, nonce) (Section 8.5), which the tombstone derives from k_tomb, the stored prefix and the request's cleartext nonce. The reply is under a hundred octets (56 in Appendix D.11) to a request of over a thousand, is bound to the request's transcript, and can be produced only by a holder of cs(g) or of the tombstone. The peer, on opening it, closes with the carried reason, erases its record, and reports Closed{reason} with the reason's class (Section 20.2). The form value tells the peer which key to open with; a live responder's RETRY and a tombstone's CLOSED are never confused and never cost a trial opening.¶

Receiver. After authentication, record the reason, report Closed{reason}, send nothing, and persist a tombstone of its own in place of the continuity record, as the sender does, before discarding the session state. The closer's tombstone answers the receiver's re-anchors; only the receiver's own closure state refuses the sealed records it issued for the session, which a former peer may keep together with the session's secret and present after sending CLOSE itself (Section 16.6.3).¶

20.1. Principles

• Before authentication, every error is a silent drop. PQST sends no unauthenticated error message of any kind: no version-negotiation message, no "unknown identifier", no rejection of a handshake. Each would be a reflection vector, a reset vector, or a fingerprint. The cost is that a requester learns of failure only by timeout, and Section 9.4 and Section 16.7 size the timeouts and fallbacks accordingly.¶

• After authentication, an error is counted, ignored, or closes the session. Nothing in between: PQST has no error frame, no warning, no negotiation of a repair.¶

• The network is never an error source. ICMP messages, including unreachable and packet-too-big, MUST NOT change path, session or MTU state; an implementation MAY let them accelerate a PROBE it would have sent anyway. Loss of a path is detected by probes (Section 15.6) and is not an error.¶

20.2. Close Reasons

A close reason is one octet, carried in CLOSE (Section 19.6) and in the detail of a CLOSED response (form 5) (Section 9.2.2). Reasons are grouped by class; the class is what an upper layer acts on.¶

• 0x00. Reason: reserved; Meaning: never sent¶

• 0x01. Reason: LOCAL_CLOSE; Class: policy; Meaning: the application closed the session; Defined in: 18.2 S26¶

• 0x02. Reason: SUPERSEDED; Class: policy; Meaning: a newer session with the same peer was confirmed; Defined in: 9.6.1, 16.7¶

• 0x03. Reason: SESSION_LIFETIME; Class: policy; Meaning: lineage_gen or attempt would exceed 0xFFFF; Defined in: 9.3.3, 12.2, 16.5¶

• 0x04. Reason: DORMANCY_EXPIRED; Class: policy; Meaning: max_dormancy elapsed; Defined in: 16.7¶

• 0x05. Reason: AUTHZ_EXPIRED; Class: policy; Meaning: a grant expired without renewal; Defined in: 17.3¶

• 0x06. Reason: AUTHZ_REVOKED; Class: policy; Meaning: the grantor revoked; Defined in: 17.4¶

• 0x10. Reason: PROTOCOL_ERROR; Class: protocol; Meaning: persistent violation after authentication; Defined in: 20.3¶

• 0x20. Reason: REPROOF_FAILED; Class: compromise; Meaning: a required identity proof or certificate verification failed; Defined in: 16.3.3, 19.4.5¶

• 0x21. Reason: COMPROMISE_SUSPECTED; Class: compromise; Meaning: reserved: no rule of this document raises it, since a receiver detects no nonce reuse (Section 12.5); an endpoint closing a session on a compromise it learned of by other means MAY use it; Defined in: 12.5¶

• 0x80-0xBF. Reason: upper-layer reasons, assigned by registry (Section 25); Class: as registered¶

• 0xC0-0xFF. Reason: private use; Class: private¶

Codes 0x01-0x0F are policy class, 0x10-0x1F protocol class, 0x20-0x2F compromise class; the remaining codes below 0x80 are reserved. There is no transport class of close, because no transport event closes a session (Section 3). Every close is reported as the security-class event Closed{reason}; AUTHZ_EXPIRED, AUTHZ_REVOKED, REPROOF_FAILED and COMPROMISE_SUSPECTED are additionally reported under their own names (Section 18.5).¶

A receiver treats an unknown code as PROTOCOL_ERROR class for the purpose of acting on it and preserves the code for logging.¶

20.3. Violations After Authentication

A packet that authenticates but violates a MUST of this specification (a malformed frame, frames that do not consume the payload, a control packet with an empty payload, a PROBE_ACK matching nothing, an OBJECT segment outside its total_len, an anchor request with impossible fields) is handled as the defining section says, in every case by dropping the offending part and counting the event; its replay commit stands (Section 11.4). A receiver MAY close the session with PROTOCOL_ERROR when such events exceed a policy threshold (RECOMMENDED: 10 in 60 seconds; violation_limit and violation_window in the reference, which closes on the tenth), because a peer that persistently violates the protocol is either broken or hostile and in neither case worth keeping.¶

An authenticated peer that abuses a budgeted mechanism, by re-anchoring, migrating or probing at a rate the local policy will not sustain, is rate-limited per session before it is closed; the budgets of Section 9.4, Section 15.4 and Section 19.2 are the first line, and PROTOCOL_ERROR the last.¶

20.4. Counters

Implementations SHOULD maintain, and SHOULD be able to expose, at least these counters, per endpoint and where meaningful per session: packets dropped by size, header, unknown routing key, pre-authentication filter, and failed AEAD; replay-window rejections, duplicates and packets below the window; frames unknown and malformed; unmatched probe acknowledgements; anchor requests dropped at each check of Section 9.3 by reason; RETRY responses sent by reason; objects discarded for version or size; paths validated, lost and rebound; closes by reason. They are the only trace an unauthenticated packet leaves in authoritative state, the bounded pre-authentication work of Section 11.7 being the other (Section 11.1) and the first instrument of the validation plan.¶

20.5. Logging

A close with COMPROMISE_SUSPECTED, where an endpoint uses it (Section 20.2), is logged at the highest severity available; REPROOF_FAILED and AUTHZ_REVOKED at high severity. Logs identify sessions by their session identifier (Section 8.6) and peers by fingerprint, never by identifier or address alone, and never include key material, sealed parts, or authz_hint. Section 24 states what logs may reveal and how long they should live.¶

21.1. Versions

The version octet in every packet is 0x14 for this document. A receiver that does not implement the version of a packet drops it silently (Section 20.1); there is no version-negotiation message, because one would be an unauthenticated reflection and a fingerprint. An initiator configured for several versions sends its highest first and MAY retry a lower one after an attempt times out; the lowest version it will use is its policy, and that policy is the only protection against an attacker who drops higher-version requests. The version is in every transcript (Section 8.3), so an exchange that completes was not downgraded within itself.¶

A new version is a new value of the octet and a new document. Within a version, behaviour changes only through the mechanisms below. One of them adds a packet type: packet type 3 is reserved for a future extension, intended for a group data plane above the cohort layer (Section 26), and has no semantics in this document; the extension that defines it states its acceptance, authentication and capability rules, a receiver that does not implement it drops the type at the common header (Section 10.1.1; Section 11.1, step 2), and a packet of the type MUST NOT create or change any state this document defines unless it authenticates under keys the extension derives (I-1).¶

21.2. Suites

A suite is a fixed set of algorithms (Section 6.1). The suite in use is implied by the identity key the requester encapsulates to, selected among a responder's keys by rk_hint (Section 9.2.1), and is bound into every transcript. A deployment moves to a new suite by provisioning identity keys of the new type; endpoints that hold keys of both types can serve both during a transition. No suite negotiation exists and none is needed: agility is by key provisioning. Suite identifiers are registered (Section 25).¶

21.3. Capabilities

capabilities is a 16-bit field exchanged in the sealed parts of the FRESH exchange and fixed for the session. A bit set means the endpoint implements the feature as issuer or server; an endpoint consults the peer's bits before sending an optional object kind or relying on an optional behaviour. Unknown bits MUST be ignored.¶

Capabilities are not negotiated: each endpoint states what it does, and the peer behaves accordingly. A feature that needs agreement from both sides is on when both set its bit.¶

21.4. Extensions

The anchor exchange is extended by objects: an extension carries its data as an object in the objects of a sealed part (Section 9.2.1 and Section 19.4), under a kind registered for it, and is therefore in the transcript; a receiver ignores an object kind it does not implement (Section 21.5). The binding statement (Appendix A) has an ext field of ext_type(2) ext_len(2) ext_data(*) entries, bounded by the enclosing length; a receiver MUST ignore an extension type it does not implement and continue, and MUST NOT fail the verification for it. An extension MUST NOT change the behaviour of anything this document specifies for an endpoint that does not implement the extension. Extension types are registered (Section 25); the range 0xC000-0xFFFF is private use.¶

21.5. Codepoints

Frame types, object kinds, close reasons, stream identifiers, RETRY reasons, forms and message types each have a registry with a reserved range for upper layers and a private-use range (Section 25). Receivers skip unknown frame types, acknowledge and ignore unknown object kinds, treat unknown close reasons as protocol class, and discard data on unimplemented reserved stream identifiers, as the defining sections state; none of these is fatal. Reserved codepoints are never reused with another meaning within a version.¶

21.6. Principles

• Everything that affects a sealing key is in that key's transcript before the key is derived; the lineage and the session root take the request's transcript, and the continuity secret the shared secrets alone (Section 8).¶

• No negotiation exists in CORE, so no downgrade within an exchange exists; the only downgrade surface is the initiator's version floor, which is policy.¶

• Unknown is ignorable at every level except the version octet and the reserved bits of the packet and block headers, which are the fingerprint-free, cost-free places to reject garbage; a reserved packet type is dropped there unless the receiver implements the extension that defines it.¶

• CORE semantics are stable across extensions and capabilities; an endpoint that implements only CORE interoperates with every endpoint of the same version.¶

22.1. What Changes Each Part of a Session's State (Informative)

A session's state has several parts that move independently, and a packet can be authentic without being evidence for all of them. The table restates, from the sections named, what changes each part and what does not; nothing in it is new.¶

23.1. The Anchor Exchange

Authentication. In FRESH, the requester encapsulates to the responder's identity key and the responder to the requester's; both secrets enter cs(0). A response that opens proves the responder holds ss_peer, hence its identity key; the requester's first protected packet proves it holds ss_req, hence its identity key. Authentication rests on the IND-CCA2 security of ML-KEM-1024 and on key confirmation, not on signatures, which is the structure of the KEM instantiation of Noise IK [Noise] analysed for PQ-WireGuard [PQWireGuard]; PQST adds the transcript hash as info in every derivation and binds the intended peer identity, the version, the suite and any DISCOVER prefix into th_0. In the CONTINUE forms authentication is possession of cs(g - 1), which is the session, and identity proofs are added by flag.¶

Key-compromise impersonation. Compromise of the responder's identity key lets an attacker read the identities in captured requests and impersonate the responder to anyone, but not impersonate another requester to the responder, because that requires decapsulating ct_req with the requester's key; symmetrically for the requester's key. Each party's authentication of the other depends on a decapsulation only the other can perform.¶

Early data is not delivered exactly once. The consumed prekey and recovery identifier make zero-round-trip early data unreplayable toward a stateful receiver: an attacker cannot have the original packets accepted again under the receiver's state. They do not make its delivery exactly once across the outcomes of a recovery: in a gateway group one gateway may arm the generation and deliver the early data while another answers RETRY, and the requester, which then repeats the attempt as a CONTINUE, cannot know whether the data was delivered (Section 16.3.2). An application that sends an action as early data and repeats it after a RETRY must make the action idempotent or carry a transaction identifier; the transport reports the attempt's refusal and never reports the early data as undelivered.¶

Forward secrecy comes from ss_fresh: the ephemeral decapsulation key or the single-use prekey, erased after one use. Later compromise of both identity keys yields ss_peer and ss_req from captured traffic and nothing else; cs(g) is not recoverable. Within a lineage, the erasure of an epoch secret hides that epoch's traffic from an attacker who obtains only a later epoch secret, and not from one who obtains the retained lineage_secret; forward secrecy of a generation's traffic against compromise of the endpoint begins when the generation is retired and its cs and lineage_secret are gone (Section 14.3).¶

Post-compromise security comes from the ratchet: every re-anchor folds a fresh KEM secret into cs(g + 1) and erases cs(g). Against a passive adversary that learned cs(g) and takes no part in the next re-anchor the successor is secret, and the scheduled re-anchor makes that happen within reanchor_interval. An active adversary holding cs(g) can authenticate an ordinary CONTINUE without either identity key, and if its exchange commits first it holds the successor instead of the legitimate endpoint: ordinary continuity, recovery and generation advance are not fresh verification of identity. What bounds that adversary is the identity re-proof deadline of Section 16.3.3: an exchange that proves the peer encapsulates to its identity key, which the holder of the continuity secret cannot decapsulate; a proof is sought a reanchor_interval before the deadline, nothing above the session moves after it without a proof, and the session closes when the proving exchange fails. max_dormancy bounds dormancy, not an actively maintained session, and a grant's lifetime bounds authorization, not identity. The race is real and stated: a thief who re-anchors before the legitimate endpoint holds the session until the deadline and no longer.¶

Exporter compromise and recovery. A re-anchor changes the lineage-scoped exporter's root and nothing session-scoped: session_root is derived once and kept for the session's life (Section 8.6). An adversary that obtains session_root, or the generation-0 material it derives from, keeps deriving session-scoped exports after every later re-anchor; recovery of such material needs a new session, by FRESH, whose root is independent of the old. Lineage-scoped exports are healed by a re-anchor whose fresh input the adversary does not hold, as the continuity secret is. Applications put material meant to rotate with post-compromise recovery in lineage scope, and the session identifier and bindings meant to last in session scope, knowing what each survives.¶

Identity hiding holds against passive observers and against active attackers who do not hold the responder's identity key. It does not hold against a later compromise of that key for captured requests, and flight sizes reveal that an exchange occurred (Section 24).¶

Replay. A replayed FRESH request whose exchange was confirmed fails the freshness counter after one decapsulation and gets no reply; one replayed while its exchange is half-open is answered from the reply cache; one never confirmed and replayed after its exchange expired is served again and can never be confirmed, which costs the responder what a forged request costs and ends at the requester's next confirmed FRESH (Section 9.3.5); a replayed CONTINUE request gets at most the cached reply at the original address; a replayed CONTINUE_0RTT request at a stateful responder finds its prekey consumed; at a stateless responder serving from a record it yields an armed generation no one can use (Section 16.6.3).¶

Reflection. Section 9.5 and Section 15.4 together bound what an endpoint sends toward an address it has not validated to what it received from it, for authenticated and unauthenticated input alike, beyond two named allowances: the probe floor of k_probe probes of 56 octets per address and interval, kept across the budget table's forgetting so that churning the table yields no second floor, and the previously validated addresses, which send unbudgeted for validated_ttl toward an address the peer legitimately held, which is why that lifetime is minutes. The bound against third-party reflection therefore rests on path validation, on the expiry of previous validation and on the endpoint-wide budget, not on a ratio alone. An authenticated anchor response proves possession of the exchange's secrets, not control of the address it appears to come from, which an attacker that observes or relays an authentic response can set at will; a response therefore validates the address the request was sent to, never its own source, and an unknown source stays within the budget until a probe sent to it is answered (Section 9.3.8, Section 15.7). Without that rule one relayed response would lift the budget toward any address.¶

Denial of service. The unauthenticated path performs public key operations only on a complete FRESH request whose cleartext parses, and two attackers are to be told apart. One without a sealed part that opens, the blind forger and the stale replay, costs one decapsulation per identity key the responder holds before any other check that could reject the request, and, rejected, holds no half-open state (Section 9.3.2); at line rate on a 1 Gbps link that is about 40,000 decapsulations a second, roughly one core. One holding the responder's public key and the fingerprint of an identity the responder authorizes, which the responder's peers all hold, can make a request that opens with a fresh counter: it costs the responder that decapsulation, two encapsulations, the key schedule, a response of at most the request's size (Section 9.5), a half-open entry until anchor_timeout and the write-ahead of that entry (Section 16.4), and nothing keyed by the identity, whose counter mark does not move until confirmation (Section 9.3.5); the half-open bounds per source address and per claimed identity (Section 9.4) cap what one such attacker holds at once, and the work per request is the work of one establishment, which the responder was provisioned to do for that identity. The pre-authentication tag moves the rejection of strangers of both kinds before reassembly and before any public key operation. The figure is a benchmark for one implementation on one machine, not a property of the protocol. Established sessions cannot be modified by any handshake-path load, because recovery is located by identifier, authenticated with one AEAD under cs(g - 1) before any public key work, and reassembled in a pool the handshake path cannot occupy (Section 9.4); the work a flood can cause is bounded by the admission controls of Section 9.4 and the rate limits of Section 11.6. Whether recovery proceeds at full speed while the handshake path is saturated is a capacity property of an implementation, its workers, queues and buffers, which an implementation that claims it demonstrates by measurement: recovery latency and continuity under increasing rates of invalid FRESH requests, with the pre-authentication tag off and on. The protocol's property, worth stating to operators as such, is that an attack on new sessions cannot reach into the fleet's sessions; the implementation's property is how much of its capacity it keeps for them.¶

What an unconfirmed FRESH reveals. A request that opens with a fresh counter is answered; one naming an identity the responder does not authorize, or carrying a stale counter, is dropped in silence (Section 9.3.2). Whoever can make a request that opens therefore learns, from the presence of a response, whether the identity it named is authorized at this responder, and, by trying counters, where that identity's freshness mark stands, in at most 64 requests. Neither changes any state: the mark moves only on confirmation (Section 9.3.5, I-21), and the response seals its grant to the holder of the named identity's key (Section 9.3.9). What is disclosed is a membership and a counter, which a passive observer of the identity's own exchanges with this responder learns more slowly. A deployment for which that matters configures the fleet secret (Section 9.3.4): without psk no request passes the tag, so nothing is answered and nothing is learned; Section 24.4 states the privacy side.¶

Deniability. Nothing is signed online, so no party can produce a transferable proof that the other participated. This is a privacy property and an audit limitation; authorization references and upper-layer records are where accountability lives.¶

Downgrade and agility. One suite per identity key type, bound into every transcript; no negotiation; the version floor is the initiator's policy (Section 21).¶

23.2. The Data Plane

Nonce uniqueness is the single property whose failure is catastrophic with AES-GCM. It rests on the sender's rules of Section 12 and nothing else; the receiver's detection is defence in depth. The two rules implementers break are resuming an epoch after a restart and allocating a sequence number under one epoch's counter while encrypting under another's keys; Section 12.6 and Section 12.7 exist for them.¶

AES-GCM limits. 2^23 packets per key is the [RFC9001] figure for packets up to 2^11 octets; it is conservative for 1,200-octet packets and costs nothing because an epoch advance is free.¶

Header protection hides the epoch, sequence, stream, flags and padding length from observers but is not an integrity mechanism; integrity comes from the block being associated data. The mask key is per generation and direction, so its compromise reveals the metadata of one lineage and nothing else. The timing difference between a filter drop and an AEAD drop reveals only possession of the mask key. The filter's bound of about 2^-80 holds for a block an attacker had to guess. It does not hold for an active attacker who holds a legitimate packet whose sequence number the receiver has not yet accepted: keeping the routing key, the masked block and the first sixteen octets of ciphertext, which the mask is derived from, and altering the tag, the attacker makes variants that unmask to the same valid header, pass the filter and fail only at the AEAD, as many as it sends until it lets the original through. Nothing of the receiver's state moves, the one-AEAD-per-datagram invariant holds, and the integrity bound is counted (Section 12.4); what the attacker gains is one AEAD of the receiver's work per datagram it sends, the same as any forged datagram costs a protocol without a filter. An implementation that limits the rate of failed verifications it attempts per routing key does so far above any legitimate rate, since a limit that drops packets at an identifier drops the legitimate sender's too; the filter alone is not an argument that forgery attempts are negligible.¶

The one-AEAD rule and the two-phase check are where a privacy feature becomes a session-killing bug if implemented loosely: a receiver that retries under other keys, or advances a window before authentication, hands an off-path attacker a way to desynchronise or exhaust the session. Both are invariants with required tests (Section 22).¶

Derived identifiers are unpredictable to anyone without the lineage secret and need no signalling, so there is no identifier-allocation protocol to attack. Their one cost is the collision rule of Section 15.1, which fires with negligible probability without a prefix and rarely with one, and resolves by re-anchor.¶

Cross-path copies. An on-path attacker that copies a protected packet onto another path of the same session, or relabels it with another of the session's routing keys, which the associated data does not cover (Section 10.2.2), delivers at most what the original would have: the replay window is the session's, not the path's (Section 13), so whichever copy arrives first is accepted once and every other is a duplicate; the path the accepted copy arrives on gains the liveness evidence any authentic packet gives it and nothing more, sending toward an address still waiting on validation (Section 15.3); and a copy moved to a path of another session fails that session's AEAD.¶

23.3. Recovery, Records and Groups

The continuity record is the session; its protection at rest is the protection of every session the device holds. Section 16.6.2 requires that recovering it take the identity key, which makes a storage image useless when the key is in hardware. Hardware keystores that decapsulate ML-KEM-1024 are not yet universal; where the key is software on the same storage the rule still costs nothing and reproof_after_restart is available as policy. Records are erased on close, revocation, supersession and generation regression.¶

Prekeys give forward-secret zero-round-trip recovery; their decapsulation keys are the only long-lived private material besides the identity key, which is why a regenerating issuer MUST rotate and erase its local_secret at least every max_dormancy.¶

Recovery that supersedes. One case recovers by a new session instead of continuing the old one: a requester that commits on a response and is then cut off for the life of the responder's armed generation (Section 16.10). It is safe and live, and costs the session identifier; the layer above sees a supersession (Section 16.7). A second case has the same cost and the same safety: an outage that ends while both endpoints run their recovery schedules, when the initiator's FRESH completes before a CONTINUE does (Section 16.10).¶

Evidence that the peer is alive. An initiator that has heard from the peer within an interval makes a CONTINUE instead of its scheduled FRESH (Section 16.7), so what counts as hearing decides whether a peer that has lost its state can be recovered from. A protected packet counts because the replay window admits each one once; a request counts only if its attempt is above every one seen, because a recorded request replayed still opens under the session's secret, and an attacker able to send spoofed packets could otherwise hold back every FRESH with one old capture (Section 16.7). What remains needs an attacker on the path: packets of the peer's that it withheld and releases one per interval are new to the replay window and count. Such an attacker can as well drop everything, and so gains nothing it did not have; the session stays safe, and recovers once the attacker stops.¶

The record key protects the continuity secrets carried by every sealed record an observer captured; its compromise exposes the generations those records name, which is why Section 16.6.3 bounds its lifetime by rotation and erasure. It deserves the protection of the identity key.¶

Stateless service from sealed records holds the no-fork property in its usable form and degrades zero-round-trip data to one round trip, never to replayable data. A requester cannot tell, from a RETRY, whether another member of a gateway group delivered its early data (Section 16.3.2): zero-round-trip data is at most once per member state, and of unknown fate when refused.¶

Gateway groups. Session portability across gateways requires one replicated identity key, one sealing key and one prefix convention; compromise of one gateway is compromise of the group identity, and the group should treat its gateways as one trust boundary with the key in hardware at each. Single gateways are the degenerate case.¶

The malicious authenticated peer can do exactly what Section 4.4 says and no more. The design treats a valid identity as a reason to deliver its traffic, never as a reason to trust its claims about addresses, rates or other sessions.¶

23.4. Operational

• PQST performs no congestion control; the traffic it carries brings its own, and [RFC8085] applies. PQST's own traffic is bounded: one probe per interval per path, one acknowledgement per object version, anchor messages at the retransmission schedule.¶

• Any number of sessions in either role share one port; nothing in the protocol depends on port numbers.¶

• No synchronised clock is needed by packet protection, replay prevention, the pairwise re-anchor or the session's timers, which run on monotonic local clocks; the absolute times are in optional certificate validity and in the sealed records of a gateway group, whose age check tolerates a skew of five minutes among the group's members (Section 16.6.3), the one place a deployment's clocks must agree.¶

• ICMP is never a state input (Section 20.1).¶

• Logs identify sessions and peers as Section 20.5 says and never contain key material.¶

• Symbolic models of the three anchor forms (Tamarin; FRESH, CONTINUE, CONTINUE_0RTT, each one exchange) establish, under a Dolev-Yao adversary that may reveal long-term keys, ephemeral keys, continuity secrets and prekeys, the cryptographic properties of Section 9.8 for the modelled exchanges: secrecy and forward secrecy of cs(0) and of cs(g), injective agreement, resistance to key-compromise impersonation, the binding of a DISCOVER through prior, healing of a one-time leak against a passive adversary, the identity-proof requirement, agreement on generation and lineage, and the single use of prekeys and early data; a fourth model covers tombstones and sealed records. They show the limit of Section 16.10 as an attack: a holder of cs(g - 1) completes a CONTINUE without proofs in either role. They do not establish identity hiding, the reflection and cost bounds, deniability, the re-proof deadline of Section 16.3.3, which is a policy with its own tests, crash recovery or gateway-group behaviour; Section 27 states each model's scope, and the correspondence note beside the models maps their operations to the implementation.¶

Identity key rotation. A responder rotates its identity key by holding two keys for an overlap: the new one, which it gives to requesters from then on, and the retiring one, distinguished by rk_hint (Section 9.2.1; with an unspecified hint the responder tries both, never more than two). A FRESH request is served under whichever key it was encapsulated to, and a session remembers the key it was established under, which it needs for every later proof of the responder (prove_peer, Section 16.3.3) and keeps in its record (Section 16.6.2); records written before the rotation are read under the retiring key, and a sealed record names the key by its associated data (Section 16.6.3). Sessions need nothing else: a CONTINUE without prove_peer is authenticated by the session's own secret, whichever key began it. The retiring key is erased once no session established under it remains or max_dormancy has passed since the rotation. A proof of the responder demanded of a session after that fails, and the requester delivers nothing above the session from the first unsatisfied demand and closes it with REPROOF_FAILED at the deadline (Section 16.3.3), a compromise-class report for what was a planned rotation; a requester that has learned the new key avoids it by replacing each session established under the retiring key with a FRESH exchange to the new key that carries SUPERSEDE (Section 16.7), before the retiring key is erased. The new session carries the new fingerprint, and the layer above, which knows of the rotation from the same source as the new key, relates the two. Requesters learn the new key out of band, by DISCOVER (Section 9.7) or from a certificate (Section 9.7.3); the freshness counter is one counter across every responder (Section 9.3.5), so the rotation never makes a requester's FRESH look stale.¶