Post-Quantum Secure Transport (PQST): Overview and Reading Guide

Introduction This document specifies nothing. Where any statement in it appears to conflict with "Post-Quantum Secure Transport" or "The Cohort Layer of Post-Quantum Secure Transport" , those documents govern. Words such as "must" and "required" in this document are ordinary English or are summaries of statements in those documents; they are not requirements of this document.

Why This Document Exists The core PQST specification is a large implementation-oriented draft proposed for review: a handshake, a data plane, path management, dormancy and crash-consistent recovery, authorization, a state-object mechanism, and the registries and invariants that hold them together, specified in one place. We recognize that the time commitment that we are asking of readers is a substantial one, and this document exists as a quick overview so that you can rapidly decide whether the problem and/or design are relevant to IETF or of interest to you. In this document, you will find the problem, the design's five commitments, one session's life, the security model with its qualifications explicitly stated, the costs, the evidence, the limits, and a map to the parts of the specifications written for each kind of reader.

The Document Family

Document	Intended status	What it is
	Standards Track	The core pairwise protocol: the anchor exchange, the data plane, paths, dormancy and recovery, authorization, objects, and their invariants.
	Experimental	A membership, policy, reachability and discovery control plane over PQST sessions, run by a sequencer. It specifies no group data plane in this version.
This document	Informational	A non-normative overview and reading guide to the two documents above.

The cohort layer depends normatively on the core protocol. This overview depends on neither in the protocol sense: nothing can be implemented from it, and an implementation built from this document alone would not interoperate with anything. It is posted as an Informational Internet-Draft to serve as a reading guide now; whether it should progress further is a later question, and nothing in the specifications requires it to be read first.

How to Use This Guide A reader in a hurry can read and and stop with an accurate mental model. A reader deciding whether to invest further should continue through and , where the qualifications and limits are collected. maps each kind of reader to the sections of the specifications written for them, and lists the questions the author is bringing to the community.

The Problem

Three Situations Most secure networking protocols tie their cryptographic state to a connection or a security association that must be retained, resumed or reconstructed when connectivity disappears. PQST asks a different question: can the authenticated session itself survive after the network paths and the live cryptographic state are gone? PQST makes session continuity an explicit transport mechanism: how new secrets are established, how the previous session is authenticated, and what happens when recovery fails or either machine crashes. The problem begins where the live cryptographic and transport state of a secure association is gone, in three situations. The process is gone. A tunnel endpoint restarts (a crash, upgrade, and/or device reboot). Live keys, replay windows and sequence state are gone with the process. In deployed transports the live session is gone too; what the endpoint kept on disk, a configured peer, a ticket, a security association's parameters, lets the next session be built faster, not the same session continue, and continuity, where a deployment has it, is reconstructed at some other layer with its own state and semantics. The network was gone longer than live state is worth keeping. In disconnected, intermittent and limited environments, such as radio nets, connectivity returns after hours or days. Holding idle cryptographic and transport state for days would be a suboptimal trade, but so would paying full re-establishment, re-authentication and re-authorization as though a known peer were an untrusted stranger. A different machine must answer. In a gateway group, the instance that holds a session fails or is drained, and another instance of the same group is expected to take the session up without the peer seeing a new peer. Existing transports answer parts of this, each by its own mechanism. What none of them specifies is the logical session itself: its identifier, its authorization, and the bindings above it surviving the loss of everything else as defined transport behaviour, with the persistence, erasure and failure semantics of that survival specified rather than left to the deployment. That is PQST's reason to exist.

What Deployed Transports Do Instead

