diff options
Diffstat (limited to 'docs/FOG-WIRE.md')
| -rw-r--r-- | docs/FOG-WIRE.md | 1246 |
1 files changed, 1246 insertions, 0 deletions
diff --git a/docs/FOG-WIRE.md b/docs/FOG-WIRE.md new file mode 100644 index 0000000..1f0964a --- /dev/null +++ b/docs/FOG-WIRE.md @@ -0,0 +1,1246 @@ +# FOG Wire Protocol + +Status: Draft 0.1 + +Date: 2026-08-08 + +## 1. Purpose + +This document defines `FOG-WIRE-1`, the authenticated transport protocol used +between adjacent online FOG roles. + +It refines the following baselines: + +- `FOG-THREAT-MODEL.md`, especially `TM-NET-01`, `TM-NET-03`, `TM-NET-04`, + `TM-NET-05`, `TM-NET-06`, `TM-PKI-02`, `TM-ROLE-01`, `TM-ROLE-02`, + `TM-ROLE-03`, `TM-OPS-01`, `TM-CRYPTO-01`, `TM-CRYPTO-02`, and + `TM-AVAIL-01`; +- `FOG-ARCHITECTURE.md`, especially `ARC-003`, `ARC-004`, `ARC-005`, + `ARC-006`, `ARC-007`, `ARC-008`, `ARC-009`, `IF-03`, `IF-04`, `IF-06`, + `IF-07`, `IF-08`, `IF-09`, `IF-10`, and `IF-11`; +- `FOG-PKI.md`, especially consensus-authorized profiles, endpoints, + role-specific epoch public keys, monotonic profile state, and hard expiry. + +FOG is not implemented. Requirements in this document are protocol targets, +not statements about deployed security. + +The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY describe +normative requirements in the sense of BCP 14 when they appear in uppercase. + +## 2. Scope + +`FOG-WIRE-1` owns: + +- the version-1 TCP carrier profile; +- selection of one exact consensus-authorized Noise profile; +- responder-only authentication for relay-to-entry links; +- mutual authentication for node, authority, storage, and observer links; +- binding of network, epoch, consensus, role, peer, key, and link context to + the Noise handshake; +- handshake and transport framing; +- fixed-size encrypted records and bounded logical-message fragmentation; +- command allowlists by link context and direction; +- per-record cipher-state rekey and bounded fresh handshakes; +- epoch and profile transition behavior; +- connection ownership, timeouts, backoff, overload, and failure behavior; +- key lifecycle, privacy-safe diagnostics, and conformance requirements. + +`FOG-WIRE-1` does not own: + +- message-level end-to-end encryption; +- KEMSphinx packet construction, routing, replay tags, or SURBs; +- the entry submission capsule or return rendezvous; +- storage capability semantics or replica durability; +- application acknowledgments, retries, or deduplication; +- mix delays, route selection, cover rates, or retrieval schedules; +- consensus construction or profile authorization; +- local administration, release updates, public mirror HTTP, or Composer + transfer formats. + +Noise protects one adjacent connection. It does not hide IP endpoints, TCP +connection existence, timing, direction, duration, or byte volume. It does +not replace KEMSphinx or end-to-end message encryption. + +## 3. Security Goals + +FOG-WIRE MUST provide, for one accepted connection: + +- authentication of every required online endpoint before application work; +- anonymity at the Noise identity layer for a blind relay connecting to an + entry; +- confidentiality and integrity of transport records after the handshake; +- forward secrecy to the extent supplied by the selected reviewed Noise or + PQNoise profile and correct erasure of ephemeral state; +- exact authorization of role adjacency and command direction; +- authenticated agreement on the network, epoch, consensus, profile, roles, + node identifiers, and transport-key identifiers; +- no silent suite, pattern, carrier, role, or version downgrade; +- fixed ciphertext length for records within one profile; +- bounded parsing, allocation, reassembly, cryptographic work, and queues; +- coarse non-amplifying remote failures; +- deterministic profile and epoch retirement. + +FOG-WIRE does not provide: + +- anonymity against an observer who can correlate connection timing or + volume; +- protocol camouflage or censorship resistance; +- authentication of a blind relay as a stable user or network identity; +- application-message authenticity or recipient authentication; +- KEMSphinx replay protection; +- delivery, liveness, or availability against sustained denial of service; +- safe operation after compromise of both endpoint processes; +- post-quantum security merely because one profile contains a post-quantum + primitive. + +## 4. Protocol Invariants + +### WIRE-INV-01: One authenticated profile + +Every connection uses exactly one immutable wire profile authorized by the +accepted consensus. Peers MUST NOT negotiate a list, guess a profile, or fall +back after failure. + +### WIRE-INV-02: One link context + +Every connection has exactly one link context that fixes the initiator role, +responder role, authentication mode, permitted direction, and command +allowlist. + +### WIRE-INV-03: No early application data + +Every Noise handshake payload is empty in version 1. No FOG command is sent, +accepted, buffered as trusted, or acted upon before the handshake completes +and peer authorization succeeds. Session resumption, PSK resumption, and +0-RTT application data are forbidden. + +### WIRE-INV-04: Consensus is the authority + +Operator configuration MAY restrict peers further, but MUST NOT add a peer, +role, endpoint, key, context, or profile absent from the accepted consensus or +trusted authority manifest. + +### WIRE-INV-05: Fixed encrypted records + +All post-handshake records on one connection have the exact ciphertext length +defined by its profile. Application type and semantic body length MUST NOT +change that record length. + +### WIRE-INV-06: Strict ordered state + +Version 1 runs over ordered TCP. Noise transport nonces and cipher-state +rekeys advance exactly once per successfully sent or received record. A +missing, duplicated, unauthentic, or out-of-order record terminates the +connection. + +### WIRE-INV-07: Purpose-separated keys + +Noise static keys, node identity keys, authority vote keys, KEMSphinx keys, +entry capsule keys, replica-envelope keys, message keys, queue-sealing keys, +and release keys are distinct. One key MUST NOT serve two of these purposes. + +### WIRE-INV-08: Bounded work before trust + +Preface, handshake, frame, record, fragment, connection, and queue work is +bounded before allocation proportional to attacker-controlled input. A peer +cannot request an arbitrary algorithm, record size, or reassembly budget. + +### WIRE-INV-09: Failure does not widen access + +Failure never causes plaintext transport, direct client fallback, layer +skipping, a new role edge, an older profile, a previous epoch, or a generic +RPC path. + +### WIRE-INV-10: Traffic scheduling is external but mandatory + +FOG-WIRE supplies fixed records and a padding record. The authenticated cover +profile decides when records are emitted. A local keepalive choice MUST NOT +silently replace or modify that traffic schedule. + +## 5. Terminology and Byte Order + +Terms used in this specification: + +- **wire profile**: immutable mapping from one numeric profile identifier to + an exact carrier, Noise protocol name, record geometry, limits, timers, + socket behavior, and compatible command-shape registry; +- **link context**: immutable role adjacency and directional command policy; +- **preface**: the fixed 32-byte cleartext connection header; +- **prologue**: the canonical byte string supplied to both Noise handshake + states and authenticated by the handshake transcript; +- **record**: one fixed-size plaintext structure encrypted as one Noise + transport message; +- **logical message**: one command body carried in one or more DATA records; +- **current consensus**: the accepted consensus valid for new work at the + local uncertainty interval; +- **staged consensus**: a valid future consensus that is not yet active for + new work. + +All integer fields defined directly by FOG-WIRE are unsigned and encoded in +network byte order, most significant byte first. Byte arrays have the exact +declared length. Reserved and padding bytes MUST be zero after decryption or +when transmitted in cleartext. + +TCP is a byte stream. An implementation MUST NOT assume that one write equals +one read, that one TCP segment equals one FOG frame, or that a partial read is +an error. + +## 6. Version-1 Carrier + +The only version-1 carrier is TCP as specified by RFC 9293. + +The version-1 carrier profile: + +- uses one direct TCP connection between descriptor-authorized endpoints; +- does not add TLS, DTLS, QUIC, HTTP, WebSocket, SOCKS, a service mesh, or a + proxy protocol header; +- treats IPv4 and IPv6 endpoint forms only as permitted by the active profile; +- binds the responder key through Noise rather than DNS or X.509; +- does not trust TCP source address as a cryptographic identity; +- uses no in-band carrier autodetection; +- uses no TCP urgent data; +- treats a half-close as connection termination after bounded output drain. + +A future carrier requires a new immutable wire profile and explicit profile +transition. One port MUST NOT auto-detect TCP FOG-WIRE, TLS, QUIC, or any +foreign protocol. + +FOG-WIRE has a visible fixed preface and does not claim to be +indistinguishable from unrelated network traffic. Noise ephemeral public keys +may also be fingerprintable. Deployment documentation MUST state this +residual risk. + +## 7. Wire Profile Registry + +Every `wire_profile_id` is a non-zero unsigned 32-bit integer whose meaning is +permanent. Reusing an identifier for changed bytes or behavior is forbidden. + +An exact wire profile definition contains at least: + +```text +[ + wire_profile_id, + wire_version, + carrier_id, + noise_protocol_name, + authentication_mode, + permitted_link_context_ids, + record_plaintext_size, + command_shape_registry_id, + maximum_session_records_per_direction, + maximum_session_ciphertext_bytes_per_direction, + maximum_session_age, + preface_timeout, + handshake_timeout, + fragment_timeout, + drain_timeout, + reconnect_backoff_profile_id, + socket_behavior_profile_id +] +``` + +The registry definition is part of the normative protocol release and is +identified by an immutable digest in release metadata. Consensus +`active_profile_ids` authorizes identifiers, not operator-provided profile +bodies. Implementations MUST reject an authorized identifier they do not +implement exactly. + +The profile fixes one complete Noise protocol name. Pattern, KEM or DH, +cipher, hash, hybrid combiner, key encoding, handshake message count, and +handshake message sizes are not independently negotiated. + +The initial concrete classical or hybrid post-quantum Noise names and reviewed +library remain a pre-PoC selection gate. FOG MUST use a published reviewed +construction and maintained implementation. It MUST NOT create a FOG-specific +KEM, cipher, combiner, Noise token, or handshake extension. + +## 8. Authentication Modes + +### 8.1 Entry mode + +`ENTRY-AUTH-1` has these semantics: + +- the initiator is a blind relay with no static Noise identity in the + handshake; +- the responder is an entry whose exact epoch Noise public key is known from + accepted consensus; +- the initiator authenticates the responder; +- the responder learns no stable relay identity from Noise; +- both sides use fresh handshake ephemeral state; +- all handshake payloads are empty; +- application work begins only after the complete handshake. + +A classical profile MAY realize these semantics with the Noise `NK` pattern +while mandating an empty first handshake payload. A post-quantum or hybrid +profile MUST name one reviewed equivalent construction explicitly. Support in +the abstract Noise framework is not authorization to improvise a conversion. + +The entry authenticates each later submission capsule under +`FOG-SPHINX-PROFILES`. A TCP address, client certificate, username, API token, +or reusable relay key MUST NOT become a durable FOG user identity. + +### 8.2 Mutual node mode + +`NODE-MUTUAL-1` has these semantics: + +- initiator and responder have distinct role-local static Noise keys; +- each endpoint knows the exact expected peer public key before connecting; +- each endpoint proves possession of its corresponding private key; +- both endpoints use fresh handshake ephemeral state; +- all handshake payloads are empty; +- application work begins only after complete mutual authentication. + +A classical profile MAY realize these semantics with Noise `KK`. A +post-quantum or hybrid profile MUST name a reviewed mutually authenticated +equivalent construction. The peer keys come from the same accepted consensus, +except authority wire keys, which come from root-certified authority wire-key +certificates referenced by that consensus. + +### 8.3 No optional authentication + +Version 1 has no anonymous-to-mutual upgrade, dummy identity, user password, +bearer token, client certificate, or authentication extension inside the +handshake. A link context determines one mode before parsing begins. + +## 9. Link Context Registry + +Version 1 reserves these link contexts: + +| ID | Name | Initiator | Responder | Mode | Connection use | +| --- | --- | --- | --- | --- | --- | +| 1 | `RELAY_ENTRY` | relay | entry | `ENTRY-AUTH-1` | submission and bounded return traffic | +| 2 | `ENTRY_LAYER1` | entry | layer-1 mix | `NODE-MUTUAL-1` | forward and reply KEMSphinx packets | +| 3 | `LAYER1_LAYER2` | layer-1 mix | layer-2 mix | `NODE-MUTUAL-1` | forward and reply KEMSphinx packets | +| 4 | `LAYER2_LAYER3` | layer-2 mix | layer-3 mix | `NODE-MUTUAL-1` | forward and reply KEMSphinx packets | +| 5 | `LAYER3_TERMINAL` | layer-3 mix | courier or authorized native service | `NODE-MUTUAL-1` | terminal request and anonymous reply | +| 6 | `COURIER_STORE` | courier | store | `NODE-MUTUAL-1` | bounded replica operations | +| 7 | `STORE_STORE` | lower `node_id` store | higher `node_id` store | `NODE-MUTUAL-1` | replica synchronization only | +| 8 | `NODE_AUTHORITY` | admitted node | authority | `NODE-MUTUAL-1` | descriptor submission only | +| 9 | `AUTHORITY_AUTHORITY` | lower `authority_id` | higher `authority_id` | `NODE-MUTUAL-1` | PKI protocol objects only | +| 10 | `ROLE_OBSERVER` | reporting role | observer | `NODE-MUTUAL-1` | approved aggregate reports only | + +The numeric ordering rule gives contexts 7 and 9 one canonical connector and +prevents persistent duplicate connections. Numeric comparison is over the +complete identifier bytes. + +The reply direction MAY use an already authenticated adjacency connection in +the reverse record direction. It does not authorize a new topology edge. The +packet profile determines which peer is the next authorized reply hop. + +Adding a context or changing its role pair, direction, mode, or command set +requires a new wire version or immutable profile transition. Operator +configuration cannot create a custom context. + +## 10. Peer Authorization + +Before starting a mutual handshake, each side MUST derive an expected peer +record from one accepted network view: + +```text +ExpectedPeer = ( + network_id, + epoch, + consensus_hash, + link_context_id, + local_role, + remote_role, + local_identifier, + remote_identifier, + local_wire_key_id, + remote_wire_key_id, + local_endpoint, + remote_endpoint +) +``` + +For node links, both node descriptors MUST be valid for the selected epoch, +their effective consensus roles and layers MUST match the link context, and +their Noise keys MUST have the `node Noise transport` purpose. + +For authority links, the authority identifier and dedicated wire public key +MUST validate through an `AuthorityWireKeyCertificate` signed by the matching +offline authority root. An authority vote key MUST NOT be used as a Noise +key. + +For `RELAY_ENTRY`, the relay identifier and key identifier are absent and are +encoded as all-zero values in the prologue. The entry descriptor, role, +endpoint, profile, and epoch key are still validated exactly. + +Authorization MUST be repeated before exposing a completed handshake to the +role implementation. A peer removed, suspended, revoked, reassigned, expired, +or no longer adjacent under consensus MUST NOT continue new work merely +because an old TCP connection remains open. + +## 11. Cleartext Preface + +Every connection begins with exactly one 32-byte `WirePreface`: + +```text +struct WirePreface { + byte magic[8]; // ASCII "FOGWIRE1" + uint16 wire_version; // 1 + uint32 wire_profile_id; + uint16 link_context_id; + uint64 epoch; + uint16 flags; // 0 + byte reserved[6]; // all zero +} +``` + +The preface is transmitted by the initiator and is not encrypted. The +responder MUST read all 32 bytes within the profile preface timeout and then: + +1. compare `magic` to the exact eight ASCII bytes `FOGWIRE1`; +2. require `wire_version` equal to 1; +3. require zero flags and reserved bytes; +4. require a locally implemented profile authorized for the declared epoch; +5. require the context to be permitted by that profile and listener; +6. require the declared epoch to be current or explicitly staged under + Section 23; +7. select exactly one handshake state without probing alternatives. + +The preface does not negotiate. The responder sends no selection, supported +list, retry profile, or downgrade hint. Any failure closes the TCP connection +without protocol bytes. + +## 12. Authenticated Noise Prologue + +Both peers construct the exact same byte string before initializing Noise: + +```text +WirePrologue = EncodeFixed( + "FOG-WIRE-PROLOGUE-1", + WirePreface, + network_id, + consensus_hash, + initiator_role_id, + responder_role_id, + initiator_identifier, + responder_identifier, + initiator_wire_key_id, + responder_wire_key_id +) +``` + +`EncodeFixed` is concatenation of the exact-width fields in the order shown. +The domain string is 19 ASCII bytes without a terminator. `network_id`, +`consensus_hash`, each identifier, and each key identifier use the hash output +length pinned by the trusted PKI suite. Role identifiers are unsigned 16-bit +integers. Absent relay identifier and key fields are all zero. + +No field is length-prefixed because every width is determined by the trusted +PKI suite and wire version. Implementations MUST publish byte-exact prologue +fixtures for every context. + +The complete `WirePrologue` is supplied as the Noise prologue input. It is +authenticated by the resulting handshake transcript but is not secret and is +not treated as extra key material. + +The implementation MUST retain the final Noise handshake hash as a +connection-local channel-binding value until connection teardown. It MUST NOT +log, publish, or reuse that value as a cross-session identifier. + +## 13. Handshake Framing and State Machine + +Each Noise handshake message is carried as: + +```text +struct HandshakeFrame { + uint16 noise_message_length; + byte noise_message[noise_message_length]; +} +``` + +Rules: + +- `noise_message_length` MUST be non-zero and at most 65,535; +- the profile MUST define the exact handshake message count and expected + length of every message; +- a received length different from the profile expectation terminates the + connection before proportional allocation; +- every Noise handshake payload is zero bytes; +- trailing, extra, duplicated, or out-of-order handshake frames terminate the + connection; +- the complete handshake MUST finish within the profile handshake timeout; +- a Noise parse, decapsulation, DH, AEAD, key, or authentication failure + terminates the connection; +- no application-specific error is sent during the handshake; +- ephemeral private state and incomplete cipher state are erased on success, + failure, or timeout to the extent supported by the runtime. + +The initiator state machine is: + +```text +TCP_CONNECTED + -> SEND_PREFACE + -> NOISE_HANDSHAKE + -> VERIFY_RESPONDER_OR_BOTH_PEERS + -> TRANSPORT + -> DRAIN_OR_FAIL + -> CLOSED +``` + +The responder state machine is: + +```text +TCP_ACCEPTED + -> READ_AND_VALIDATE_PREFACE + -> NOISE_HANDSHAKE + -> VERIFY_INITIATOR_IF_REQUIRED + -> TRANSPORT + -> DRAIN_OR_FAIL + -> CLOSED +``` + +There is no resumption state and no transition from a failed state back to +handshake on the same TCP connection. + +## 14. Transport Framing + +After a successful handshake, each record is carried as: + +```text +struct TransportFrame { + uint16 ciphertext_length; + byte ciphertext[ciphertext_length]; +} +``` + +For one connection, `ciphertext_length` is constant and equals: + +```text +record_plaintext_size + 16 +``` + +The 16 bytes are the Noise AEAD authentication overhead. The concrete profile +MUST use a Noise cipher function with this standard overhead. + +`record_plaintext_size` MUST be a multiple of 256 between 4,096 and 65,280 +bytes inclusive. Consequently every ciphertext fits the standard Noise +65,535-byte message limit. FOG-WIRE does not adopt a larger non-standard Noise +message limit. + +A receiver MUST validate the two-byte length against the one expected +constant before allocating or reading the ciphertext. Zero, short, overlong, +or profile-mismatched lengths terminate the connection. + +TCP split and coalescing are transparent to this framing. One implementation +MUST interoperate when every framing byte arrives in a separate TCP read and +when multiple frames arrive in one read. + +## 15. Record Plaintext + +Every decrypted record has this exact layout: + +```text +struct WireRecord { + uint8 record_version; // 1 + uint8 record_type; + uint16 flags; // 0 + byte message_id[16]; + uint16 command_id; + uint16 command_version; + uint32 fragment_index; + uint32 fragment_count; + uint32 total_length; + uint16 fragment_length; + uint16 reserved; // 0 + byte fragment_and_padding[record_plaintext_size - 40]; +} +``` + +The 40-byte header is fixed. Version 1 defines: + +| `record_type` | Name | Meaning | +| --- | --- | --- | +| 0 | `PADDING` | traffic-schedule record, discarded after validation | +| 1 | `DATA` | one fragment of one allowed logical command | +| 2 | `CLOSE` | authenticated planned close or fresh-handshake rotation | + +Unknown versions, types, flags, commands, command versions, or non-zero +reserved values are critical errors and terminate the connection. + +### 15.1 Padding record + +For `PADDING`, every field after `flags`, including all payload bytes, MUST be +zero. The receiver validates and discards it. It MUST pass through the same +Noise decrypt, length check, record rekey, accounting, and aggregate metrics +path as DATA records before semantic discard. + +### 15.2 Close record + +For `CLOSE`, `command_id` is a coarse close class: + +- 0: planned normal close; +- 1: authenticated fresh-handshake or epoch rotation. + +Every other header field after `flags`, except `command_id`, and all payload +bytes MUST be zero. +Failure, authentication, parsing, overload, or authorization errors do not +send a CLOSE reason. They close the socket without protocol bytes. + +### 15.3 Data record + +For `DATA`: + +- `message_id` MUST be a fresh non-zero 16-byte value generated from the + operating-system CSPRNG and unique within the connection; +- `command_id` and `command_version` MUST be allowed for the context, + direction, role pair, epoch, and command-shape registry; +- `fragment_count` MUST be from 1 through 4,096; +- `fragment_index` MUST be less than `fragment_count`; +- `total_length` MUST be no greater than 8 MiB and within the lower + context-specific limit; +- `fragment_length` MUST be no greater than + `record_plaintext_size - 40`; +- every non-final fragment MUST fill the complete fragment capacity; +- the final fragment length MUST equal the remaining declared body length; +- `fragment_count` MUST equal the unique count implied by total length and + fragment capacity; +- unused `fragment_and_padding` bytes MUST be zero. + +Zero-length command bodies use exactly one DATA record with zero fragment +length and are valid only when the command registry explicitly permits them. + +`message_id` is a connection-local reassembly handle, not a capability, +account, authentication token, delivery identifier, storage key, or +cross-session replay defense. A narrower command protocol owns idempotency and +deduplication across reconnects. + +## 16. Logical-Message Reassembly + +A receiver MAY interleave fragments from multiple logical messages only +within all profile bounds. It MUST: + +1. authenticate and validate each complete record before reading its fields; +2. reject duplicate fragment indices and inconsistent repeated metadata; +3. avoid allocation based only on `fragment_count` or `total_length`; +4. allocate or spool incrementally within a fixed connection budget; +5. accept at most eight incomplete logical messages per connection; +6. accept at most 16 MiB of incomplete reassembly state per connection; +7. expire incomplete messages at the profile fragment timeout; +8. erase partial bodies on timeout, connection loss, parse failure, or role + rejection; +9. invoke command handling only after exact complete reassembly and final + shape validation. + +A context profile MAY lower the 8 MiB message limit, eight-message count, or +16 MiB buffer budget. It MUST NOT raise them in wire version 1. + +Implementations SHOULD stream authenticated fragments into bounded +role-local temporary storage when a command legitimately exceeds the in-memory +budget. Temporary files MUST be private to the role account, unlinked or +randomly named without peer identifiers, size-bounded, and deleted on every +terminal path. + +## 17. Command Registry and Direction + +Version 1 reserves these command families: + +| ID | Command | Body owner | +| --- | --- | --- | +| 1 | `PACKET_SUBMIT` | future `FOG-ENTRY-CAPSULE` specification | +| 2 | `PACKET_FORWARD` | `FOG-SPHINX-PROFILES` fixed KEMSphinx packet | +| 3 | `PACKET_RETURN` | `FOG-SPHINX-PROFILES` bounded relay return object | +| 256 | `REPLICA_REQUEST` | `FOG-STORAGE` | +| 257 | `REPLICA_RESPONSE` | `FOG-STORAGE` | +| 258 | `REPLICA_SYNC` | `FOG-STORAGE` | +| 512 | `DESCRIPTOR_UPLOAD` | `FOG-PKI` | +| 513 | `DESCRIPTOR_RESULT` | `FOG-PKI` | +| 514 | `AUTHORITY_OBJECT` | `FOG-PKI` | +| 768 | `AGGREGATE_REPORT` | `FOG-OBSERVABILITY` | + +The directional allowlist is: + +| Context | Initiator to responder | Responder to initiator | +| --- | --- | --- | +| `RELAY_ENTRY` | `PACKET_SUBMIT` | `PACKET_RETURN` | +| `ENTRY_LAYER1` | `PACKET_FORWARD` | `PACKET_FORWARD` | +| `LAYER1_LAYER2` | `PACKET_FORWARD` | `PACKET_FORWARD` | +| `LAYER2_LAYER3` | `PACKET_FORWARD` | `PACKET_FORWARD` | +| `LAYER3_TERMINAL` | `PACKET_FORWARD` | `PACKET_FORWARD` | +| `COURIER_STORE` | `REPLICA_REQUEST` | `REPLICA_RESPONSE` | +| `STORE_STORE` | `REPLICA_SYNC` | `REPLICA_SYNC` | +| `NODE_AUTHORITY` | `DESCRIPTOR_UPLOAD` | `DESCRIPTOR_RESULT` | +| `AUTHORITY_AUTHORITY` | `AUTHORITY_OBJECT` | `AUTHORITY_OBJECT` | +| `ROLE_OBSERVER` | `AGGREGATE_REPORT` | none | + +`PACKET_FORWARD` in the reverse record direction is permitted only when the +packet profile validates the receiving peer as the next hop of an anonymous +reply. It does not allow arbitrary reverse RPC. + +Every narrower specification MUST define exact body bytes, version, maximum +size, expected padded size class, request-to-response relation, idempotency, +semantic timeout, and behavior after reconnect. Unknown commands never reach +role code. + +There is no vendor, experimental, operator-private, or generic-RPC command +range in version 1. + +## 18. Command Shapes and Length Privacy + +The active `command_shape_registry_id` maps each allowed command to: + +- one exact logical body length; or +- a small ordered set of public padded length classes; +- an exact record count for each class; +- a context-specific maximum in-flight count; +- whether zero-length bodies are valid. + +The sender pads the semantic object inside the owning protocol before passing +it to FOG-WIRE. FOG-WIRE zero-fills only unused space in the last fixed +record. It does not invent application padding classes. + +All native KEMSphinx applications use the same `PACKET_SUBMIT`, +`PACKET_FORWARD`, and `PACKET_RETURN` shapes for an active packet profile. +`fog-drop`, `fog-mailbox`, and `fog-im` MUST NOT select distinguishable wire +sizes. + +`FOG-SPHINX-PROFILES.md` defines the exact packet and return bodies. For the +non-active `FOG-SPHINX-CANDIDATE-MLKEM768-X25519-1`, `PACKET_FORWARD` is +16,150 bytes and `PACKET_RETURN` is 10,204 bytes. These calculated candidate +lengths do not authorize the suite. A wire profile paired with it must map each +body to one deterministic fixed record count and reject any other logical +length. + +The number and timing of records remain observable. A command shape is a +declared traffic class, not perfect length hiding. The simulator and owning +protocol MUST evaluate whether a class creates an unacceptable fingerprint. + +## 19. Cipher-State Rekey + +After encrypting and queueing each complete transport record, the sender MUST +call Noise `CipherState.Rekey()` on the outbound cipher state exactly once. +After successfully authenticating, decrypting, and validating the fixed +ciphertext length of each complete record, the receiver MUST call +`CipherState.Rekey()` on the inbound cipher state exactly once before +processing the record semantically. + +If authentication fails, the receiver does not advance or retry. It destroys +both transport cipher states and closes the connection. + +Noise rekey changes the current cipher key through a one-way function and does +not reset the Noise nonce. It does not add a fresh DH or KEM secret. Therefore +it MUST NOT be described as a replacement for a fresh authenticated +handshake. + +The separate inbound and outbound cipher states are never combined and +half-duplex Noise mode is forbidden. + +## 20. Fresh Handshake and Session Limits + +A connection MUST be replaced with a completely new TCP and Noise handshake +at the earliest of: + +- the profile maximum records sent in either direction; +- the profile maximum ciphertext bytes sent in either direction; +- the profile maximum session age; +- activation of a new required epoch key or wire profile; +- peer role, topology adjacency, endpoint, key, revocation, or authorization + change; +- any uncertainty about cipher-state synchronization; +- local secret-state restoration or process restart. + +Version-1 absolute ceilings are: + +| Item | Absolute ceiling | +| --- | --- | +| records per direction per session | 2^32 | +| ciphertext bytes per direction per session | 1 TiB | +| session age | 24 hours | + +Every concrete profile MUST select lower exact values based on cipher bounds, +cover rate, connection churn, epoch schedule, and measurements. + +The connector MAY establish one authenticated replacement in parallel. It +MUST NOT send new logical messages on the replacement until the handshake and +authorization complete. The old connection drains only already admitted +messages for the profile drain timeout, then closes. + +Logical-message retry across the replacement belongs to the command owner. A +transport reconnect MUST NOT silently report application success, replay an +unknown partial command, or create a second delivery without that command's +idempotency rule. + +## 21. Connection Ownership and Multiplicity + +There is at most one active data connection for one tuple: + +```text +( + network_id, + epoch, + wire_profile_id, + link_context_id, + initiator_identifier, + responder_identifier +) +``` + +`RELAY_ENTRY` uses one relay-local connection instance in place of an +initiator identifier. A relay MAY maintain the small temporary entry set +permitted by its authenticated cover profile, but the count MUST NOT vary +immediately with one user message. + +One additional authenticated connection MAY exist only as a staged +replacement. Any other duplicate is closed after authentication without +moving work to it. + +The canonical initiator in Section 9 owns reconnect attempts. A responder +does not open a reverse substitute connection. Nodes SHOULD maintain required +adjacency connections independently of application queue occupancy when the +cover profile requires it. + +## 22. Traffic Scheduling, Padding, and Liveness + +The active cover profile specifies connection maintenance and a record-emission +schedule for each privacy-relevant context. It may choose a measured constant, +Poisson, or other reviewed schedule, but all operators in that profile use the +same authenticated parameters. + +At each scheduled emission opportunity: + +- the role sends one queued DATA record allowed by the scheduling policy; or +- it sends one PADDING record when no eligible DATA record is selected. + +DATA arrival MUST NOT cause an undeclared immediate write that bypasses the +schedule. PADDING MUST NOT be disabled locally while a profile claims traffic +normalization. + +FOG-WIRE defines no `PING` or `PONG`. TCP itself has no sufficient application +liveness guarantee. Health is inferred from authenticated traffic, socket +failure, connection age, and separate coarse loop protocols. If a deployment +enables operating-system TCP keepalive only for dead-resource cleanup, its +exact settings MUST be profile-bound and it MUST NOT be counted as cover +traffic or anonymity evidence. + +Failure of required cover generation moves the role into the degraded or stop +state defined by the cover profile. It does not switch to activity-triggered +records. + +The first matrix in `FOG-SIMULATION.md` does not select this schedule. It shows +that high packet cover can improve simple timing and intersection proxies +without supplying adequate local mixing at short mean delay. Exact record +schedules still require queue, liveness, loop, polling, reply, and load models. + +## 23. Epoch and Profile Transitions + +The preface declares one epoch. The Noise prologue binds the exact consensus +hash for that epoch. Peers MUST NOT combine a descriptor, key, topology edge, +profile, or parameter from a different consensus body. + +During an authenticated transition: + +- a listener MAY accept the current epoch and one preannounced next epoch; +- a next-epoch connection MAY complete and remain staged before `valid_after`; +- no next-epoch application work is sent or accepted before `valid_after`; +- an old profile remains usable only through its signed overlap interval; +- minimum accepted profile state prevents rollback after promotion; +- a previous epoch connection stops accepting new work at its exact boundary; +- bounded draining MUST end before key or consensus hard expiry; +- expired private keys are erased after the owning protocol's last required + grace window; +- same-epoch consensus conflict freezes new connections and new work. + +A listener chooses the exact state directly from the preface and local +accepted PKI state. It does not try current and old parsers in sequence. + +At consensus `valid_until`, new handshakes and new logical messages under that +consensus stop. Existing connections MAY only perform an explicitly specified +bounded drain that does not outlive key authorization. + +## 24. Timeouts and Reconnect Backoff + +Every concrete wire profile defines exact values for: + +- TCP connect timeout; +- 32-byte preface timeout; +- complete Noise handshake timeout; +- fixed frame read and write timeout; +- incomplete logical-message fragment timeout; +- output drain timeout; +- maximum session age; +- reconnect initial delay, multiplier, ceiling, and jitter distribution. + +Version-1 absolute maxima are: + +| Timer | Maximum | +| --- | --- | +| preface | 30 seconds | +| complete handshake | 60 seconds | +| incomplete frame | 60 seconds | +| incomplete logical message | 5 minutes | +| drain | 30 seconds | +| reconnect ceiling | 15 minutes | + +Timeouts are monotonic-duration measurements, not peer-provided wall-clock +values. A timeout closes the connection without detailed remote error. + +Reconnect uses bounded exponential backoff with CSPRNG-derived full jitter. +The attempt schedule MUST NOT use node identifiers, message identifiers, +queue length, or application type as its random seed. Immediate deterministic +fallback to another route, layer, or older profile is forbidden. + +## 25. Backpressure and Resource Limits + +Before the local PoC, every role profile MUST set lower operational limits +within these version-1 absolute bounds: + +| Resource | Absolute bound | +| --- | --- | +| accepted unauthenticated connections per listener | 1,024 | +| concurrent handshakes per listener | 256 | +| active connections per authenticated peer/context | 1 plus 1 staged | +| encrypted record plaintext | 65,280 bytes | +| logical message | 8 MiB | +| fragments per logical message | 4,096 | +| incomplete messages per connection | 8 | +| incomplete reassembly bytes per connection | 16 MiB | +| queued complete logical messages per connection | 1,024 | +| command versions accepted per command | 2 during signed transition | + +Implementations MUST also bound total process connections, file descriptors, +handshake CPU, KEM decapsulations, per-source unauthenticated attempts, queue +bytes, write backlog, temporary files, and aggregate reassembly memory. + +When a queue is full, the role follows the owning command's shedding policy. +It MUST NOT allocate without bound, skip authentication, enlarge a packet, +send an error larger than the triggering record, or route around a required +layer. + +Entry-mode abuse control MAY use coarse short-lived network-source limits and +valid entry capsules, but MUST NOT create a stable cross-entry user account. +Safe anonymous admission and rate control remain an explicit open security +decision. + +## 26. Socket Behavior + +The immutable socket behavior profile fixes at least: + +- TCP no-delay behavior; +- keepalive enablement and exact cleanup timers if used; +- send and receive buffer ceilings; +- user-space write batching; +- address-family policy; +- dual-stack binding behavior; +- connection and accept backlog limits; +- maximum pending output bytes; +- graceful close and reset behavior. + +Operators MUST NOT tune these settings independently when they affect record +timing, batching, connection duration, or public traffic claims. The initial +values require trace measurement on supported operating systems because TCP +segmentation does not preserve FOG record boundaries. + +Proxy-protocol headers, transparent proxy source metadata, TLS termination, +and service-mesh sidecars are forbidden on core FOG-WIRE listeners. A +deployment requiring a network proxy is a separate analyzed profile and trust +boundary. + +## 27. Failure Behavior + +| Condition | Remote behavior | Local behavior | +| --- | --- | --- | +| invalid or unsupported preface | close without bytes | coarse counter | +| unauthorized epoch, profile, context, role, or endpoint | close without bytes | coarse authorization class | +| handshake length or timeout failure | close without bytes | coarse handshake class | +| Noise authentication or decapsulation failure | close without bytes | one aggregate crypto-failure class | +| transport length mismatch | close without bytes | coarse frame class | +| Noise record authentication failure | close without bytes | destroy both cipher states | +| unknown or malformed record | close without bytes | coarse record class | +| forbidden command or direction | close without bytes | coarse policy class | +| reassembly bound or timeout | close without bytes | erase partial state | +| queue saturation after authentication | owning protocol's uniform bounded outcome or close | aggregate overload class | +| planned rotation | one fixed CLOSE record if schedule permits | bounded drain and fresh handshake | +| TCP loss or half-close | no protocol error | erase partial state and back off | + +Peers never receive parser offsets, expected keys, supported profiles, +consensus hashes, role policy, capacity, queue depth, or cryptographic error +details. + +The implementation is not required to make all local computation paths +constant-time with respect to public invalid framing. Cryptographic libraries +MUST provide their required side-channel protections, and remotely observable +failure behavior MUST remain non-amplifying and free of detailed oracles. + +## 28. Logging and Metrics + +FOG-WIRE MUST NOT log or export: + +- plaintext or ciphertext record bodies; +- entry capsules or KEMSphinx packets; +- `message_id`, Noise handshake hash, traffic key, ephemeral key, or private + key material; +- per-record timestamps or direction traces; +- queue contents, logical-message hashes, capabilities, or reply material; +- source IP addresses for anonymous relay-to-entry sessions in persistent + application logs; +- detailed handshake failure stages associated with one remote endpoint. + +Role-local debugging MAY use coarse enumerated failure classes in a protected +short-retention log, without input bytes or secret values. Claim-bearing +profiles disable packet and record tracing. + +Metrics are delayed aggregates over declared windows and minimum populations. +Allowed examples include total completed handshakes by context, aggregate +failure class, coarse connection age bucket, aggregate queue occupancy bucket, +and total padding-to-data ratio. The observer interface receives aggregates, +not event streams. + +## 29. Key and Secret Lifecycle + +| Key or secret | Generator | Authorized use | Lifetime and overlap | Compromise response | Backup | +| --- | --- | --- | --- | --- | --- | +| Node Noise epoch private key | owning node OS CSPRNG | one node role and authorized adjacent links | profile-bounded current key, staged next key, exact grace only | revoke key or node, stop new handshakes, rotate | no routine backup | +| Entry Noise epoch private key | entry OS CSPRNG | authenticate `RELAY_ENTRY` and authorized node links | profile-bounded current and staged next | revoke entry key, stop sessions, rotate | no routine backup | +| Authority wire private key | authority wire service OS CSPRNG or controlled ceremony | authority mutual links only | root-certified bounded interval, staged next key | root-signed revocation and replacement | SHOULD NOT restore into a concurrent service | +| Handshake ephemeral private state | connection endpoint OS CSPRNG | one Noise handshake | until handshake completion or failure | close connection, erase state | none | +| Noise transport cipher states | Noise handshake `Split()` | one direction of one connection | until close or fresh handshake | destroy connection state and reauthenticate | none | +| Reassembly message identifier | sending role OS CSPRNG | one logical message within one connection | until completion or timeout | discard partial message | none | +| Queue-sealing key | owning role local secret facility | local queued ciphertext at rest | deployment-rotated, independent of Noise | quarantine queue, rotate, discard unverifiable state | profile-specific encrypted backup | + +Static private keys MUST be readable only by the one role service that owns +them. They MUST NOT appear in environment templates, command arguments, +container images, shared volumes, logs, crash dumps, examples, test fixtures, +or support bundles. + +Best-effort zeroization is required for ephemeral, cipher-state, and partial +plaintext buffers. Documentation MUST NOT claim complete erasure where the +language runtime, allocator, kernel, swap, hibernation, or hardware cannot +guarantee it. + +## 30. Implementation Requirements + +An implementation MUST: + +- use a maintained reviewed Noise or PQNoise library; +- use the operating-system CSPRNG for static keys, ephemeral state, message + identifiers, and jitter; +- keep protocol framing separate from role command parsing; +- enforce all limits before proportional allocation; +- use checked integer arithmetic for lengths, counts, and record totals; +- reject trailing bytes and unknown-critical values; +- authenticate complete records before semantic parsing; +- prevent one role package from importing another role implementation; +- expose one typed context-specific command interface, not raw generic RPC; +- disable core dumps and secret-bearing panic or exception output; +- hold static private keys in the minimum role-local protected facility; +- destroy connection state on every authentication or synchronization error; +- keep the Composer implementation free of FOG-WIRE listeners and sockets. + +The protocol implementation MUST NOT: + +- implement cryptographic primitives or hybrid combiners locally; +- let configuration specify an arbitrary Noise protocol string; +- use a shared transport key for multiple nodes or roles; +- retry decryption with old keys or profiles; +- accept a DNS result, TCP source, or TLS certificate instead of PKI key + validation; +- expose a generic byte tunnel to applications; +- compress records or logical messages at the wire layer; +- silently fragment an over-limit command; +- persist session cipher state for resumption. + +### 30.1 Required module boundaries + +The future implementation keeps these responsibilities independently +testable: + +```text +role executable and role package + -> TCP listener or connector adapter + -> FOG-WIRE session state machine + -> profile and link-context authorization + -> pure preface, prologue, frame, record, and fragment codecs + -> reviewed Noise or PQNoise library +``` + +The pure codecs MUST be testable without opening a socket or starting a role. +The session state machine owns no role database and invokes only a typed +context-specific command boundary after complete validation. The TCP adapter +owns socket IO but does not parse role command bodies. Role handlers own +semantic commands but never access Noise cipher state or unvalidated record +bytes. + +Profile registry, framing, session, and command-shape code MUST NOT be placed +in a generic `utils` package. Role packages MUST NOT call each other to bypass +the wire contract or share one transport singleton. Separate executables are +justified by the established security and state-isolation boundaries, not by +independent feature scaling. + +## 31. Conformance and Adversarial Tests + +Before the local PoC, FOG-WIRE MUST have tests for: + +- byte-exact preface encoding and every rejected field variation; +- byte-exact prologue construction for every context and PKI hash length; +- entry responder authentication with no relay static identity; +- mutual node and authority authentication; +- wrong network, consensus, epoch, context, role, node, endpoint, key, and + profile binding; +- empty handshake payload enforcement and attempted early application data; +- handshake messages at expected, short, long, zero, and 65,535-byte bounds; +- TCP reads split at every byte boundary and coalesced across multiple frames; +- fixed ciphertext length and standard Noise maximum enforcement; +- every record type and zero-reserved or zero-padding rule; +- unknown record, command, command version, close class, and direction; +- valid single- and multi-fragment reassembly; +- duplicate, missing, reordered, inconsistent, expired, excessive, and sparse + fragments; +- exact 8 MiB, 4,096-fragment, 8-message, and 16 MiB boundaries; +- per-record outbound and inbound rekey synchronization; +- authentication failure before and after a rekey boundary; +- fresh-handshake record, byte, age, epoch, topology, and profile boundaries; +- current and next epoch staging with no early forwarding; +- old-profile retirement and rollback refusal; +- duplicate connection collision and one staged replacement; +- queue saturation, slow reads, slow writes, half-close, reset, and timeout; +- reconnect backoff and jitter bounds under repeated failure; +- listener floods and expensive-handshake concurrency limits; +- log and metrics schema rejection of prohibited fields; +- parser mutation, coverage-guided fuzzing, differential framing tests, race + tests, and allocation tests; +- firewall validation for every link context and forbidden role edge. + +Tests generate ephemeral private fixtures at runtime. Private keys MUST NOT be +committed as example or conformance data. Public canonical framing fixtures +MAY be committed when they contain no secret material. + +Independent implementations MUST consume the same public framing and +transcript-binding corpus before interoperability is claimed. + +## 32. Claim Gates + +### 32.1 Functional PoC + +The local PoC MUST demonstrate: + +- one fixed reviewed Noise profile; +- responder-only relay-to-entry and mutual node authentication; +- complete traversal of entry and three mix layers; +- fixed records, padding records, fragmentation, and strict command policy; +- per-record rekey and bounded fresh handshakes; +- current and next epoch transition; +- malformed, unauthorized, flooded, and disconnected peers; +- no multi-role key, state, account, or writable-volume sharing. + +This demonstrates functional correctness only. It does not demonstrate a +production anonymity set or global-observer resistance. + +`FOG-LOCAL-POC.md` fixes the container and network boundary for this gate. It +uses one internal pairwise network per permitted data-plane adjacency, no host +ports, and no shared role state. Its current validated plan is not a FOG-WIRE +implementation and deliberately contains no invented wire profile or port. + +### 32.2 Operator alpha + +Alpha additionally requires: + +- fixed reviewed hybrid post-quantum or explicitly documented classical + profile selection; +- interoperability between independently built endpoints; +- fuzz, race, load, fault, and side-channel review results; +- measured TCP record segmentation and timing on supported systems; +- measured handshake cost and anonymous-entry flood behavior; +- six independently operated mixes and profile-conformant cover scheduling; +- rehearsed key compromise, revocation, epoch transition, and rollback tests; +- public residual-risk documentation for visible endpoints and traffic. + +### 32.3 Production transport claims + +Production claims additionally require: + +- independent protocol and implementation review; +- reviewed library and dependency provenance; +- published concrete suite, geometry, limits, and conformance results; +- verified erasure and crash behavior within stated platform limits; +- sustained adversarial load and resource-exhaustion testing; +- evidence that profile rollout does not create persistent minority + fingerprints; +- claim wording that distinguishes link confidentiality, forward secrecy, + post-quantum assumptions, and metadata privacy. + +## 33. Requirements Traceability + +| Requirement | FOG-WIRE control | +| --- | --- | +| `TM-NET-01` | fixed records, command shapes, profile-bound scheduling, padding records | +| `TM-NET-03` | bounded retries, no bypass, cover-profile failure gate | +| `TM-NET-04` | ordered Noise nonces, no resumption, command-owned cross-session deduplication | +| `TM-NET-05` | authenticated records, strict failure, no action before validation | +| `TM-NET-06` | immutable profiles, exact context, no negotiation or autodetection | +| `TM-PKI-02` | epoch and consensus binding, monotonic profile transition, hard expiry | +| `TM-ROLE-01` | anonymous relay mode, authenticated entry, no durable relay account | +| `TM-ROLE-02` | exact layer adjacency, mutual node authentication, no layer skip | +| `TM-ROLE-03` | courier/store contexts, command separation, fixed replica shapes | +| `TM-OPS-01` | prohibited log fields, delayed aggregate metrics | +| `TM-CRYPTO-01` | purpose-separated keys, lifecycle table, fresh handshakes | +| `TM-CRYPTO-02` | consensus-authorized exact Noise name, no fallback, bounded overlap | +| `TM-AVAIL-01` | strict frame, fragment, handshake, connection, queue, and CPU bounds | +| `ARC-003` | no data-plane bypass or new failure edge | +| `ARC-004` | Noise limited to adjacent transport protection | +| `ARC-005` | peers and profiles derived from one complete accepted consensus | +| `ARC-006` | fixed records and application-independent packet commands | +| `ARC-007` | one private-key owner and one purpose | +| `ARC-008` | exact versioned framing and absolute parser limits | +| `ARC-009` | coarse non-amplifying remote failure | +| `IF-03` | authenticated bounded descriptor command | +| `IF-04` | authenticated authority object command | +| `IF-06` | anonymous relay initiator, authenticated entry, fixed submission command | +| `IF-07` | mutually authenticated exact layer adjacency | +| `IF-08` | fixed authenticated layer-3 to terminal transport | +| `IF-09` | dedicated courier/store and store/store contexts | +| `IF-10` | reverse-direction packet only over authorized adjacency | +| `IF-11` | aggregate-only observer command | + +## 34. Open Pre-Implementation Selections + +The version-1 protocol structure is fixed, but these selections block daemon +implementation: + +- the exact reviewed classical or hybrid post-quantum Noise protocol names; +- the reviewed Noise or PQNoise library and supported implementation language; +- X-Wing is the leading KEM to evaluate, but no exact FOG entry or mutual + post-quantum handshake profile is selected; +- exact `wire_profile_id` assignments and immutable registry digests; +- record plaintext size and command-shape pairings; +- fresh-handshake record, byte, and age thresholds; +- concrete timeouts, reconnect distribution, and socket behavior profile; +- lower role-specific connection, queue, CPU, and memory limits; +- packet, PKI, and observer command body specifications, plus byte-exact + `FOG-STORAGE` command-to-record mappings; +- cover-record schedules and degraded-mode thresholds from simulation; +- safe anonymous entry admission and flood-control policy; +- authority wire-key certificate rollout and revocation ceremony. + +Implementations MUST NOT resolve these selections through undocumented local +defaults. Each selected value becomes an immutable reviewed profile with test +vectors and a signed transition path. + +## 35. References + +- FOG threat model: `FOG-THREAT-MODEL.md` +- FOG architecture: `FOG-ARCHITECTURE.md` +- FOG public key infrastructure: `FOG-PKI.md` +- FOG storage protocol: `FOG-STORAGE.md` +- FOG cryptographic suite evaluation: `FOG-CRYPTO-SUITES.md` +- FOG traffic and topology simulation: `FOG-SIMULATION.md` +- FOG local Podman PoC: `FOG-LOCAL-POC.md` +- Noise Protocol Framework: + <https://noiseprotocol.org/noise.html> +- Katzenpost mix network wire protocol: + <https://katzenpost.network/docs/specs/wireprotocol/> +- Post Quantum Noise: + <https://eprint.iacr.org/2022/539> +- CFRG X-Wing KEM Internet-Draft: + <https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/> +- RFC 9293, Transmission Control Protocol: + <https://www.rfc-editor.org/rfc/rfc9293.html> +- RFC 8174, Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words: + <https://www.rfc-editor.org/rfc/rfc8174.html> + +These references inform Noise handshake semantics, standard message bounds, +rekey behavior, TCP stream framing, post-quantum construction review, and +adjacent mix-link experience. They do not make a concrete FOG profile secure +without exact selection, conformance testing, operational measurement, and +independent review. |