Internet Engineering Task Force S. Rama Hebbar Internet-Draft Independent Intended status: Standards Track 5 August 2026 Expires: 6 February 2027 Zero Trust Secure Layer (ZTSL) Protocol Specification with Opcode Framework and Application Binding Layer draft-ztsl-secdispatch-protocol-00 Abstract This document specifies the Zero Trust Secure Layer (ZTSL) protocol, a transport-layer security framework that enforces Zero Trust principles at the protocol level by embedding continuous identity verification, device trust validation, policy-driven communication, and cryptographic session management into every protocol message. ZTSL introduces the First Authentication Needed (FAN) mechanism, Zessions (Zero Trust Sessions), the Device Trust Flag (DTF), the Client Security Routing Profile (CSRP), the Triple Signature Model, the Trust Triangle, Adaptive Protocol Negotiation, and Heartbeat Fingerprint (HBF) synchronization. This document also specifies the ZTSL Opcode Framework, a structured, extensible opcode namespace that encodes every protocol operation as a precisely identified, versioned, and trust-contextualized instruction. Every FAN exchange, Zession state transition, socket operation, signing step, routing decision, heartbeat synchronization, threat event, and recovery action is assigned a unique opcode and transmitted as an opcode-bearing ZTSL frame. The document further specifies the Application Binding Layer (ABL), the transparent shim through which any application interacts with ZTSL via a familiar socket-like API, completely insulated from the underlying trust machinery. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Rama Hebbar Expires 6 February 2027 [Page 1] Internet-Draft ZTSL Protocol August 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 2.1. Protocol Terms . . . . . . . . . . . . . . . . . . . . . 6 2.2. Opcode Framework Terms . . . . . . . . . . . . . . . . . 7 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 4. End-to-End Communication Flow . . . . . . . . . . . . . . . . 9 4.1. Phase 1 -- Policy Definition . . . . . . . . . . . . . . 9 4.2. Phase 2 -- Server Initialization . . . . . . . . . . . . 9 4.3. Phase 3 -- Managed Client Generation . . . . . . . . . . 9 4.4. Phase 4 -- Client Installation and Device Registration . 10 4.5. Phase 5 -- First Authentication Needed (FAN) . . . . . . 10 4.6. Phase 6 -- Adaptive Protocol Negotiation . . . . . . . . 11 4.7. Phase 7 -- Zession Creation . . . . . . . . . . . . . . . 11 4.8. Phase 8 -- Secure Socket Creation . . . . . . . . . . . . 12 4.9. Phase 9 -- Trust Triangle Establishment . . . . . . . . . 12 4.10. Phase 10 -- Message Preparation and Metadata . . . . . . 12 4.11. Phase 11 -- Triple Signature Generation . . . . . . . . . 12 4.12. Phase 12 -- ZTSL Packet Construction . . . . . . . . . . 13 4.13. Phase 13 -- Server-Side Packet Validation . . . . . . . . 14 4.14. Phase 14 -- Trust-Aware Routing . . . . . . . . . . . . . 14 4.15. Phase 15 -- Receiver-Side Validation . . . . . . . . . . 14 4.16. Phase 16 -- Heartbeat Synchronization . . . . . . . . . . 14 4.17. Phase 17 -- Continuous Trust Evaluation . . . . . . . . . 15 4.18. Phase 18 -- Threat Detection . . . . . . . . . . . . . . 15 4.19. Phase 19 -- Adaptive Recovery . . . . . . . . . . . . . . 15 Rama Hebbar Expires 6 February 2027 [Page 2] Internet-Draft ZTSL Protocol August 2026 4.20. Phase 20 -- Secure Session Termination . . . . . . . . . 16 5. FAN Architecture . . . . . . . . . . . . . . . . . . . . . . 16 6. Zession Specification . . . . . . . . . . . . . . . . . . . . 17 7. ZTSL Opcode Framework . . . . . . . . . . . . . . . . . . . . 17 7.1. Opcode Namespace Structure . . . . . . . . . . . . . . . 17 7.2. Opcode Encoding . . . . . . . . . . . . . . . . . . . . . 17 7.3. Class 0x00 -- Control Plane (CP) . . . . . . . . . . . . 18 7.4. Class 0x01 -- FAN Operations . . . . . . . . . . . . . . 18 7.5. Class 0x02 -- Zession Management . . . . . . . . . . . . 18 7.6. Class 0x03 -- Socket Operations . . . . . . . . . . . . . 18 7.7. Class 0x04 -- Data Plane (DP) . . . . . . . . . . . . . . 19 7.8. Class 0x05 -- Trust Operations . . . . . . . . . . . . . 19 7.9. Class 0x06 -- Recovery Operations . . . . . . . . . . . . 19 7.10. Class 0x07 -- Audit and Telemetry . . . . . . . . . . . . 20 8. ZTSL Opcode State Machine . . . . . . . . . . . . . . . . . . 20 8.1. State: PRE_FAN . . . . . . . . . . . . . . . . . . . . . 20 8.2. State: FAN_NEGOTIATION . . . . . . . . . . . . . . . . . 20 8.3. State: ZESSION_ACTIVE . . . . . . . . . . . . . . . . . . 20 8.4. State: TRUST_DEGRADED . . . . . . . . . . . . . . . . . . 20 8.5. State: RECOVERY . . . . . . . . . . . . . . . . . . . . . 21 8.6. State: TERMINATION . . . . . . . . . . . . . . . . . . . 21 9. Protocol Phase Opcode Encoding Reference . . . . . . . . . . 21 9.1. FAN Exchange . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Data-Plane Message Flow . . . . . . . . . . . . . . . . . 21 9.3. Heartbeat Synchronization . . . . . . . . . . . . . . . . 22 9.4. Threat Detection and Recovery . . . . . . . . . . . . . . 23 10. Application Binding Layer (ABL) . . . . . . . . . . . . . . . 23 10.1. ABL Socket API . . . . . . . . . . . . . . . . . . . . . 23 10.2. ABL Dispatch Table . . . . . . . . . . . . . . . . . . . 24 11. ZTSL Packet Structure . . . . . . . . . . . . . . . . . . . . 24 12. Trust Mesh Architecture . . . . . . . . . . . . . . . . . . . 25 13. Wire Format Examples . . . . . . . . . . . . . . . . . . . . 25 13.1. FAN_REQ_INITIAL First Bytes . . . . . . . . . . . . . . 25 13.2. DP_DATA_NORMAL First Bytes . . . . . . . . . . . . . . . 26 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26 14.1. Opcode Binding as a Novel Security Primitive . . . . . . 26 14.2. Cryptographic Agility . . . . . . . . . . . . . . . . . 26 14.3. Replay Attack Prevention . . . . . . . . . . . . . . . . 27 14.4. Denial of Service Mitigation . . . . . . . . . . . . . . 27 14.5. Side-Channel Resistance . . . . . . . . . . . . . . . . 27 14.6. Key Management and Perfect Forward Secrecy . . . . . . . 27 14.7. Post-Quantum Readiness . . . . . . . . . . . . . . . . . 27 14.8. Audit and Non-Repudiation . . . . . . . . . . . . . . . 27 14.9. Trust Score Manipulation . . . . . . . . . . . . . . . . 28 14.10. Insider Threat . . . . . . . . . . . . . . . . . . . . . 28 14.11. Physical Security . . . . . . . . . . . . . . . . . . . 28 14.12. Opcode Namespace Exhaustion . . . . . . . . . . . . . . 28 14.13. State Machine Enforcement . . . . . . . . . . . . . . . 28 Rama Hebbar Expires 6 February 2027 [Page 3] Internet-Draft ZTSL Protocol August 2026 14.14. ABL Buffer Security . . . . . . . . . . . . . . . . . . 28 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 15.1. ZTSL Primary Opcode Class Registry . . . . . . . . . . . 29 15.2. ZTSL Operation Code Sub-Registries . . . . . . . . . . . 29 15.3. ZTSL Frame Flags Registry . . . . . . . . . . . . . . . 29 15.4. ZTSL Adaptive Protocol Identifier Registry . . . . . . . 29 15.5. Well-Known Port Number . . . . . . . . . . . . . . . . . 29 15.6. ALPN Identifier . . . . . . . . . . . . . . . . . . . . 29 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 16.1. Normative References . . . . . . . . . . . . . . . . . . 29 16.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A: Key Term Summary . . . . . . . . . . . . . . . . . . 31 Appendix B: High-Level Communication Flow Summary . . . . . . . . 32 Appendix C: Complete Opcode Reference Table (84 opcodes) . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction Modern network security has historically relied on perimeter-based models in which a device or user, once authenticated at the boundary, is granted implicit trust within the interior network. This approach has proven fundamentally inadequate in the face of insider threats, compromised endpoints, lateral movement attacks, and increasingly distributed application architectures. The Zero Trust security model [NIST.SP.800-207] mandates that trust is never implicitly granted and MUST be continuously verified for every access request, every device, every session, and every network interaction. While numerous higher-layer protocols have begun adopting Zero Trust principles, the transport layer has remained largely unchanged, relying on connection-oriented trust established once at session initiation and maintained statically thereafter. The Zero Trust Secure Layer (ZTSL) protocol addresses this gap by introducing a transport-layer framework that enforces Zero Trust principles at the protocol level. ZTSL provides: * A mandatory multi-dimensional trust establishment phase (FAN) that MUST complete before any data transport begins. * Continuously verified sessions (Zessions) carrying an auditable, cryptographically linked hash chain reflecting evolving trust state. * Per-packet device validation via the Device Trust Flag (DTF). * A Triple Signature Model binding every message to its originating socket, device, and plaintext content hash. Rama Hebbar Expires 6 February 2027 [Page 4] Internet-Draft ZTSL Protocol August 2026 * A Trust Triangle Model ensuring sender, server, and receiver maintain synchronized trust contexts at all times. * Adaptive Protocol Negotiation allowing the transport substrate to be selected dynamically based on trust score, network conditions, and administrator policy. * Heartbeat Fingerprint (HBF) messages that propagate trust state rather than merely signaling liveness. * Adaptive Recovery mechanisms allowing the protocol to survive partial compromise without requiring application restart. * A formal Opcode Framework assigning a hierarchical, three-tier opcode identifier to every protocol operation, enabling deterministic parsing, state machine enforcement, conformance testing, and clean extension. * An Application Binding Layer (ABL) that maps application-level socket calls to ZTSL opcode sequences transparently, requiring zero application code modification. ZTSL operates above the transport layer (TCP, QUIC, SCTP, DCCP) and below the application layer, serving as a secure transport abstraction analogous in position - but far richer in trust semantics - to TLS. The novel technical contributions of this specification are: 1. A formally specified, hierarchical 24-bit opcode namespace for a Zero Trust transport protocol, enabling machine-parseable operation encoding with 16,777,216 addressable opcodes. 2. Opcode Binding: the inclusion of each frame's 24-bit opcode in the Triple Signature computation, preventing opcode forgery, cross-opcode replay, and protocol confusion attacks. 3. An opcode-annotated Zession hash chain, embedding a tamper- evident causal audit trail directly in the cryptographic session state. 4. An Application Binding Layer specification with a formal Dispatch Table mapping every standard socket call to an explicit, ordered ZTSL opcode sequence. Rama Hebbar Expires 6 February 2027 [Page 5] Internet-Draft ZTSL Protocol August 2026 2. Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 2.1. Protocol Terms ZTSL Zero Trust Secure Layer - the transport-layer protocol defined in this document. Zession A Zero Trust Session: a continuously verified trust context with a cryptographically linked hash chain reflecting evolving trust state. Every Zession transition is signed and auditable. FAN First Authentication Needed - the mandatory multi-dimensional trust establishment phase that MUST complete before a Zession is created and data transport begins. DTF Device Trust Flag - a cryptographic token derived from trusted device measurements (TPM attestation, Secure Enclave, certificate fingerprint) carried in every ZTSL packet for per-packet device validation. CSRP Client Security Routing Profile - a structured, signed, versioned profile generated by the ZTSL Server encoding identity, policies, routing, protocol preferences, and trust thresholds. Trust Score A numeric value computed by the Trust Engine representing the current aggregate trust level of a device, session, or channel. Socket Fingerprint A cryptographic identifier uniquely bound to a ZTSL socket and its trust policies and permitted capabilities. Connection Fingerprint A cryptographic identifier representing a specific client-to-client communication context established through the Trust Triangle. Adaptive Protocol Fingerprint A cryptographic identifier tied to the negotiated transport protocol and its governing policies. HBF Heartbeat Fingerprint - a cryptographic structure in Heartbeat frames synchronizing trust state between all parties in the Trust Triangle. Rama Hebbar Expires 6 February 2027 [Page 6] Internet-Draft ZTSL Protocol August 2026 Trust Triangle The three-way trust relationship among sender, ZTSL Server, and receiver, in which the server continuously validates and mediates trust. Trust Mesh The centralized architecture in which the ZTSL Server maintains and arbitrates all inter-client trust relationships. Triple Signature The combination of Socket Signature, Device Signature, and Message Signature applied to every ZTSL data message, each with Opcode Binding. Adaptive Recovery The protocol mechanism by which compromised cryptographic material, DTFs, Zessions, and CSRPs are regenerated without requiring application restart. URG Flag An urgency flag (FrameFlags bit 7) set by the Trust Engine to signal an immediate trust event; recipient MUST suspend data forwarding. 2.2. Opcode Framework Terms Opcode A 24-bit hierarchical identifier (Class.Op.Sub) assigned to every ZTSL protocol operation. ZTSL Frame The fundamental encoding unit of the ZTSL protocol - a TLV structure prefixed with a 24-bit opcode. Primary Class The high-order 8 bits of the opcode identifying the broad category of operation. Operation Code (Op) The middle 8 bits identifying the specific operation within a Primary Class. Sub-Code The low-order 8 bits identifying a variant or sub-operation within an operation. ABL Application Binding Layer - the transparent shim between application socket calls and ZTSL opcode sequences. Opcode State Machine The finite-state automaton governing which opcodes are legal in each ZTSL protocol state. Opcode Binding The inclusion of the 24-bit opcode in the Triple Signature computation, preventing opcode forgery or replay. Dispatch Table The ABL mapping from application socket call to ZTSL opcode sequence. Rama Hebbar Expires 6 February 2027 [Page 7] Internet-Draft ZTSL Protocol August 2026 3. Architectural Overview The ZTSL architecture is organized around a central ZTSL Server that functions as the trust authority for all client communications. No direct client-to-client communication occurs without server mediation. All communication follows the Trust Triangle model. +----------------------------------------------------+ | ZTSL Server | | | | +------------------+ +---------------------+ | | | Policy Engine | | Identity Manager | | | +------------------+ +---------------------+ | | +------------------+ +---------------------+ | | | Trust Engine | | Zession Manager | | | +------------------+ +---------------------+ | | +------------------+ +---------------------+ | | | Routing Engine | | Recovery Engine | | | +------------------+ +---------------------+ | | +------------------+ +---------------------+ | | | FAN Engine | | Adaptive Protocol | | | +------------------+ | Engine | | | +------------------+ +---------------------+ | | | Heartbeat Engine | | Audit Engine | | | +------------------+ +---------------------+ | +----------------------------------------------------+ ^ ^ | Trust Triangle | +-------+--------+ +---------+------+ | Client A | | Client B | | (ZTSL Agent) | | (ZTSL Agent) | +----------------+ +----------------+ Figure 1: ZTSL Architecture The client communication model is strictly server-mediated: Client A --> ZTSL Server --> Client B The ZTSL Server comprises twelve internal engine components, all of which MUST be operational before client communication is permitted. The ZTSL Agent runs on each client endpoint as a transparent system service, implementing the ABL that intercepts standard socket calls and translates them into ZTSL opcode sequences without any application code modification. Rama Hebbar Expires 6 February 2027 [Page 8] Internet-Draft ZTSL Protocol August 2026 4. End-to-End Communication Flow The ZTSL communication lifecycle consists of twenty sequential phases. Each phase MUST complete successfully before the next begins. Failure in any phase MUST result in termination of the current attempt and, depending on the phase, MUST trigger Adaptive Recovery or audit logging. 4.1. Phase 1 -- Policy Definition All ZTSL communication originates from administrator-defined policies. Policies constitute the root of trust for the entire ZTSL environment and MUST be defined before any server is initialized. Policies MUST specify, at minimum, the following domains: Device Trust, User Identity, Application Trust, Network Trust, Communication Methods, Encryption, Routing, Adaptive Protocol, Heartbeat, Trust Thresholds, Recovery, and Audit. Policies MUST be versioned. Any policy update MUST increment the Policy Version and MUST be propagated to all active Zessions and CSRP profiles. 4.2. Phase 2 -- Server Initialization The administrator initializes the ZTSL Server. The server MUST load and activate the following components in this order: (1) Policy Engine, (2) Identity Manager, (3) Certificate Manager, (4) Client Generator, (5) FAN Engine, (6) Trust Engine, (7) Routing Engine, (8) Adaptive Protocol Engine, (9) Heartbeat Engine, (10) Zession Manager, (11) Recovery Engine, (12) Audit Engine. Upon successful initialization, the server becomes the central trust authority. No client communication MAY occur before initialization is complete. 4.3. Phase 3 -- Managed Client Generation The ZTSL Server generates every client artifact, ensuring all clients operate within administrator-defined trust boundaries from installation. For each endpoint, the server MUST generate and securely distribute: Client Certificate, Client Private Key, Identity Manager ID, Device Trust Flag (DTF), Socket Profiles, Communication Policies, Adaptive Protocol Configuration, Routing Policies, Trust Thresholds, Heartbeat Configuration, Initial Zession Template, and CSRP. Rama Hebbar Expires 6 February 2027 [Page 9] Internet-Draft ZTSL Protocol August 2026 Generated artifacts MUST be distributed over a secure out-of-band channel employing mutual authentication and end-to-end encryption independent of ZTSL. 4.4. Phase 4 -- Client Installation and Device Registration Upon receiving generated artifacts, the client software is installed on the endpoint. During installation, the client collects trusted device measurements: Device Certificate Fingerprint (SHA-256), Platform Attestation (TPM 2.0 or Secure Enclave), OS Information, Application Fingerprint, Hardware Characteristics, Network Characteristics, and Identity Manager ID. The server MUST validate the registration before acknowledging it. An endpoint failing to provide valid measurements MUST NOT be permitted to proceed to the FAN phase. 4.5. Phase 5 -- First Authentication Needed (FAN) A registered client MUST NOT initiate any ZTSL Zession without first completing a successful FAN exchange. FAN establishes the initial multi-dimensional trust context. The FAN Request (Opcode: 0x01.0x01.0x01 FAN_REQ_INITIAL) MUST contain: identity_manager_id (128 bits), device_trust_flag (DTF Structure), certificate_fingerprint (SHA-256, 256 bits), application_fingerprint (SHA-256, 256 bits), device_measurements (Attestation Report), network_measurements (Network Evidence), policy_version (32 bits), nonce (256 bits random), timestamp (64-bit Unix nanoseconds), and client_signature (Ed25519 or ECDSA P-384). The server MUST validate through six stages in order: (1) Device Trust Validation, (2) Application Trust Validation, (3) Identity Trust Validation, (4) Certificate Trust Validation, (5) Policy Trust Validation, (6) Network Trust Validation. Failure at any stage MUST cause rejection with the appropriate FAN_REJECT_* opcode. Security requirements: * FAN requests MUST be signed by the client's private key. * The server MUST verify the nonce has not been seen before within the validity window. * FAN requests with timestamp outside 60-second window MUST be rejected with 0x01.0x05.0x08 (FAN_REJECT_SKEW). Rama Hebbar Expires 6 February 2027 [Page 10] Internet-Draft ZTSL Protocol August 2026 * Failed FAN requests MUST be logged by the Audit Engine with full diagnostic context. * Configurable exponential backoff and account lockout SHOULD be enforced after repeated FAN failures. 4.6. Phase 6 -- Adaptive Protocol Negotiation Following a successful FAN, the Adaptive Protocol Engine selects the optimal transport substrate for the Zession based on: Network Latency, Packet Loss Rate, Security Policy, Trust Score, Communication Type, and Device Capability. Permitted transport substrates: (1) QUIC [RFC9000] - preferred for low-latency, high-security; (2) TCP [RFC793] - preferred for compatibility; (3) SCTP [RFC4960] - for multi-homing; (4) DCCP [RFC4340] - datagram with congestion control; (5) HTTP/HTTPS Tunnel - last-resort fallback. 4.7. Phase 7 -- Zession Creation A Zession is fundamentally distinct from a conventional session. Where a conventional session represents connection state, a Zession represents a continuously verified trust context with an auditable cryptographic history. A Zession contains: zession_id (128-bit UUID), previous_hash (SHA- 256, 256 bits), current_hash (SHA-256, 256 bits), trust_score (32 bits), device_trust_flag (DTF), socket_fingerprint (SHA-256), adaptive_protocol_fp (SHA-256), connection_fingerprint (SHA-256), heartbeat_fingerprint (HBF), policy_version (32 bits), cryptographic_state (opaque), creation_timestamp (64 bits), last_updated (64 bits). Both the server and the client MUST maintain identical, synchronized copies of the Zession. Any discrepancy MUST be treated as a trust anomaly and MUST trigger Threat Detection (Section 4.18). The Zession Hash Chain Extension Rule: at each state transition, the hash chain MUST be extended as follows: new_hash = SHA-256(prev_hash || event_opcode_24bit || trust_score || timestamp || dtf) The event_opcode_24bit is the 24-bit opcode of the frame that triggered the transition, embedding a tamper-evident, opcode- annotated audit trail in the cryptographic session state. Rama Hebbar Expires 6 February 2027 [Page 11] Internet-Draft ZTSL Protocol August 2026 4.8. Phase 8 -- Secure Socket Creation When an application requests communication, it MUST request a ZTSL Socket rather than a conventional transport socket. Each ZTSL Socket carries: socket_id (UUID, 128 bits), socket_fingerprint, allowed_protocols, allowed_data_size, allowed_message_types, and allowed_policies. A socket MUST NOT carry traffic outside its authorized parameters. Any attempt MUST trigger 0x05.0x03.0x06 (TR_THREAT_POLICY_VIOL). 4.9. Phase 9 -- Trust Triangle Establishment Before any application-level communication may proceed between Client A and Client B, the server MUST establish the Trust Triangle, binding: Sender <-> Server (server validates A's Zession, DTF, Socket Fingerprint), Server <-> Receiver (server validates B's Zession, DTF, Socket Fingerprint), and Sender <-> Receiver (server maintains Connection Fingerprint binding A and B). Trust Triangle establishment is initiated by 0x03.0x03.0x00 (SK_CONNECT) and confirmed by 0x03.0x03.0x01 (SK_CONNECT_ACK) carrying the assigned Connection Fingerprint. 4.10. Phase 10 -- Message Preparation and Metadata Before a message payload is transmitted, the sending client MUST prepare message metadata including: message_id (UUID, 128 bits), sender_id (128 bits), receiver_id (128 bits), timestamp (64-bit Unix nanoseconds), priority (8 bits: 1=CRITICAL, 2=HIGH, 3=NORMAL, 4=LOW, 5=BACKGROUND), message_type (8 bits), routing_class (8 bits), policy_id (64 bits), content_length (32 bits). Payload encryption MUST occur after the Triple Signature is computed. 4.11. Phase 11 -- Triple Signature Generation Every ZTSL data message MUST carry three independent cryptographic signatures. The 24-bit opcode is included in every signature's signed input - this constitutes Opcode Binding (Section 14.1). The correct signing order MUST be followed: 1. H = SHA-256(plaintext payload) 2. SockSig = Sign(sk_socket, opcode || SockFP || metadata) Rama Hebbar Expires 6 February 2027 [Page 12] Internet-Draft ZTSL Protocol August 2026 3. DevSig = Sign(sk_device, opcode || DTF || Cert || MsgID || timestamp) 4. MsgSig = Sign(sk_client, opcode || SockSig || DevSig || metadata || H) 5. EncPayload = AEAD(plaintext, session_key) 6. Assemble ZTSL frame with EncPayload and all three signatures. Both server and receiver MUST independently verify all three signatures. Failure to verify any MUST result in packet rejection and a TR_THREAT_* opcode being raised. 4.12. Phase 12 -- ZTSL Packet Construction Every ZTSL packet carries its full trust context, ensuring each packet is independently verifiable. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode[Cl] | Opcode[Op] | Opcode[Sub] | FrameFlags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Length (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zession ID (128 bits) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (64 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Trust Context Hash (256 bits) | | SHA-256( ZessionStateHash XOR DTF ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Signature (variable) | | Covers: Opcode || Flags || Length || ZessionID || | | SeqNum || TrustContextHash || Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Payload (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: ZTSL Frame Wire Format Rama Hebbar Expires 6 February 2027 [Page 13] Internet-Draft ZTSL Protocol August 2026 Frame Flags Bitmask (8 bits): Bit 7 (URG) - urgent trust event, suspend forwarding; Bit 6 (ACK) - acknowledges previous frame; Bit 5 (EXT) - extension fields present; Bit 4 (ENC) - payload encrypted (AEAD); Bit 3 (SIG) - Frame Signature present, MUST always be 1; Bit 2 (FIN) - final frame in multi-frame sequence; Bit 1 (FRG) - fragment of larger message; Bit 0 (RES) - reserved, MUST be zero. Every frame MUST have bit 3 (SIG) set. Frames with SIG=0 MUST be rejected. 4.13. Phase 13 -- Server-Side Packet Validation Upon receiving a ZTSL packet, the server MUST validate it through ten ordered steps: (1) Packet Integrity, (2) Replay Protection (anti- replay window MUST cover at least 64 sequence numbers), (3) Timestamp Validation (60-second window), (4) Socket Signature Verification with Opcode Binding, (5) Device Trust Flag Validation, (6) Message Signature Verification, (7) Policy Validation, (8) Trust Score Evaluation, (9) Zession Hash Validation, (10) Routing Validation. Failure at any step MUST cause immediate packet rejection, Audit Engine notification, and Trust Engine notification. 4.14. Phase 14 -- Trust-Aware Routing The Routing Engine performs trust-aware forwarding. A packet MUST NOT be forwarded if the receiver's Zession is invalid, DTF has failed, or Trust Score is below minimum. Such packets MUST be quarantined and Trust Engine notified with 0x04.0x06.0x01 (DP_ROUTE_REJECT). 4.15. Phase 15 -- Receiver-Side Validation The receiving client independently validates every packet through eight ordered steps: (1) Connection Fingerprint Validation, (2) Socket Fingerprint Validation, (3) Device Trust Validation, (4) Triple Signature Verification with Opcode Binding confirmation, (5) Policy Verification, (6) Replay Protection, (7) Payload Decryption (AES-256-GCM or ChaCha20-Poly1305), (8) Deliver to Application via ABL recv(). 4.16. Phase 16 -- Heartbeat Synchronization ZTSL Heartbeat frames (0x05.0x01.0x00, TR_HEARTBEAT) are exchanged at the configured interval. Unlike TCP keep-alive, Heartbeat frames carry an HBF synchronizing trust state between all Trust Triangle parties. Rama Hebbar Expires 6 February 2027 [Page 14] Internet-Draft ZTSL Protocol August 2026 The Zession hash chain is extended at each heartbeat: new_hash = SHA-256(prev_hash || 0x05.0x01.0x00 || trust_score || timestamp || dtf) If a client misses a Heartbeat within the tolerance window, the server MUST: (1) Emit 0x05.0x01.0x02 (TR_HEARTBEAT_MISS) and decrement Trust Score; (2) Emit 0x05.0x02.0x01 (TR_SCORE_BELOW_MIN) if threshold crossed; (3) Emit 0x02.0x05.0x02 (ZS_CLOSE_FORCED) if max misses reached. 4.17. Phase 17 -- Continuous Trust Evaluation Throughout the lifetime of a Zession, the Trust Engine continuously evaluates trust state across seven dimensions: Device State, Application Integrity, Policy Updates, Trust Score Trend, Network State, Heartbeat Consistency, and Zession Hash Chain. 4.18. Phase 18 -- Threat Detection The Trust Engine monitors for threat indicators including: application binary modification (CRITICAL, TR_THREAT_APP_MOD), device measurement mismatch (CRITICAL, TR_THREAT_DTF_FAIL), Zession hash chain broken (CRITICAL, TR_THREAT_HASH_BREAK), replay attack (CRITICAL, TR_THREAT_REPLAY), fingerprint mismatch (HIGH, TR_THREAT_FP_MISMATCH), policy violation (HIGH, TR_THREAT_POLICY_VIOL), critical trust score (HIGH, TR_SCORE_CRITICAL), clock skew (MEDIUM, TR_THREAT_SKEW), and heartbeat gap (MEDIUM, TR_HEARTBEAT_MISS). Upon detecting a threat, the Trust Engine MUST: (1) Mark the Zession as COMPROMISED; (2) Emit TR_URG with URG flag set; (3) Emit TR_URG_SUSPEND, ceasing forwarding; (4) Notify Audit Engine with AU_EVENT_SECURITY; (5) Initiate Adaptive Recovery if recoverable, otherwise emit ZS_CLOSE_FORCED. The protocol MUST NOT silently continue communication when trust context has been lost. 4.19. Phase 19 -- Adaptive Recovery When the Trust Engine determines that trust context can be re- established, the Recovery Engine initiates Adaptive Recovery in six steps: 1. New Cryptographic Keys: REC_KEY_EXCHANGE (X25519 or ECDH P-384), REC_KEY_CONFIRM. Rama Hebbar Expires 6 February 2027 [Page 15] Internet-Draft ZTSL Protocol August 2026 2. Fresh Device Attestation: REC_DTF_REQUEST, REC_DTF_RESPONSE, REC_DTF_ACCEPT (or REC_DTF_REJECT leading to REC_FAILED). 3. New Fingerprints: REC_FP_UPDATE. 4. New Zession: REC_ZESSION_NEW (genesis links Recovery ID), REC_ZESSION_SYNC. 5. Updated CSRP: REC_CSRP_UPDATE, REC_CSRP_ACK. 6. Audit and Resume: AU_RECOVERY_LOG, REC_RESUME, TR_URG_RESUME. Adaptive Recovery MUST be transparent to the application. The ABL MUST buffer application send() calls during Recovery and MUST replay them after REC_RESUME. If recovery fails after the maximum configured attempts, the server MUST emit REC_FAILED followed by REC_TERMINATE_ZESSION, and a new FAN exchange MUST be required. 4.20. Phase 20 -- Secure Session Termination Termination opcode sequence: (1) ZS_CLOSE - initiator requests close; (2) ZS_CLOSE_ACK - mutual signed ACK; (3) AU_ZESSION_CLOSE - final audit committed (Final Trust Score, Final Zession Hash, Session Metrics, Security Events); (4) SK_CLOSE; (5) SK_CLOSE_ACK; (6) All session keys, IVs, and DTF-derived material MUST be securely erased. Hardware-protected keys MUST be revoked. (7) Zession marked CLOSED. (8) Transport connection terminated. A new FAN exchange MUST be completed before a new Zession can be created. 5. FAN Architecture FAN is the mandatory multi-dimensional trust establishment gateway. No Zession MAY be created without a successful FAN exchange. The six validation dimensions are: Device Trust, Application Trust, Identity Trust, Certificate Trust, Policy Trust, and Network Trust. Each dimension MUST pass for FAN_ACCEPT to be issued. FAN rejection opcodes range from 0x01.0x05.0x01 (FAN_REJECT_DTF) through 0x01.0x05.0x08 (FAN_REJECT_SKEW), covering all specific rejection reasons. The specific opcode MUST be returned to permit the client to diagnose the failure without exposing unnecessary server state. Rama Hebbar Expires 6 February 2027 [Page 16] Internet-Draft ZTSL Protocol August 2026 6. Zession Specification A Zession is a continuously verified trust context superseding the conventional concept of a network session. Its five key distinguishing properties are: 1. Hash Chain Integrity: Every Zession state transition produces a new hash linked to its predecessor using the triggering opcode. Breaks MUST trigger TR_THREAT_HASH_BREAK. 2. Per-Heartbeat Synchronization: Zession state is synchronized at every Heartbeat interval, not merely at session initiation. 3. Trust Score Integration: The Zession carries the current Trust Score, reflecting real-time trust evaluation. 4. Adaptive Recovery Continuity: When Adaptive Recovery occurs, the new Zession genesis block MUST reference the Recovery ID, maintaining full auditability. 5. Secure Termination Record: Upon Zession closure, all terminal state is committed to the Audit Engine before cryptographic material is retired. 7. ZTSL Opcode Framework 7.1. Opcode Namespace Structure The 24-bit opcode is structured as three 8-bit fields: Bits 23-16 (Primary Class), Bits 15-8 (Operation Code), Bits 7-0 (Sub-Code). This provides a namespace capacity of 2^24 = 16,777,216 distinct opcodes. Opcode notation: CLASS.OP.SUB in hexadecimal. For example, 0x01.0x05.0x07 = Class FAN, Op REJECT, Sub REPLAY. 7.2. Opcode Encoding 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Class | Operation Code | Sub-Code | | (8 bits) | (8 bits) | (8 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Opcode Encoding (3-byte, big-endian) Rama Hebbar Expires 6 February 2027 [Page 17] Internet-Draft ZTSL Protocol August 2026 The opcode MUST be the first three bytes of every ZTSL Frame. Implementations MUST reject frames whose opcode is not in the IANA ZTSL Opcode Registry. 7.3. Class 0x00 -- Control Plane (CP) Control Plane opcodes include: CP_VERSION_HELLO (0x00.0x00.0x00), CP_VERSION_ACCEPT (0x00.0x00.0x01), CP_VERSION_REJECT (0x00.0x00.0x02), CP_ERROR (0x00.0x01.0x00), CP_ERROR_FATAL (0x00.0x01.0x01), CP_ERROR_WARN (0x00.0x01.0x02), CP_POLICY_UPDATE (0x00.0x02.0x00), CP_POLICY_ACK (0x00.0x02.0x01), CP_KEEPALIVE (0x00.0x03.0x00). 7.4. Class 0x01 -- FAN Operations FAN opcodes include: FAN_REQ_INITIAL (0x01.0x01.0x01), FAN_REQ_REAUTH (0x01.0x01.0x02), FAN_REQ_RECOVERY (0x01.0x01.0x03), FAN_CHALLENGE (0x01.0x02.0x00), FAN_CHALLENGE_DTF (0x01.0x02.0x01), FAN_CHALLENGE_NONCE (0x01.0x02.0x02), FAN_RESPONSE (0x01.0x03.0x00), FAN_ACCEPT (0x01.0x04.0x00), FAN_ACCEPT_DEGRADED (0x01.0x04.0x01), FAN_REJECT_DTF (0x01.0x05.0x01) through FAN_REJECT_SKEW (0x01.0x05.0x08), FAN_BACKOFF (0x01.0x06.0x00). 7.5. Class 0x02 -- Zession Management Zession Management opcodes include: ZS_CREATE (0x02.0x01.0x00), ZS_CREATE_ACK (0x02.0x01.0x01), ZS_UPDATE (0x02.0x02.0x00), ZS_UPDATE_TRUST (0x02.0x02.0x01), ZS_UPDATE_POLICY (0x02.0x02.0x02), ZS_UPDATE_PROTOCOL (0x02.0x02.0x03), ZS_SYNC (0x02.0x03.0x00), ZS_SYNC_ACK (0x02.0x03.0x01), ZS_SYNC_MISMATCH (0x02.0x03.0x02), ZS_DEGRADE (0x02.0x04.0x00), ZS_DEGRADE_RECOVER (0x02.0x04.0x01), ZS_CLOSE (0x02.0x05.0x00), ZS_CLOSE_ACK (0x02.0x05.0x01), ZS_CLOSE_FORCED (0x02.0x05.0x02). 7.6. Class 0x03 -- Socket Operations Socket opcodes include: SK_CREATE (0x03.0x01.0x00), SK_CREATE_ACK (0x03.0x01.0x01), SK_CREATE_REJECT (0x03.0x01.0x02), SK_BIND (0x03.0x02.0x00), SK_BIND_ACK (0x03.0x02.0x01), SK_CONNECT (0x03.0x03.0x00), SK_CONNECT_ACK (0x03.0x03.0x01), SK_CONNECT_REJECT (0x03.0x03.0x02), SK_CLOSE (0x03.0x04.0x00), SK_CLOSE_ACK (0x03.0x04.0x01), SK_PROFILE (0x03.0x05.0x00), SK_PROFILE_UPDATE (0x03.0x05.0x01). Rama Hebbar Expires 6 February 2027 [Page 18] Internet-Draft ZTSL Protocol August 2026 7.7. Class 0x04 -- Data Plane (DP) Data Plane opcodes include: DP_DATA_CRITICAL (0x04.0x01.0x01), DP_DATA_HIGH (0x04.0x01.0x02), DP_DATA_NORMAL (0x04.0x01.0x03), DP_DATA_LOW (0x04.0x01.0x04), DP_DATA_BACKGROUND (0x04.0x01.0x05), DP_DATA_ACK (0x04.0x02.0x00), DP_DATA_NACK (0x04.0x02.0x01), DP_META_ONLY (0x04.0x03.0x00), DP_FRAGMENT (0x04.0x04.0x00), DP_FRAGMENT_LAST (0x04.0x04.0x01), DP_SIGN_SOCKET (0x04.0x05.0x00), DP_SIGN_DEVICE (0x04.0x05.0x01), DP_SIGN_MESSAGE (0x04.0x05.0x02), DP_ROUTE_ANNOUNCE (0x04.0x06.0x00), DP_ROUTE_REJECT (0x04.0x06.0x01). All three signatures in DP_DATA_* frames include the 24-bit opcode in their signed input - this is Opcode Binding (Section 14.1). Substituting any opcode value in a captured frame immediately invalidates the frame signature. 7.8. Class 0x05 -- Trust Operations Trust opcodes include: TR_HEARTBEAT (0x05.0x01.0x00), TR_HEARTBEAT_ACK (0x05.0x01.0x01), TR_HEARTBEAT_MISS (0x05.0x01.0x02), TR_SCORE_UPDATE (0x05.0x02.0x00), TR_SCORE_BELOW_MIN (0x05.0x02.0x01), TR_SCORE_CRITICAL (0x05.0x02.0x02), TR_THREAT_DETECT (0x05.0x03.0x00), TR_THREAT_DTF_FAIL (0x05.0x03.0x01), TR_THREAT_APP_MOD (0x05.0x03.0x02), TR_THREAT_HASH_BREAK (0x05.0x03.0x03), TR_THREAT_REPLAY (0x05.0x03.0x04), TR_THREAT_FP_MISMATCH (0x05.0x03.0x05), TR_THREAT_POLICY_VIOL (0x05.0x03.0x06), TR_THREAT_SKEW (0x05.0x03.0x07), TR_URG (0x05.0x04.0x00), TR_URG_SUSPEND (0x05.0x04.0x01), TR_URG_RESUME (0x05.0x04.0x02). 7.9. Class 0x06 -- Recovery Operations Recovery opcodes include: REC_INITIATE (0x06.0x01.0x00), REC_INITIATE_CLIENT (0x06.0x01.0x01), REC_KEY_EXCHANGE (0x06.0x02.0x00), REC_KEY_CONFIRM (0x06.0x02.0x01), REC_DTF_REQUEST (0x06.0x03.0x00), REC_DTF_RESPONSE (0x06.0x03.0x01), REC_DTF_ACCEPT (0x06.0x03.0x02), REC_DTF_REJECT (0x06.0x03.0x03), REC_FP_UPDATE (0x06.0x04.0x00), REC_ZESSION_NEW (0x06.0x05.0x00), REC_ZESSION_SYNC (0x06.0x05.0x01), REC_CSRP_UPDATE (0x06.0x06.0x00), REC_CSRP_ACK (0x06.0x06.0x01), REC_RESUME (0x06.0x07.0x00), REC_FAILED (0x06.0x07.0x01), REC_TERMINATE_ZESSION (0x06.0x08.0x00). The REC_INITIATE frame MUST include the Recovery Trigger Opcode field - the exact TR_THREAT_* opcode that caused the recovery - as a signed field. Clients MUST verify this field matches the most recently received TR_THREAT_* opcode. A mismatch MUST be treated as CP_ERROR_FATAL. Rama Hebbar Expires 6 February 2027 [Page 19] Internet-Draft ZTSL Protocol August 2026 7.10. Class 0x07 -- Audit and Telemetry Audit opcodes include: AU_EVENT (0x07.0x01.0x00), AU_EVENT_SECURITY (0x07.0x01.0x01), AU_EVENT_TRUST (0x07.0x01.0x02), AU_EVENT_POLICY (0x07.0x01.0x03), AU_ZESSION_OPEN (0x07.0x02.0x00), AU_ZESSION_CLOSE (0x07.0x02.0x01), AU_METRICS (0x07.0x03.0x00), AU_NONREPUDIATION (0x07.0x04.0x00), AU_RECOVERY_LOG (0x07.0x05.0x00). 8. ZTSL Opcode State Machine The ZTSL Opcode State Machine defines six states. Any opcode received in a state where it is not listed MUST be treated as a CP_ERROR_FATAL event, and the Zession MUST be terminated. 8.1. State: PRE_FAN Legal opcodes: CP_VERSION_HELLO, CP_VERSION_ACCEPT, CP_VERSION_REJECT, CP_ERROR, CP_ERROR_FATAL, FAN_REQ_INITIAL, FAN_CHALLENGE_* (0x01.0x02.*), FAN_RESPONSE, FAN_REJECT_* (0x01.0x05.*), FAN_BACKOFF. All other opcodes result in CP_ERROR_FATAL. 8.2. State: FAN_NEGOTIATION Legal opcodes: All PRE_FAN opcodes, plus FAN_ACCEPT, FAN_ACCEPT_DEGRADED, FAN_REQ_REAUTH. Transitions to ZESSION_ACTIVE on FAN_ACCEPT or FAN_ACCEPT_DEGRADED; returns to PRE_FAN on FAN_REJECT_* or FAN_BACKOFF. 8.3. State: ZESSION_ACTIVE Legal opcodes: All Control Plane (except CP_VERSION_HELLO), ZS_UPDATE_*, ZS_SYNC_*, ZS_DEGRADE (-> TRUST_DEGRADED), ZS_CLOSE, all Socket Operations (0x03.*.*), all Data Plane (0x04.*.*), TR_HEARTBEAT_*, TR_SCORE_*, TR_THREAT_* (-> TRUST_DEGRADED or RECOVERY), TR_URG, all Audit (0x07.*.*). Recovery opcodes (0x06.*.*) and FAN opcodes (except FAN_REQ_REAUTH) are illegal and MUST result in CP_ERROR_FATAL. 8.4. State: TRUST_DEGRADED Legal opcodes: Control Plane, ZS_UPDATE_*, ZS_SYNC_*, ZS_DEGRADE_RECOVER (-> RECOVERY), ZS_CLOSE_*, TR_HEARTBEAT_*, TR_SCORE_*, TR_THREAT_*, TR_URG_*, Audit. Data Plane opcodes (0x04.*.*) SHOULD be suspended; ABL MUST buffer application sends. Rama Hebbar Expires 6 February 2027 [Page 20] Internet-Draft ZTSL Protocol August 2026 8.5. State: RECOVERY Legal opcodes: CP_ERROR_*, TR_URG_SUSPEND, all Recovery (0x06.*.*), all Audit (0x07.*.*), FAN_REQ_RECOVERY (if policy requires re-FAN), ZS_CREATE, ZS_CREATE_ACK. Data Plane opcodes MUST be rejected with CP_ERROR_FATAL. Transitions to ZESSION_ACTIVE on REC_RESUME; to TERMINATION on REC_FAILED or REC_TERMINATE_ZESSION. 8.6. State: TERMINATION Legal opcodes: ZS_CLOSE_*, CP_ERROR_*, SK_CLOSE, SK_CLOSE_ACK, all Audit. All other opcodes are silently discarded. Connection MUST be torn down after SK_CLOSE_ACK. 9. Protocol Phase Opcode Encoding Reference 9.1. FAN Exchange Client Server | | |--- 0x00.0x00.0x00 CP_VERSION_HELLO ----> | |<-- 0x00.0x00.0x01 CP_VERSION_ACCEPT ---- | | | |--- 0x01.0x01.0x01 FAN_REQ_INITIAL -----> | | [IM_ID, CertFP, AppFP, DTF, | | Attestation, NetFP, PolicyVer, | | Nonce, Timestamp, ClientSig] | | | | [Server evaluates 6 FAN dimensions] | | | |<-- 0x01.0x04.0x00 FAN_ACCEPT ----------- | | [ZessionID, TrustScore:95, | | GenesisHash, Transport:QUIC, | | APFingerprint, PolicyVer, | | HBInterval:5000ms, ServerSig] | | | |--- 0x02.0x01.0x01 ZS_CREATE_ACK -------> | State: PRE_FAN -> ZESSION_ACTIVE Figure 4: FAN Exchange Opcode Sequence 9.2. Data-Plane Message Flow Rama Hebbar Expires 6 February 2027 [Page 21] Internet-Draft ZTSL Protocol August 2026 APPLICATION: mySocket.send("Hello Bob") [1] 0x03.0x01.0x00 SK_CREATE [2] 0x03.0x01.0x01 SK_CREATE_ACK SocketID + SockFP [3] 0x03.0x03.0x00 SK_CONNECT Trust Triangle A->B [4] 0x03.0x03.0x01 SK_CONNECT_ACK ConnFP assigned [5] Opcode Binding -- Triple Signature: SockSig = Sign(sk_socket, 0x04.0x01.0x03 || SocketFP || MsgMeta) DevSig = Sign(sk_device, 0x04.0x01.0x03 || DTF || DevCert || MsgID || Ts) H = SHA-256("Hello Bob") MsgSig = Sign(sk_client, 0x04.0x01.0x03 || SockSig || DevSig || MsgMeta || H) Enc = AES-256-GCM("Hello Bob", session_key) [6] 0x04.0x01.0x03 DP_DATA_NORMAL (-> Server) [SERVER: 10-step validation -- all pass] [7] 0x04.0x01.0x03 DP_DATA_NORMAL (-> Bob) [RECEIVER: 8-step validation, decrypt -> "Hello Bob"] [8] 0x04.0x02.0x00 DP_DATA_ACK APPLICATION: data = mySocket.recv() -> "Hello Bob" Figure 5: Data-Plane Opcode Sequence with Opcode Binding 9.3. Heartbeat Synchronization Client Server | | |--- 0x05.0x01.0x00 TR_HEARTBEAT -------> | | [ZessionID, CurrHash, PrevHash, | | TrustScore, DTF, SockFP, ConnFP, | | APFP, HBF_Counter++, SessionState, | | PolicyVer, Timestamp, HBFSig] | | | |<-- 0x05.0x01.0x01 TR_HEARTBEAT_ACK ----- | | [ZessionID, UpdatedHash, ServerSig] | | | [Both extend Zession hash chain: new_hash = SHA-256(prev || 0x05.0x01.0x00 || score || ts || dtf)] Figure 6: Heartbeat Opcode Sequence Rama Hebbar Expires 6 February 2027 [Page 22] Internet-Draft ZTSL Protocol August 2026 9.4. Threat Detection and Recovery 0x05.0x03.0x02 TR_THREAT_APP_MOD 0x05.0x04.0x00 TR_URG (URG flag = 1) 0x05.0x04.0x01 TR_URG_SUSPEND (forwarding SUSPENDED) 0x07.0x01.0x01 AU_EVENT_SECURITY 0x06.0x01.0x00 REC_INITIATE (TriggerOpcode=0x05.0x03.0x02) 0x06.0x02.0x00 REC_KEY_EXCHANGE 0x06.0x02.0x01 REC_KEY_CONFIRM 0x06.0x03.0x00 REC_DTF_REQUEST 0x06.0x03.0x01 REC_DTF_RESPONSE 0x06.0x03.0x02 REC_DTF_ACCEPT 0x06.0x04.0x00 REC_FP_UPDATE 0x06.0x05.0x00 REC_ZESSION_NEW 0x06.0x05.0x01 REC_ZESSION_SYNC 0x06.0x06.0x00 REC_CSRP_UPDATE 0x06.0x06.0x01 REC_CSRP_ACK 0x07.0x05.0x00 AU_RECOVERY_LOG 0x06.0x07.0x00 REC_RESUME 0x05.0x04.0x02 TR_URG_RESUME State: RECOVERY -> ZESSION_ACTIVE Application: unaware; buffered sends replayed Figure 7: Recovery Opcode Sequence 10. Application Binding Layer (ABL) The ABL is the transparent integration point between application- level socket operations and the ZTSL Opcode Framework. 10.1. ABL Socket API Rama Hebbar Expires 6 February 2027 [Page 23] Internet-Draft ZTSL Protocol August 2026 /* Socket Creation */ ztsl_socket_t ztsl_socket(int domain, int type, int protocol); /* Connection */ int ztsl_connect(ztsl_socket_t sock, const ztsl_addr_t *addr, socklen_t addrlen); /* Data Transfer */ ssize_t ztsl_send(ztsl_socket_t sock, const void *buf, size_t len, int flags); ssize_t ztsl_recv(ztsl_socket_t sock, void *buf, size_t len, int flags); /* Closing */ int ztsl_close(ztsl_socket_t sock); /* Trust Query (optional) */ int ztsl_trust_score(ztsl_socket_t sock, uint32_t *score_out); int ztsl_zession_state(ztsl_socket_t sock, ztsl_zession_state_t *state_out); Applications MUST NOT configure TLS or encryption parameters directly. The ABL handles all security, key management, and trust machinery. 10.2. ABL Dispatch Table The ABL Dispatch Table maps application API calls to ZTSL opcode sequences: ztsl_socket() emits CP_VERSION_HELLO, CP_VERSION_ACCEPT, SK_CREATE, SK_CREATE_ACK; ztsl_connect() emits FAN_REQ_INITIAL through ZS_CREATE_ACK through SK_CONNECT_ACK; ztsl_send() emits Triple Signature computation followed by DP_DATA_*; ztsl_recv() validates incoming frame and emits DP_DATA_ACK; ztsl_close() emits ZS_CLOSE through SK_CLOSE_ACK. Internal heartbeat, threat, and recovery sequences are invisible to the application. 11. ZTSL Packet Structure The ZTSL packet carries: Opcode (24 bits), FrameFlags (8 bits), Frame Length (32 bits, big-endian), Zession ID (128 bits, UUID RFC 4122), Sequence Number (64 bits, big- endian, monotonic, wraps at 2^64-1), Trust Context Hash (256 bits, SHA-256(ZessionStateHash XOR DTF)), Frame Signature (variable, Ed25519 64 bytes or ECDSA P-384 96 bytes), and Frame Payload (variable, opcode-specific). For DP frames additionally: Message ID (128-bit UUID), Sender ID (128-bit UUID), Receiver ID (128-bit UUID), Message Timestamp (64-bit Unix nanoseconds), Priority (8-bit enum), Message Type (8-bit enum), Rama Hebbar Expires 6 February 2027 [Page 24] Internet-Draft ZTSL Protocol August 2026 Routing Class (8-bit enum), Policy ID (64 bits), Content Length (32 bits), Socket Fingerprint (SHA-256), Connection Fingerprint (SHA- 256), Adaptive Protocol Fingerprint (SHA-256), DTF (variable), Socket Signature (min 64 bytes), Device Signature (min 64 bytes), Message Signature (min 64 bytes), Encrypted Payload (AES-256-GCM or ChaCha20-Poly1305), AEAD Auth Tag (128 bits). 12. Trust Mesh Architecture The Trust Mesh is the centralized architecture through which the ZTSL Server maintains and arbitrates all inter-client trust relationships. Key properties: * Centralized Mediation: All communication passes through the ZTSL Server. * Pairwise Connection Fingerprints: Each client-to-client pair has a unique Connection Fingerprint. * Trust Score Propagation: Changes in one client's trust score immediately affect all connections involving that client. * Dynamic Policy Enforcement: Policy updates propagated to all active Zessions via CP_POLICY_UPDATE. * Comprehensive Audit Trail: Every trust event recorded with opcode annotations. * Lateral Movement Prevention: A compromised client's connections MUST be immediately quarantined (ZS_CLOSE_FORCED) without disrupting other mesh participants. 13. Wire Format Examples 13.1. FAN_REQ_INITIAL First Bytes Offset Value (hex) Field ------ ----------- ----- 0x00 01 Opcode[Class] = 0x01 (FAN Operations) 0x01 01 Opcode[Op] = 0x01 (FAN_REQ) 0x02 01 Opcode[Sub] = 0x01 (INITIAL) 0x03 08 FrameFlags: SIG=1 0x04 00 02 14 00 Frame Length = 532 bytes (example) 0x08 00 * 16 Zession ID = all-zeros (pre-FAN) 0x18 00..01 (8B) Sequence No. = 1 0x20 00 * 32 Trust Context = all-zeros (pre-FAN) 0x40 [64 bytes] Ed25519 Frame Signature Rama Hebbar Expires 6 February 2027 [Page 25] Internet-Draft ZTSL Protocol August 2026 13.2. DP_DATA_NORMAL First Bytes Offset Value (hex) Field ------ ----------- ----- 0x00 04 Opcode[Class] = 0x04 (Data Plane) 0x01 01 Opcode[Op] = 0x01 (DATA_SEND) 0x02 03 Opcode[Sub] = 0x03 (NORMAL priority) 0x03 18 FrameFlags: SIG=1, ENC=1 0x04 [length] Frame Length 0x08 [ZessionID] 128-bit Zession ID 0x40 [FrameSig] Ed25519 Frame Signature (64 bytes) 0x80 [payload] MsgID,SrcID,DstID,Ts,Priority, MsgType,RoutingClass,PolicyID, ContentLen,SockFP,ConnFP,DTF, SockSig,DevSig,MsgSig, AES-256-GCM EncPayload, AEAD Auth Tag 14. Security Considerations 14.1. Opcode Binding as a Novel Security Primitive The inclusion of the 24-bit opcode in the Triple Signature computation constitutes a novel security primitive termed Opcode Binding. It provides: 1. Opcode Forgery Prevention: Substituting one opcode value for another in a captured frame immediately invalidates the Ed25519 or ECDSA P-384 signature. 2. Cross-Opcode Replay Prevention: A valid frame for 0x04.0x01.0x01 (CRITICAL) cannot be replayed as 0x04.0x01.0x03 (NORMAL) to downgrade message handling. 3. Protocol Confusion Prevention: A recovery opcode cannot be forged during ZESSION_ACTIVE state - the state machine blocks it and Opcode Binding prevents it. 4. Causal Audit Chain: The Recovery Trigger Opcode in REC_INITIATE creates a verifiable, signed causal link between threat detection and recovery. 14.2. Cryptographic Agility Implementations MUST support algorithm negotiation. Required: AES- 256-GCM (symmetric encryption), Ed25519 (signatures), SHA-256 (hash), X25519 (key exchange), HKDF-SHA-256 [RFC5869] (DTF derivation). Alternatives: ChaCha20-Poly1305, ECDSA P-384, SHA-384 or SHA-512, ECDH P-384. Rama Hebbar Expires 6 February 2027 [Page 26] Internet-Draft ZTSL Protocol August 2026 14.3. Replay Attack Prevention ZTSL employs multiple overlapping anti-replay mechanisms: sequence numbers with an anti-replay window of at least 64 entries; unique 256-bit nonces in FAN requests; 60- second timestamp validation window; Zession hash chain validation; Zession ID binding (frames from prior Zession MUST be rejected even if signatures are valid); and opcode sequence binding. 14.4. Denial of Service Mitigation FAN requests MUST be rate-limited per source address and per Identity Manager ID. Repeated failures MUST trigger exponential backoff carried in FAN_BACKOFF. After a configurable number of consecutive failures, the client's Identity Manager ID MUST be temporarily locked. Unknown opcode frames MUST be silently discarded (not rejected) to prevent opcode flooding DoS. 14.5. Side-Channel Resistance Implementations MUST use constant-time comparison for all cryptographic operations. Cryptographic operations SHOULD be performed in hardware-isolated environments (HSM, TPM, TEE) where available. 14.6. Key Management and Perfect Forward Secrecy All session keys MUST be ephemeral. PFS MUST be achieved via ephemeral key exchange (X25519 or ECDH P-384) at Zession creation and at every Adaptive Recovery. Upon Zession termination, all session key material MUST be securely erased. Hardware-protected keys MUST be revoked through the hardware interface. 14.7. Post-Quantum Readiness ZTSL implementations SHOULD incorporate NIST-standardized post- quantum algorithms - ML-KEM [NIST.FIPS.203] for key encapsulation and ML-DSA [NIST.FIPS.204] for signatures - in hybrid mode alongside classical algorithms. 14.8. Audit and Non-Repudiation The Audit Engine MUST record sufficient information to support non- repudiation. Audit records MUST be integrity- protected and SHOULD be stored in a write-once or append- only log. Required events: AU_ZESSION_OPEN (all FAN outcomes), AU_ZESSION_CLOSE (final hash and metrics), AU_EVENT_SECURITY (all threat events), AU_RECOVERY_LOG (recovery events), AU_EVENT_POLICY (policy updates), AU_EVENT_TRUST Rama Hebbar Expires 6 February 2027 [Page 27] Internet-Draft ZTSL Protocol August 2026 (Trust Score changes below threshold). 14.9. Trust Score Manipulation Trust Score computation MUST rely exclusively on verifiable, hardware-attested measurements where available. Trust Score inputs MUST NOT be modifiable by the client. The algorithm MUST be defined in administrator policy and MUST be versioned. 14.10. Insider Threat Implementations SHOULD deploy anomaly detection monitoring for unusual communication patterns. Anomaly detection events MUST be emitted as AU_EVENT_SECURITY frames. 14.11. Physical Security Device Trust Flags SHOULD be derived from hardware-rooted trust mechanisms (TPM 2.0 [TPM2.0], Apple Secure Enclave, or equivalent). Implementations MUST clearly document the security properties of DTF derivation for both hardware and software attestation paths. 14.12. Opcode Namespace Exhaustion Implementations MUST maintain a local opcode allowlist from the IANA ZTSL Opcode Registry. Frames with opcodes not in the allowlist MUST be silently discarded and logged as AU_EVENT_SECURITY. 14.13. State Machine Enforcement Implementations MUST enforce the opcode state machine (Section 8). Acceptance of an out-of- state opcode MUST be treated as CP_ERROR_FATAL and MUST trigger Zession termination. This prevents protocol confusion attacks. 14.14. ABL Buffer Security The ABL application send buffer MUST be stored in memory protected against swapping to persistent storage. The buffer MUST be securely cleared after recovery completes or fails. Buffer size MUST be bounded by a configurable maximum to prevent memory exhaustion. 15. IANA Considerations This document requests that IANA create a new "ZTSL Protocol Parameters" registry group containing the following registries. Rama Hebbar Expires 6 February 2027 [Page 28] Internet-Draft ZTSL Protocol August 2026 15.1. ZTSL Primary Opcode Class Registry Registration policy: Standards Action (0x00-0x3F), IETF Review (0x40-0x7F), First Come First Served (0x80-0xBF). Initial values: 0x00 Control Plane, 0x01 FAN Operations, 0x02 Zession Management, 0x03 Socket Operations, 0x04 Data Plane, 0x05 Trust Operations, 0x06 Recovery Operations, 0x07 Audit and Telemetry (all referencing this document). 0x08-0x3F IETF-Reserved (Standards Action); 0x40-0x7F IETF-Assignable (IETF Review); 0x80-0xBF Private Use; 0xC0-0xFE Future Extension; 0xFF RESERVED. 15.2. ZTSL Operation Code Sub-Registries IANA is requested to create a sub-registry per Primary Opcode Class titled "ZTSL [ClassName] Operation Codes", with initial values as defined in Section 7. Registration policy: Standards Action (0x00-0x3F), IETF Review (0x40-0x7F). 15.3. ZTSL Frame Flags Registry IANA is requested to create a registry titled "ZTSL Frame Flags" with 8 single-bit entries (Bits 0-7) as defined in Section 4.12. 15.4. ZTSL Adaptive Protocol Identifier Registry Initial values: 0x0001 TCP (RFC 793), 0x0002 QUIC (RFC 9000), 0x0003 SCTP (RFC 4960), 0x0004 DCCP (RFC 4340), 0x0005 HTTP/HTTPS Tunnel; 0x0006-0x7FFF IETF-Assignable; 0x8000-0xFFFE Private Use; 0xFFFF RESERVED. 15.5. Well-Known Port Number A well-known TCP/UDP/SCTP/QUIC port for the ZTSL control channel is requested. Specific value TBD pending IANA assignment. 15.6. ALPN Identifier An ALPN identifier of "ztsl/1" is requested for use in TLS [RFC8446] and QUIC [RFC9000] negotiation contexts. 16. References 16.1. Normative References [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, September 1981, . Rama Hebbar Expires 6 February 2027 [Page 29] Internet-Draft ZTSL Protocol August 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021, . 16.2. Informative References [NIST.FIPS.203] National Institute of Standards and Technology, "Module- Lattice-Based Key-Encapsulation Mechanism Standard", NIST FIPS 203, August 2024, . [NIST.FIPS.204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", NIST FIPS 204, August 2024, . Rama Hebbar Expires 6 February 2027 [Page 30] Internet-Draft ZTSL Protocol August 2026 [NIST.SP.800-207] Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture", NIST Special Publication 800-207, August 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 8949, December 2020, . [TPM2.0] Trusted Computing Group, "Trusted Platform Module Library Specification, Family 2.0", 2019, . Appendix A: Key Term Summary FAN Mandatory 6-dimension trust establishment gateway before any Zession. Zession Continuously verified trust context with opcode-annotated hash chain history. DTF Per-packet cryptographic device validation token. CSRP Signed versioned client trust and routing profile. HBF Trust-carrying heartbeat structure. Triple Signature Socket + Device + Message signatures, each with Opcode Binding. Trust Triangle Sender <-> Server <-> Receiver three-way trust model. Trust Mesh Centralized inter-client trust management architecture. Adaptive Recovery Application-transparent cryptographic regeneration on compromise. Opcode Binding Opcode included in Triple Signature; prevents forgery or substitution. ABL Transparent shim mapping socket API calls to ZTSL opcode sequences. Opcode State Machine FSA defining which opcodes are legal in each ZTSL state. Rama Hebbar Expires 6 February 2027 [Page 31] Internet-Draft ZTSL Protocol August 2026 Appendix B: High-Level Communication Flow Summary 1. Administrator defines policies (root of trust). 2. Initialize ZTSL Server (12 engine components). 3. Generate Managed Clients (CSRP, Certs, DTF seeds). 4. Install Client, Register Device (DTF computed from hardware measurements). 5. FAN: CP_VERSION_HELLO -> FAN_REQ_INITIAL -> FAN_ACCEPT. 6 dimensions validated, TrustScore computed. 6. Adaptive Protocol Negotiation embedded in FAN_ACCEPT. APFingerprint assigned. 7. Zession Creation: ZS_CREATE -> ZS_CREATE_ACK -> AU_ZESSION_OPEN. Hash-chained Zession active. 8. Secure Socket Creation: SK_CREATE -> SK_CREATE_ACK. SockFP assigned. 9. Trust Triangle: SK_CONNECT -> SK_CONNECT_ACK. ConnFP assigned. 10. Message Preparation: MsgID, Priority, RoutingClass, PolicyID prepared. 11. Triple Signature with Opcode Binding: SockSig, DevSig, MsgSig computed. 12. ZTSL Packet Construction: DP_DATA_* with full trust context. 13. Server-Side Validation: 10 ordered steps. 14. Trust-Aware Routing: Trust Score + QoS + Policy. 15. Receiver-Side Validation: 8 ordered steps with Opcode Binding confirmation. 16. Encrypted Delivery to Application via ABL recv(). 17. Heartbeat Synchronization (every HBInterval): TR_HEARTBEAT -> TR_HEARTBEAT_ACK -> ZS_SYNC -> ZS_SYNC_ACK. 18. Continuous Trust Evaluation (7-dimension ongoing). 19. Threat Detection: TR_THREAT_* -> TR_URG -> TR_URG_SUSPEND. Rama Hebbar Expires 6 February 2027 [Page 32] Internet-Draft ZTSL Protocol August 2026 20. Adaptive Recovery (6-step): REC_INITIATE through REC_RESUME. Application unaware. 21. Secure Termination: ZS_CLOSE -> ZS_CLOSE_ACK -> AU_ZESSION_CLOSE -> SK_CLOSE -> SK_CLOSE_ACK. Keys erased. Appendix C: Complete Opcode Reference Table (84 opcodes) +------------------+-----------------------+---------------------+ | Opcode | Symbolic Name | Legal States | +------------------+-----------------------+---------------------+ | 0x00.0x00.0x00 | CP_VERSION_HELLO | PRE_FAN | | 0x00.0x00.0x01 | CP_VERSION_ACCEPT | PRE_FAN | | 0x00.0x00.0x02 | CP_VERSION_REJECT | PRE_FAN | | 0x00.0x01.0x00 | CP_ERROR | ALL | | 0x00.0x01.0x01 | CP_ERROR_FATAL | ALL | | 0x00.0x01.0x02 | CP_ERROR_WARN | ALL | | 0x00.0x02.0x00 | CP_POLICY_UPDATE | ZESSION_ACTIVE | | 0x00.0x02.0x01 | CP_POLICY_ACK | ZESSION_ACTIVE | | 0x00.0x03.0x00 | CP_KEEPALIVE | ZESSION_ACTIVE | | 0x01.0x01.0x01 | FAN_REQ_INITIAL | PRE_FAN | | 0x01.0x01.0x02 | FAN_REQ_REAUTH | FAN_NEGOTIATION | | 0x01.0x01.0x03 | FAN_REQ_RECOVERY | RECOVERY | | 0x01.0x02.0x00 | FAN_CHALLENGE | FAN_NEGOTIATION | | 0x01.0x02.0x01 | FAN_CHALLENGE_DTF | FAN_NEGOTIATION | | 0x01.0x02.0x02 | FAN_CHALLENGE_NONCE | FAN_NEGOTIATION | | 0x01.0x03.0x00 | FAN_RESPONSE | FAN_NEGOTIATION | | 0x01.0x04.0x00 | FAN_ACCEPT | FAN_NEGOTIATION | | 0x01.0x04.0x01 | FAN_ACCEPT_DEGRADED | FAN_NEGOTIATION | | 0x01.0x05.0x01 | FAN_REJECT_DTF | FAN_NEGOTIATION | | 0x01.0x05.0x02 | FAN_REJECT_CERT | FAN_NEGOTIATION | | 0x01.0x05.0x03 | FAN_REJECT_POLICY | FAN_NEGOTIATION | | 0x01.0x05.0x04 | FAN_REJECT_IDENTITY | FAN_NEGOTIATION | | 0x01.0x05.0x05 | FAN_REJECT_APP | FAN_NEGOTIATION | | 0x01.0x05.0x06 | FAN_REJECT_NETWORK | FAN_NEGOTIATION | | 0x01.0x05.0x07 | FAN_REJECT_REPLAY | FAN_NEGOTIATION | | 0x01.0x05.0x08 | FAN_REJECT_SKEW | FAN_NEGOTIATION | | 0x01.0x06.0x00 | FAN_BACKOFF | FAN_NEGOTIATION | | 0x02.0x01.0x00 | ZS_CREATE | FAN_NEG, RECOVERY | | 0x02.0x01.0x01 | ZS_CREATE_ACK | FAN_NEG, RECOVERY | | 0x02.0x02.0x00 | ZS_UPDATE | ZESSION_ACTIVE | | 0x02.0x02.0x01 | ZS_UPDATE_TRUST | ZESSION_ACTIVE | | 0x02.0x02.0x02 | ZS_UPDATE_POLICY | ZESSION_ACTIVE | | 0x02.0x02.0x03 | ZS_UPDATE_PROTOCOL | ZESSION_ACTIVE | | 0x02.0x03.0x00 | ZS_SYNC | ZESSION_ACTIVE | | 0x02.0x03.0x01 | ZS_SYNC_ACK | ZESSION_ACTIVE | | 0x02.0x03.0x02 | ZS_SYNC_MISMATCH | ZESSION_ACTIVE | | 0x02.0x04.0x00 | ZS_DEGRADE | ZESSION_ACTIVE | Rama Hebbar Expires 6 February 2027 [Page 33] Internet-Draft ZTSL Protocol August 2026 | 0x02.0x04.0x01 | ZS_DEGRADE_RECOVER | TRUST_DEGRADED | | 0x02.0x05.0x00 | ZS_CLOSE | ALL | | 0x02.0x05.0x01 | ZS_CLOSE_ACK | TERMINATION | | 0x02.0x05.0x02 | ZS_CLOSE_FORCED | ALL | | 0x03.0x01.0x00 | SK_CREATE | ZESSION_ACTIVE | | 0x03.0x01.0x01 | SK_CREATE_ACK | ZESSION_ACTIVE | | 0x03.0x01.0x02 | SK_CREATE_REJECT | ZESSION_ACTIVE | | 0x03.0x02.0x00 | SK_BIND | ZESSION_ACTIVE | | 0x03.0x02.0x01 | SK_BIND_ACK | ZESSION_ACTIVE | | 0x03.0x03.0x00 | SK_CONNECT | ZESSION_ACTIVE | | 0x03.0x03.0x01 | SK_CONNECT_ACK | ZESSION_ACTIVE | | 0x03.0x03.0x02 | SK_CONNECT_REJECT | ZESSION_ACTIVE | | 0x03.0x04.0x00 | SK_CLOSE | TERMINATION | | 0x03.0x04.0x01 | SK_CLOSE_ACK | TERMINATION | | 0x03.0x05.0x00 | SK_PROFILE | ZESSION_ACTIVE | | 0x03.0x05.0x01 | SK_PROFILE_UPDATE | ZESSION_ACTIVE | | 0x04.0x01.0x01 | DP_DATA_CRITICAL | ZESSION_ACTIVE | | 0x04.0x01.0x02 | DP_DATA_HIGH | ZESSION_ACTIVE | | 0x04.0x01.0x03 | DP_DATA_NORMAL | ZESSION_ACTIVE | | 0x04.0x01.0x04 | DP_DATA_LOW | ZESSION_ACTIVE | | 0x04.0x01.0x05 | DP_DATA_BACKGROUND | ZESSION_ACTIVE | | 0x04.0x02.0x00 | DP_DATA_ACK | ZESSION_ACTIVE | | 0x04.0x02.0x01 | DP_DATA_NACK | ZESSION_ACTIVE | | 0x04.0x03.0x00 | DP_META_ONLY | ZESSION_ACTIVE | | 0x04.0x04.0x00 | DP_FRAGMENT | ZESSION_ACTIVE | | 0x04.0x04.0x01 | DP_FRAGMENT_LAST | ZESSION_ACTIVE | | 0x04.0x05.0x00 | DP_SIGN_SOCKET | ZESSION_ACTIVE | | 0x04.0x05.0x01 | DP_SIGN_DEVICE | ZESSION_ACTIVE | | 0x04.0x05.0x02 | DP_SIGN_MESSAGE | ZESSION_ACTIVE | | 0x04.0x06.0x00 | DP_ROUTE_ANNOUNCE | ZESSION_ACTIVE | | 0x04.0x06.0x01 | DP_ROUTE_REJECT | ZESSION_ACTIVE | | 0x05.0x01.0x00 | TR_HEARTBEAT | ACTIVE, DEGRADED | | 0x05.0x01.0x01 | TR_HEARTBEAT_ACK | ACTIVE, DEGRADED | | 0x05.0x01.0x02 | TR_HEARTBEAT_MISS | ACTIVE, DEGRADED | | 0x05.0x02.0x00 | TR_SCORE_UPDATE | ACTIVE, DEGRADED | | 0x05.0x02.0x01 | TR_SCORE_BELOW_MIN | ACTIVE, DEGRADED | | 0x05.0x02.0x02 | TR_SCORE_CRITICAL | ACTIVE, DEGRADED | | 0x05.0x03.0x00 | TR_THREAT_DETECT | ZESSION_ACTIVE | | 0x05.0x03.0x01 | TR_THREAT_DTF_FAIL | ZESSION_ACTIVE | | 0x05.0x03.0x02 | TR_THREAT_APP_MOD | ZESSION_ACTIVE | | 0x05.0x03.0x03 | TR_THREAT_HASH_BREAK | ZESSION_ACTIVE | | 0x05.0x03.0x04 | TR_THREAT_REPLAY | ZESSION_ACTIVE | | 0x05.0x03.0x05 | TR_THREAT_FP_MISMATCH | ZESSION_ACTIVE | | 0x05.0x03.0x06 | TR_THREAT_POLICY_VIOL | ZESSION_ACTIVE | | 0x05.0x03.0x07 | TR_THREAT_SKEW | ZESSION_ACTIVE | | 0x05.0x04.0x00 | TR_URG | ALL | | 0x05.0x04.0x01 | TR_URG_SUSPEND | ALL | | 0x05.0x04.0x02 | TR_URG_RESUME | RECOVERY | Rama Hebbar Expires 6 February 2027 [Page 34] Internet-Draft ZTSL Protocol August 2026 | 0x06.0x01.0x00 | REC_INITIATE | DEGRADED, RECOVERY | | 0x06.0x01.0x01 | REC_INITIATE_CLIENT | TRUST_DEGRADED | | 0x06.0x02.0x00 | REC_KEY_EXCHANGE | RECOVERY | | 0x06.0x02.0x01 | REC_KEY_CONFIRM | RECOVERY | | 0x06.0x03.0x00 | REC_DTF_REQUEST | RECOVERY | | 0x06.0x03.0x01 | REC_DTF_RESPONSE | RECOVERY | | 0x06.0x03.0x02 | REC_DTF_ACCEPT | RECOVERY | | 0x06.0x03.0x03 | REC_DTF_REJECT | RECOVERY | | 0x06.0x04.0x00 | REC_FP_UPDATE | RECOVERY | | 0x06.0x05.0x00 | REC_ZESSION_NEW | RECOVERY | | 0x06.0x05.0x01 | REC_ZESSION_SYNC | RECOVERY | | 0x06.0x06.0x00 | REC_CSRP_UPDATE | RECOVERY | | 0x06.0x06.0x01 | REC_CSRP_ACK | RECOVERY | | 0x06.0x07.0x00 | REC_RESUME | RECOVERY | | 0x06.0x07.0x01 | REC_FAILED | RECOVERY | | 0x06.0x08.0x00 | REC_TERMINATE_ZESSION | RECOVERY | | 0x07.0x01.0x00 | AU_EVENT | ALL | | 0x07.0x01.0x01 | AU_EVENT_SECURITY | ALL | | 0x07.0x01.0x02 | AU_EVENT_TRUST | ALL | | 0x07.0x01.0x03 | AU_EVENT_POLICY | ALL | | 0x07.0x02.0x00 | AU_ZESSION_OPEN | ZESSION_ACTIVE | | 0x07.0x02.0x01 | AU_ZESSION_CLOSE | TERMINATION | | 0x07.0x03.0x00 | AU_METRICS | ACTIVE, TERMINATION | | 0x07.0x04.0x00 | AU_NONREPUDIATION | ALL | | 0x07.0x05.0x00 | AU_RECOVERY_LOG | RECOVERY | +------------------+-----------------------+---------------------+ Author's Address Sripad Rama Hebbar Independent Bangalore India Email: sripadkarthik@gmail.com Rama Hebbar Expires 6 February 2027 [Page 35]