QUIC with TLS 1.3 . Process restart: a new connection (resumption is a new connection with resumed parameters); Long dormancy: the connection may be retained while both endpoints keep its state; Another instance takes over: not a property of the transport; Post-quantum key establishment: through TLS
WireGuard , with Rosenpass . Process restart: a new handshake under a persistent configured peer; Long dormancy: the configured peer persists; traffic keys are replaced by new handshakes; Another instance takes over: not specified; Post-quantum key establishment: not in the baseline; Rosenpass adds a post-quantum rekey
IKEv2 with MOBIKE . Process restart: re-established, or resumed from a ticket as a new IKE SA ; Long dormancy: retention is an implementation liveness decision; Another instance takes over: not specified; Post-quantum key establishment: multiple key exchanges
PQST. Process restart: re-anchored from the continuity record as the same session, within the limits of ; Long dormancy: a defined DORMANT state holding only the continuity record; Another instance takes over: sealed records and gateway groups (); Post-quantum key establishment: native, by ML-KEM in establishment, recovery and re-proof alike

Where a cell says "may be retained" or "not specified", the other protocol has, or permits, the behaviour; PQST claims no novelty in it. The rows that distinguish PQST are the first three columns' last row: the same session, as a specified outcome.

The Architectural Alternative Nothing in this design makes the alternative impossible. A session layer above QUIC, or above MASQUE's UDP and IP proxying and , could keep its own identity, authorization and continuity state across connections, and would inherit mature HTTP infrastructure, proxy traversal and congestion control. PQST is the other shape: one purpose-built protocol over UDP, with direct control of cryptographic recovery and a state model built for severe intermittency, at the price of being a new transport. Which shape is simpler, cheaper and more predictable in the environments of is an open question, and it is the first question of . The purpose of this submission is not to challenge or dismiss existing protocols, but rather to contribute a new perspective to the discussion by starting from a different problem set.

PQST at a Glance One mechanism, the anchor exchange, establishes a session and, performed again from it, serves six more roles: recovery after the loss of every path, survival across a restart, the post-compromise ratchet, identity re-proof, and the renewal of identifiers and of the lineage (). The rest of this section says what makes that possible.

The Inversion PQST orders its objects by how long they live, and holds the order as a rule: A path event, by itself, changes neither the authenticated identity, nor the committed generation, nor authorization, nor any binding above the session; it selects which path the session uses. Conversely, a session with no path at all is a defined state with defined behaviour, not an error. Everything else in the design is consequence or machinery of this ordering (Sections and of ).

The Five Commitments Continuity is durable, and its durability is specified. What an endpoint keeps while dormant or across a restart (the continuity record) is written ahead of every transmission that depends on it, committed atomically, and erased on close, with a tombstone left to answer late recovery attempts. Crash consistency is a protocol requirement with stated failure semantics, not an implementation suggestion (Sections and of ). One exchange establishes and recovers. The anchor exchange, in its FRESH form, creates a session; in its CONTINUE forms, performed from an existing session, it creates the session's next generation of secrets from the previous generation plus a fresh post-quantum secret. Re-anchor is the single 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 needs no round trip (Sections and of ). Identity is a KEM key. An endpoint's long-term identity is an ML-KEM-1024 key pair, and a peer proves its identity by decapsulating. No signature is computed online in any exchange; ML-DSA-87 appears only in offline certification of identity keys, which the core protocol does not need (Sections and of ). Nothing unauthenticated changes authoritative state. The receiver performs at most one AEAD operation per protected packet, and replay, epoch and path state move only after that operation succeeds. What an unauthenticated datagram may cost before that point is bounded and named; no error is signalled to an unauthenticated sender (Sections to of ). Nothing is signalled that can be derived. Packet identifiers, recovery identifiers and epoch keys are derived by both endpoints from the session's secrets. The epoch and the sequence number travel header-protected; PQST's own per-packet overhead is 44 octets. What cannot be derived, such as grants, prekeys, sealed records, inner addresses, is carried as a small set of versioned state objects with one reliability rule (Sections , , and of ).

What PQST Is Not PQST provides neither reliable delivery nor congestion control. It is designed for the case the UDP usage guidelines treat first (): a tunnel carrying congestion-controlled IP unicast, whose rate is the carried traffic's and which therefore performs no congestion control of its own. A deployment that carries traffic without congestion control, or whose tunnel rate is not set by the carried traffic, needs the safeguards those guidelines recommend for that case, a circuit breaker among them (); the specification does not yet state that expectation, nor the treatment of the carried packets' ECN marking, and keeps both as questions. PQST's own traffic is bounded: anchor messages and state objects are retransmitted on a doubling schedule from one second to sixteen, there is one probe per interval per path, one acknowledgement per object version, and redundant transmission sends at most one copy per validated path (Sections , , and of ). PQST gathers no candidate addresses and traverses no NAT: an address learned elsewhere is a hint, and validation is by probe. PQST is not a group protocol; the cohort layer of is built on it as a separate, Experimental specification.

A Session's Life Two endpoints, provisioned with each other's identity keys as in a WireGuard-style deployment, neither holding any session. Establishment. The initiator sends a FRESH anchor request: a fresh ephemeral ML-KEM key, an encapsulation to the responder's identity key, and a sealed part carrying its own identity, capabilities and grant. The responder decapsulates, encapsulates to the ephemeral key and to the initiator's identity key, and answers. Both sides derive generation 0; the initiator's first protected packet confirms its identity, and the session is established. One round trip to initiator data; about 3.3 KB of anchor messages each way; no signature (). Ordinary life. Each protected packet carries a derived routing identifier, a header-protected block naming the epoch and a 64-bit sequence number, and an AEAD-protected payload. Either endpoint advances the epoch by naming the next one in a packet; the keys are chained, and a successful opening is the advance's authentication. Packets may arrive on several validated paths; a path is validated by a probe and answer, and losing one is an ordinary event that changes nothing above the path (Sections , and of ). RECOVERING RECOVERING --(schedule exhausted)--> DORMANT RECOVERING or DORMANT --(re-anchor commits)--> ESTABLISHED any state --(close)--> CLOSED; a tombstone answers late re-anchors ]]> Loss and return. When the last path is lost the session is RECOVERING, retaining its state while a recovery schedule runs. If the peer does not return, the session becomes DORMANT and discards everything but the continuity record. This record is approximately 5 KB between exchanges, about 2 KB where prekeys are regenerated from a local secret, up to about 12 KB while an exchange is in flight (). Identity, the current generation's secret, authorization state and exporter roots remain; live keys, replay windows and identifiers do not. Return, whenever it comes, is a CONTINUE re-anchor on a recovery identifier derived from the current generation: fresh key material, the same session. A restart is the same story told by the record: no epoch is ever resumed, sequence state is never persisted for reuse, and the first generation that sends after a restart is one created after it (Sections and of ). One wrinkle is stated rather than smoothed over: on a very slow, lossy link, recovery can complete as a new FRESH session superseding the old one, and the layer above sees a close and a new establishment with the same peer instead of one session continuing (). Close. A CLOSE frame with a classed reason ends the session; the record is erased, and a tombstone, holding only the keys needed to answer a late re-anchor with a sealed CLOSED response, remains for a bounded time (Sections and of ).

Why Recovery Is a Security Problem A secure session is more than a set of encryption keys. It is an agreement between two endpoints about whom they are talking to, which cryptographic state is current, and what that state authorizes. PQST's recovery has to preserve that agreement when the machines keeping it fail. Four design decisions show why that is harder than performing another key exchange. A key must have an agreed meaning. Two endpoints performing a post-quantum key exchange may both compute fresh secret material and still not agree on what it represents: a new session or the continuation of one; which identities took part; which protocol version and exchange form; which previous state, if any, it continues. A protocol that does not bind these facts cryptographically risks accepting keys under different readings of the same exchange. PQST binds the exchange's context into its transcript, the wire version, the suite, the intended peer identity, the exchange form and any preceding discovery exchange among the inputs, and matches every response to the outstanding attempt it answers; the keys that seal each message are derived from the transcript to that point, and the lineage and the session's root from the request's transcript. The resulting state belongs to that exchange and to the transition it makes, not to an arbitrary successful encapsulation (Sections and of ). A crash must not create two versions of the session. Consider a re-anchor from generation g to generation g + 1. The responder authenticates the request, derives the next generation and answers; the requester receives the answer and computes the same secrets. If either machine crashes between computing those secrets and recording them durably, the two may hold different parts of the exchange, and one may send under a generation that vanishes at its restart while the other has already accepted it. PQST distinguishes prepared from committed state: the responder records the armed generation and its cached response durably before sending; the requester commits its new generation, with its recovery record, before using it; the responder commits the armed generation only on the authenticated confirmation, durably, before it delivers anything under it; and a write that fails leaves provisional state provisional, with retransmission and cached responses carrying the exchange on. The asymmetry is deliberate: the responder may hold a durable but uncommitted generation while the requester has committed, and the specification says how that temporary disagreement resolves without either side inventing a competing history. Simultaneous re-anchors, delayed messages, writes with unknown outcomes and process restarts are all part of the problem; so is closing, where a tombstone keeps a late recovery attempt from reviving an ended session. These rules do not guarantee that every recovery succeeds as the same session: an attempt can expire, and a new FRESH session can supersede the old one. Instead, they say under what conditions continuity is preserved and what happens when it cannot be. The security of the exchange rests not only on the cryptography but on exactly when each endpoint may believe the cryptography has taken effect (Sections , , and of ). Continuity and post-compromise recovery are different goals. PQST keeps one logical session while replacing its traffic secrets again and again, and that creates a choice for the layers above. Some values must stay stable across recoveries; others should become independent of any secret an adversary may have taken. PQST therefore offers two exporter scopes. A session-scoped export is stable for the session's life: it preserves bindings that must survive re-anchors, and a compromise of its root is not healed by later re-anchors. A lineage-scoped export changes at every re-anchor: it heals when the new generation takes in fresh secret material the adversary lacks, and the application must accommodate the change. Neither scope is better in general; one preserves continuity, the other permits renewal, and PQST makes the choice explicit rather than pretending that one secret can stay unchanged and recover from its own compromise (Sections and of ). Receiving a packet is not permission to change state. An active attacker can send packets with any header, among them packets that appear to announce a new epoch or carry a very large sequence number. A receiver that moved its replay window or its keys because such a packet arrived could be steered by an attacker who holds no key. PQST separates tentative processing from authoritative change: the receiver may do bounded work to identify a packet and attempt to authenticate it, but a failed authentication advances no receive epoch, commits no replay window and validates no path. The replay check before authentication is side-effect free, and the window moves only after authentication and the acceptance checks that follow it. The principle reaches past packets to recovery and persistence: computing a value, receiving a message and durably accepting a transition are three different events (Sections to and of ). The four decisions express one philosophy: security state changes only on sufficient authenticated evidence, and a change that must survive a failure becomes durable before anything depends on it.

Security Model in One Page

Adversaries The threat model () considers an on-path network adversary that observes, drops, delays, replays and forges; a malicious authenticated peer, trusted with its identity and nothing else; a holder of an endpoint's storage image; a holder of one session's continuity secret without the identity key; a compromised gateway of a gateway group; and a denial-of-service adversary sending at line rate. Endpoint-memory compromise beyond those bounds, side channels below the protocol's constant-time requirements, and traffic analysis are out of scope.

Guarantees

Guarantee	By what mechanism	Argued in
Mutual authentication without online signatures	encapsulations to both identity keys enter the first continuity secret; key confirmation by the first protected packet	Sections and of
Confidentiality and integrity of data	AES-256-GCM under per-epoch, per-direction keys derived by the key schedule; header protection of epoch and sequence	Sections , , , of
Forward secrecy, post-compromise healing	fresh KEM secret at every re-anchor, previous continuity secret erased on commit at re-anchor granularity, with the qualifications of	Sections , of
Replay protection	per-epoch sequence windows, checked tentatively before and committed only after authentication
Amplification and reflection control	answers no larger than their requests; byte and packet budgets toward unvalidated addresses	Sections , of
Bounded cost of unauthenticated input	at most one AEAD attempt per protected packet; no authoritative state change before authentication

states these and the rest as 23 numbered invariants, each with its enforcement point; argues them and their limits.

Three Important Security Trade-Offs These are part of the security model, stated in the specification, and collected here so that no reviewer has to excavate them.

Continuity is, between identity proofs, a bearer secret. A CONTINUE re-anchor is authenticated by possession of the current continuity secret: a holder of that secret, and of no identity key, can re-anchor as the endpoint until an exchange proving the peer's identity key succeeds. The bound is the identity re-proof deadline. At the defaults of , nothing above the session moves more than 24 hours after the last proof without one; a deployment can disable the deadline and thereby claims no bound. Erasure of the previous secret at commit heals a passive leak at the next legitimate re-anchor; an active holder is bounded by the deadline and by nothing else.

Zero-round-trip recovery data is not exactly-once. Toward a stateful responder, a consumed prekey and recovery identifier make early data unreplayable by anyone else, and it is forward-secret. But where more than one state can answer, such as a gateway group, one member serving from state and another from a sealed record, an attempt can be refused after its early data was delivered, and the sender cannot learn which happened. Data sent at zero round trips must therefore be idempotent or carry its own transaction identifier; the transport reports the refusal and never reports the data as undelivered.

Session-scoped exported material does not heal. Keys an upper layer exports in session scope are derived from a root established in generation 0 and kept for the session's life, so that bindings survive re-anchors. An adversary who obtains that root keeps deriving session-scoped exports after every later re-anchor; only a new session gives independent exports. Lineage-scoped exports, by contrast, change at every re-anchor and heal with it. Material that must rotate with post-compromise recovery belongs in lineage scope.

Analysis to Date The anchor exchange is the KEM instantiation of the Noise IK pattern , as in PQ-WireGuard and Rosenpass , and its PQST form has been modelled in Tamarin: the three anchor forms, one exchange each, under an adversary that may reveal long-term, ephemeral, continuity and prekey secrets, with a fourth model covering tombstones and sealed records. The commit protocol has been modelled in TLA+ over a network that loses, duplicates, delays and reorders, with restarts and with the continuity record's writes given held, failed, and held-but-reported-failed outcomes; the checks are bounded, and the bounds are stated with the results. Sections and of account for what these models establish and what they do not, which includes identity hiding, deniability, the reflection and cost bounds, crash behaviour in the Tamarin models, and gateway-group behaviour in both.

Costs, Evidence and Limits

Costs

Quantity	Value, in the suite of
Establishment (FRESH)	one round trip to initiator data; about 3.3 KB of anchor messages each way
Re-anchor (CONTINUE)	about 1.7 KB of anchor messages each way; one round trip, or none with a prekey
Per-packet overhead	44 octets of PQST header, protected block and tag, excluding IP and UDP headers
Continuity record	about 5 KB between exchanges; up to about 12 KB with an exchange in flight
Price of a forged FRESH request	one ML-KEM-1024 decapsulation before any cheaper check can reject it; the specification prices this at about 40,000 decapsulations per second, roughly one core, at 1 Gbps line rate (), a measurement of the reference implementation on one machine, which the specification says is not a property of the protocol -- and places no return-routability proof in front of it in this version

The sizes in the table are those of the wire formats; the one rate in it is measured, not specified. Fragmentation is part of these costs on small-MTU paths: anchor messages travel in fragments of at most 1,183 octets by default, a lost message is retransmitted whole on a doubling schedule, and an optional parity fragment recovers a single lost fragment of a flight (Sections and of ).

Evidence A Go reference implementation covers the core specification, including the test vectors of Appendix D of , which an implementation reproduces to claim conformance, and negative test vectors with state assertions. A second implementation in Python, a separate codebase written from the specification text alone by an agent given no access to the reference implementation, under the author's direction (independent code, not independent authorship; the external reviews recorded in the change log were conducted independently of both), reproduces every test vector and interoperates with the reference over UDP on establishment and re-anchors requested by either side, data after each, both identity proofs, close, epoch advance and the recovery schedule; what it does not cover, including serving sessions from sealed records, gateway groups, grant lifetimes and revocation, is listed in and is not reported as interoperated. A discrete-event simulator exercises recovery, path churn, loss, replay, spoofed sources, restarts with and without the record, and storage faults against the specification's invariants over campaigns of up to 10^6 generated scenarios; reports the campaigns, their distributions and their limits. The implementation's repository is available from the author on request. The author's comparative measurements of recovery delay against WireGuard, Rosenpass over WireGuard, IKEv2 with MOBIKE and MASQUE exist, one implementation on one machine at four link speeds with loss, and are kept with the implementation's results rather than in these documents (); the comparison these documents make is the qualitative one of the table in .

Limits The full list is . The limits a prospective adopter should weigh first:

The continuity claim holds while the continuity record is recoverable and recovery completes as a re-anchor. When a recovery FRESH wins the race on a very slow, lossy link, the session returns as a new session with the same peer and the old one is reported superseded.
Every path starts at a 1,200-octet datagram MTU and is probed only upward; paths with a smaller budget must be configured, not below 576 octets, and are not discovered by the protocol.
A conforming endpoint keeps durable storage with atomic replacement for its continuity records, written ahead of the transmissions that depend on them. An endpoint without such storage is outside the core protocol's applicability, except as a responder serving from sealed records.
No UDP port is assigned or requested by the specification; a deployment configures one.
A gateway group shares one replicated identity key across its gateways: compromise of one gateway is compromise of the group's identity, and the group is one trust boundary.
The constant-time and erasure properties are stated as requirements and were reviewed in the implementations; no timing measurement is claimed.

The Cohort Layer

The Analogy and the Claim A PQST session survives the loss of every path because the session, not the path, is the persistent object. The cohort layer applies the same idea one level up: the cohort is to its members' sessions what a session is to its paths. A member may change paths, go dormant, re-anchor, restart, or return through another gateway of the group, and the cohort exists unchanged.

The Four Invariants

CG1, decoupling. No transport-class or session-class event of a member's session (path loss, dormancy, re-anchor, restart, return through another gateway) changes the membership epoch, the member list, the policy version, or any other member's cohort state.

CG2, single authoritative history. The cohort's commits form one total order; each membership epoch has exactly one epoch key; a partition creates no history.

CG3, revocation is not restorable by resumption. No resumption, re-anchor or new session restores standing revoked while a member was away. A peer that has applied the removal erases the old epoch key and accepts no proof under it; a peer that has not applied it accepts only within its own standing, which lapses on a timer, so the residual acceptance at an uninformed peer is bounded -- at most group_suspend after its last confirmed report, up to 24 hours at the pairwise defaults.

CG4, no rollback. No authenticated object, new session, gateway or restart lowers the membership epoch or policy version a member has accepted. Staleness is permitted; return to a left epoch is not.

What This Version Specifies and What It Does Not specifies a control plane: one sequencer commits membership, policy and a membership epoch key over the members' pairwise PQST sessions with it; members report reachability, locate one another under policy, and prove possession of the current epoch key to one another inside their pairwise sessions. The epoch key protects the group's own control and proves possession of the key; it does not authenticate any member's application data, and this version gives a group no native channel: member-to-member traffic travels in ordinary pairwise PQST sessions. Admission is out of band, the policy body is application-defined, and there is no roster service. Two consequences are stated at the front of the design. A removal from the cohort closes that member's sessions with the sequencer; it does not close its pairwise sessions with other members. And the sequencer is trusted in a way the Messaging Layer Security protocol exists to avoid: it commits the group's history and delivers its keys, and a deployment that cannot accept a trusted sequencer should use MLS for the group key, with the sequencer as its delivery service. The reason to accept the trade is continuity in intermittency: members cut off from the sequencer keep their last epoch and their pairwise sessions, and a group service that dies with its server is of no use on the networks PQST is designed for.

Status and the Open Question The cohort layer is Experimental, with one implementation. CG2 is a requirement on the deployment: the sequencer's commits run against an authority (a replicated store with conditional, atomic, fenced commits) whose properties the specification states and whose mechanism it does not include; the reference implementation models one (). The group data plane that would give members one secure session among themselves is described as the direction of the next version and is not specified: its sender-key derivation and packet format are preliminary, and the question left open is whether receivers must constrain each individual sender against a malicious member, or whether a member is trusted because it holds the current group key. Until that is decided, nothing of the data plane is final ().

Reading Map

By Reader

You are...	Read	About
Deciding whether the problem is real	Sections , , and of	about 20 pages
A security reviewer	Sections , , , , and of	about 60 pages
A transport reviewer	Sections to of	about 65 pages
An implementer	Sections to of , with Appendix D of	the remainder, about 230 pages, of which the test vectors are 110
Evaluating the cohort layer	Sections to , , and of	about 25 pages

By Document Part The parts of , by section:

Sections of	What they define
2 to 5	terms, architecture, the threat model and conformance
6 to 9	algorithms, encoding, the key schedule and the anchor exchange
10 to 14	the data plane: packet format, receiver processing, nonces, replay protection and epochs
15 to 17	paths, dormancy and recovery, and authorization
18	the state machine
19 to 22	the control frames, error handling, extensibility and the security invariants
23 to 27	the security and privacy considerations, the registries, the pointer to the cohort layer and the implementation status
Appendices	the identity binding statement (A), replay-window pseudocode (B), an informative signature profile (C), the test vectors (D), the wire formats (E) and the parameters (F)

The test vectors of Appendix D of are the implementer's conformance target. Of the sections, 18 to 22 are reference machinery, best read on a second pass as the need arises.

Questions for the Community

Which applications require transport-native session continuity after the total loss of live cryptographic state, specified down to persistence and crash behaviour, and what evidence would establish that a new transport is preferable to reconstructing continuity above an existing one? If that evidence exists, in which area and working group does the work belong?
Should the work be one document family, as posted, or a small core plus separately progressing extensions? Where would reviewers prefer to separate them?
Is a post-quantum-only design with one suite per version, agility by key provisioning, acceptable; or is a classical hybrid a prerequisite for consideration?
Is the forged-handshake cost of acceptable as priced and disclosed, or is a return-routability proof ahead of the first decapsulation required?
Should zero-round-trip recovery, with the delivery semantics of , survive into a -01, move to an extension, or be removed?
Is a trusted-sequencer group layer a trade the community wants available beside MLS for groups that must outlive their infrastructure and is Experimental the right status for it while its data plane is open? Would reviewers be interested in evaluating the adjacent data plane work not included in that document?
For a tunnel whose carried traffic is not congestion-controlled, or whose rate is not set by that traffic, is a circuit-breaker expectation in the core specification sufficient, or must PQST's own control traffic be paced by a congestion controller? states the case the design is made for; the other cases are open.

Security Considerations This document specifies no protocol, defines no wire format and introduces no security considerations of its own. The security models, guarantees and limits of the protocols it overviews are those of Sections and of and . of this document is a summary of three qualifications in those documents, collected for the reader's convenience; it is not a substitute for them.

IANA Considerations This document has no IANA actions. The registries requested for the core protocol are in , and for the cohort layer in ; none is allocated at the Internet-Draft stage.