Network Working Group H. Jorgen Internet-Draft Kenosian Intended status: Experimental 30 September 2026 Expires: 3 April 2027 The TLS TimeToken Secure Protocol (TTTPS) draft-helmprotocol-tttps-12 Abstract This document specifies TTTPS, an application-layer protocol for evaluating temporal evidence before an application accepts an event or performs a related state transition. The protocol defines a fixed 180-byte Proof-of-Time Record v2 containing context, freshness, integrity, issuer-authentication, and holder-authentication fields. When TLS 1.3 transport binding is selected, a separate holder binding proof is derived from TLS exporter output and holder key material. The proof is sent with, but is not part of, the 180-byte record. The fixed-record GRG admission path is bounded with respect to peer count under declared frame and correction limits. TTTPS returns an explicit admission result before application state mutation. Confidence and propagation-aware profiles are optional. This document does not define agent intent, audit record schemas, or transparency-log operation. Changes from -11 Specifies sampled lower-median synthesis, separate future-skew and past-freshness windows, a record-hash binding transcript, binary HTTP/3 content mapping, provision-stage identifiers, and reproducible verification evidence. The 180-octet record layout is unchanged; transport-binding revision selection is explicit. 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/. Jorgen Expires 3 April 2027 [Page 1] Internet-Draft TTTPS September 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 3 April 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 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 1.7. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 2. Proof-of-Time Structure . . . . . . . . . . . . . . . . . . . 6 2.1. PoT Record v2 Wire Format . . . . . . . . . . . . . . . . 6 2.2. Field Definitions . . . . . . . . . . . . . . . . . . . . 7 2.3. Holder Authentication Types . . . . . . . . . . . . . . . 8 2.4. Generation Algorithm . . . . . . . . . . . . . . . . . . 9 2.5. Verification Procedure . . . . . . . . . . . . . . . . . 9 2.6. JOSE and COSE Data Representations . . . . . . . . . . . 11 2.6.1. COSE / CBOR Data Model (CWT Mapping) . . . . . . . . 11 2.6.2. JOSE / JSON Data Model (JWS Mapping) . . . . . . . . 11 3. Relationship to Existing Mechanisms . . . . . . . . . . . . . 12 4. Integrity Algorithm Interface . . . . . . . . . . . . . . . . 12 4.1. Abstract Interface . . . . . . . . . . . . . . . . . . . 12 4.2. Optional Integrity Profiles . . . . . . . . . . . . . . . 13 4.3. External GRG Interface . . . . . . . . . . . . . . . . . 13 5. AdaptiveSwitch . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Transition Conditions and Hysteresis . . . . . . . . . . 14 Jorgen Expires 3 April 2027 [Page 2] Internet-Draft TTTPS September 2026 5.3. Penalty and Exponential Backoff . . . . . . . . . . . . . 14 5.4. Policy Thresholds . . . . . . . . . . . . . . . . . . . . 14 5.5. External Policy and Profile Inputs . . . . . . . . . . . 14 5.6. GRG Physical Framing Boundary . . . . . . . . . . . . . . 15 6. Transport Binding . . . . . . . . . . . . . . . . . . . . . . 15 6.1. TLS 1.3 Binding . . . . . . . . . . . . . . . . . . . . . 15 6.2. QUIC Integration . . . . . . . . . . . . . . . . . . . . 16 6.3. HTTP/3 Content Mapping . . . . . . . . . . . . . . . . . 17 6.4. Backward Compatibility . . . . . . . . . . . . . . . . . 17 7. Clock Substrate Interface . . . . . . . . . . . . . . . . . . 18 8. Tier Structure . . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9.1. Compromised Time Sources and Path Attacks . . . . . . . . 18 9.2. Replay Prevention . . . . . . . . . . . . . . . . . . . . 19 9.3. Sybil Time Sources and Unique Quorum . . . . . . . . . . 20 9.4. Side-Channel Considerations . . . . . . . . . . . . . . . 20 9.5. Resource and Ordering Attacks . . . . . . . . . . . . . . 20 9.6. Delay-Based Temporal Attacks . . . . . . . . . . . . . . 21 9.7. Integrity Algorithm Security . . . . . . . . . . . . . . 22 9.8. Path Manipulation . . . . . . . . . . . . . . . . . . . . 22 9.9. Trust Model and Key Compromise Resilience . . . . . . . . 22 9.9.1. Trust Hierarchy . . . . . . . . . . . . . . . . . . . 22 9.9.2. Issuer Key Compromise Response . . . . . . . . . . . 23 9.9.3. Untrusted Substrate Scope . . . . . . . . . . . . . . 23 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 10.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . 23 10.2. Minimal Disclosure . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 12. Intellectual Property . . . . . . . . . . . . . . . . . . . . 24 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 13.1. Reference Implementation . . . . . . . . . . . . . . . . 24 13.2. Deployment Evidence . . . . . . . . . . . . . . . . . . 25 13.3. Formal Verification Artifacts . . . . . . . . . . . . . 26 13.4. Interested Parties . . . . . . . . . . . . . . . . . . . 27 14. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 15.1. Normative References . . . . . . . . . . . . . . . . . . 28 15.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. AdaptiveSwitch State Contract . . . . . . . . . . . 29 Appendix B. Integrity Algorithm Interface and SHA-256 . . . . . 32 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 33 Appendix D. FILO+Integrity Delay Rejection Flow . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 Jorgen Expires 3 April 2027 [Page 3] Internet-Draft TTTPS September 2026 1. Introduction TTTPS defines an application-layer protocol for evaluating temporal evidence before an application accepts an event or performs a related state transition. It is intended for records exchanged by agents, services, and other distributed principals. TLS provides peer authentication, confidentiality, and channel integrity. DNSSEC provides origin authentication and integrity for DNS data. Neither protocol, by itself, provides the temporal admission function defined here. TTTPS does not replace TLS, DNSSEC, RATS, WIMSE, OAuth, AUDIT, or SCITT. 1.1. Motivation An authenticated event may still be stale, replayed, or bound to the wrong context. If an event changes application state before those conditions are evaluated, a later audit record cannot undo the state transition. TTTPS places the temporal decision before that transition. 1.2. Objectives TTTPS has four objectives: * bind a temporal record to an issuer, context, nonce, and holder session; * reject invalid, replayed, or stale records before application ingestion; * return explicit ACCEPT, HOLD, UNVERIFIABLE, or REJECT outcomes; and * support a fixed-record GRG path whose verification cost is O(1) with respect to peer count when frame, correction, and memory limits are fixed. The last property applies to the bounded single-record path. It does not make quorum aggregation, queue selection, entropy analysis, or transparency logging O(1). Jorgen Expires 3 April 2027 [Page 4] Internet-Draft TTTPS September 2026 1.3. Protocol Overview A sender obtains an issuer-signed PoT Record. When transport binding is enabled, the holder produces a separate binding proof after the TLS handshake. The receiver parses the fixed 180-octet record, verifies integrity and context, checks replay and freshness, verifies the issuer signature and holder proof, and only then invokes application policy. The admission result precedes application state mutation. Over TLS 1.3 or QUIC, the binding uses the TLS exporter after the handshake reaches the application-data state. Over other transports, the deployment MUST define an equivalent binding or explicitly disable that part of the protocol. 1.4. Scope The core specification defines the 180-octet PoT Record, its integrity boundary, issuer and holder authentication, transport binding, freshness checks, and admission states. Confidence and Deep-space processing are optional profiles. The core does not define agent intent, an audit record schema, a transparency log, or a particular time-source vendor. 1.5. Terminology 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, as shown here. Issuer: the authority that creates and signs a PoT Record. Holder: the principal that proves possession of the holder key or shared secret and binds the record to the transport session. Verifier: the party that evaluates a record and returns an admission result. PoT Record: the fixed 180-octet protocol record described in Section 2. Context manifest: authenticated out-of-band data identified by ctx_id. Jorgen Expires 3 April 2027 [Page 5] Internet-Draft TTTPS September 2026 1.6. Use Cases TTTPS can be used before an agent action, service request, or delegated interaction is admitted to an application state machine. In an AUDIT deployment, the admission result can be carried into an interaction, action, or delegation record. In a SCITT deployment, the result and record digest can be logged after the local admission decision. These mappings do not change the TTTPS wire record. 1.7. Problem Statement Existing authentication and transparency mechanisms do not by themselves answer whether an event is fresh and context-valid at the instant it is admitted. TTTPS addresses that pre-ingestion gap. It does not claim that a valid temporal record proves agent intent, physical truth, or the absence of a compromised trust authority. 2. Proof-of-Time Structure This section specifies the fixed 180-octet PoT Record. The record separates the Issuer's attestation of synthesised time from the Holder's proof of possession bound to a live TLS session. The separate binding proof closes the binding weakness identified in earlier revisions. 2.1. PoT Record v2 Wire Format A PoT Record is encoded as a fixed 180-octet binary sequence. All multi-octet integer fields are in network byte order (big-endian). Offset Length Field ------ ------ ----------------------------------------------- 0 1 version (0x02 for this document) 1 1 holder_auth_type (0x01 Ed25519 pk MTI, 0x02 shared secret OPTIONAL) 2 2 alg_id (integrity algorithm, Section 4) 4 8 ts (TAI microseconds since epoch) 12 4 dispersion (microseconds, uncertainty bound) 16 16 ctx_id (opaque context identifier) 32 16 nonce (cryptographically random) 48 32 holder_auth_data (holder public key, or PSK digest) 80 32 integrity_tag (Section 4, algorithm per alg_id) 112 4 issuer_key_id (Issuer signing-key identifier) 116 64 issuer_sig (Ed25519 over octets 0-115) ------ ------ Total: 180 octets Jorgen Expires 3 April 2027 [Page 6] Internet-Draft TTTPS September 2026 The binding_proof carried alongside the PoT Record at TLS binding time (Section 6.1) is a separate value, not part of these 180 octets: it is computed by the Holder from live TLS session material and cannot be produced at PoT generation time, which is the point of the separation. 2.2. Field Definitions version (8 bits): Protocol version. This document defines version 2 (0x02). Implementations MUST reject PoT records with unknown versions. holder_auth_type (8 bits): Identifies how the Holder proves possession. See Section 2.3. Implementations MUST reject unknown values. alg_id (16 bits): Identifies the integrity algorithm protecting this record (Section 4). Implementations MUST reject unsupported values. ts (64 bits): Synthesised timestamp: ts = sampled lower-median(T_1, ..., T_k), k >= 3 sources from independent administrative domains. TAI microseconds since 1958-01-01 00:00:00 TAI, the fixed wire epoch used by this document. TAI is continuous; UTC leap-second adjustments are not applied to this count. TAI, rather than UTC, is used to avoid leap-second ambiguity in the freshness comparison of Section 2.5. Synthesis MUST use at least three independent sources from distinct administrative domains (e.g., a national metrology laboratory, a GNSS-disciplined source, and an NTS-authenticated source). dispersion (32 bits): Synthesis uncertainty bound in microseconds: dispersion = max|T_i - ts| across the k sources. Used in the freshness check of Section 2.5. ctx_id (128 bits): An opaque, application-assigned context identifier. Binds the PoT Record to its context; see Section 4.1. A verifier that enables an optional profile MUST resolve ctx_id against an authenticated context manifest before selecting a physical or confidence profile. The manifest MAY select a terrestrial, near- Earth/SAGIN, cislunar, or deep-space profile. A missing, expired, contradictory, or unauthorized mapping MUST result in HOLD or UNVERIFIABLE; the verifier MUST NOT infer deep-space context from packet arrival time or silently apply a terrestrial default. Jorgen Expires 3 April 2027 [Page 7] Internet-Draft TTTPS September 2026 The manifest is out of band and is not part of the fixed 180-octet record. It SHOULD bind the profile identifier, epoch, time scale, coordinate frame, endpoints, OWLT interval, navigation or ephemeris authority, uncertainty budget, peer/provenance digest, and policy revision to ctx_id. This lookup is the automatic profile-dispatch mechanism and does not change the PoT wire length. nonce (128 bits): Cryptographically random value. MUST be generated with a cryptographically secure random number generator. Provides replay prevention in conjunction with Section 9.2. holder_auth_data (256 bits): For holder_auth_type 0x01: the Holder's Ed25519 public key. For holder_auth_type 0x02: SHA-256(k_h), a digest of the pre-shared secret, never the secret itself. integrity_tag (256 bits): Output of the algorithm identified by alg_id (Section 4), computed over octets 0-79. Detection and correction semantics are declared by the selected profile; core SHA-256 only detects. issuer_key_id (32 bits): Identifies the Issuer's signing key, enabling key rotation without requiring verifiers to trial multiple keys. issuer_sig (512 bits): Ed25519 signature by the Issuer's private key over octets 0-115 (all preceding fields), following EUF-CMA security. Issuer signature verification detects alteration by a party lacking the Issuer's signing key. It does not prove that the Issuer's timestamp or source measurements are physically correct. A compromised or dishonest Issuer can sign false data; source policy, key status, and independent evidence address that separate risk. 2.3. Holder Authentication Types 0x01 -- Ed25519 public key (Mandatory-to-Implement): holder_auth_data = holder_pk (32 octets). binding_proof (64 octets) = Ed25519.Sign(holder_sk, binding_input), verifiable by any party holding holder_pk (Section 6.1). 0x02 -- Shared secret (OPTIONAL): holder_auth_data = SHA-256(k_h) (32 octets). binding_proof (32 octets) = HMAC-SHA256(k_h, binding_input). This type requires out-of-band distribution of k_h between Holder and verifier and MUST NOT be used where verification by an external party that does not already possess k_h is required. Jorgen Expires 3 April 2027 [Page 8] Internet-Draft TTTPS September 2026 2.4. Generation Algorithm 1. Query k >= 3 time sources from independent administrative domains. Convert every reading to integer TAI microseconds using the epoch defined in Section 2.2. 2. Sort the readings in ascending order. Set ts to the element at zero-based index floor((k - 1) / 2). This is the middle element for odd k and the lower of the two middle elements for even k. 3. For each reading T_i, compute its absolute distance from ts by subtracting the smaller unsigned value from the larger. Set dispersion to the largest such distance. 4. If dispersion exceeds stratum_tolerance or UINT32_MAX: ABORT. stratum_tolerance is an authenticated policy value in microseconds. 5. Generate a 128-bit cryptographically random nonce. 6. Assemble octets 0-79: version, holder_auth_type, alg_id, ts, dispersion, ctx_id, nonce, holder_auth_data. 7. Compute integrity_tag over octets 0-79 using the algorithm identified by alg_id (Section 4). 8. Assign issuer_key_id identifying the signing Issuer key. 9. Compute issuer_sig = Ed25519.Sign(issuer_sk, octets 0-115). 10. Output the 180-octet PoT Record v2. binding_proof is deliberately not computed at generation time: it requires TLS session material that does not yet exist when the Issuer generates the record, and is instead computed by the Holder at TLS binding time (Section 6.1). 2.5. Verification Procedure A verifier processes the delimited PoT Record and external holder proof in the following order. All time values use the same TAI microsecond scale and the epoch specified in Section 2.2. 1. Bound the candidate pair to exactly 244 or 212 octets. Only then read holder_auth_type and require its corresponding 64-octet Ed25519 or 32-octet PSK proof. Reject a mismatched length. 2. Check version, alg_id, and holder_auth_type. Unsupported values cause REJECT. Jorgen Expires 3 April 2027 [Page 9] Internet-Draft TTTPS September 2026 3. Check integrity_tag over octets 0-79 using the selected profile. Core SHA-256 is detection-only. An optional bounded correction result still requires every subsequent verification step. 4. Validate now, ts, tier_window_us, and max_clock_skew_us as uint64 microseconds and dispersion as uint32 microseconds. The default max_clock_skew_us is 500,000 microseconds. A different value MUST be selected by authenticated policy. Apply the two windows: if ts > now: skew_us = ts - now if skew_us > max_clock_skew_us: REJECT else: delay_us = now - ts if tier_window_us > UINT64_MAX - dispersion: REJECT bound_us = tier_window_us + dispersion if delay_us > bound_us: REJECT and enter FULL Equality is within the selected window. Dispersion extends only the past-freshness bound; it MUST NOT extend the future-skew allowance. Wrapped subtraction or addition MUST NOT determine admission. Policy selection precedes these comparisons. 5. Perform a bounded read-only replay lookup for (ctx_id, nonce) before issuer-key resolution, signature verification, or holder proof verification. If consumed, REJECT. A cache miss MUST NOT insert or reserve the pair. The final atomic claim is mandatory. 6. Resolve issuer_key_id through authenticated trust evidence. Check chain, key use, validity, and the configured revocation policy. 7. Verify issuer_sig over all 116 preceding octets, offsets 0-115 inclusive. In half-open slice notation this is pot_record[0:116]. 8. Derive the live TLS 1.3 exporter values exactly as in Section 6.1 and verify binding_proof under the selected holder type. 9. Evaluate authenticated context and application policy. HOLD, UNVERIFIABLE, and REJECT leave the nonce and application state unchanged. Only an authorized ACCEPT proceeds. 10. Atomically claim (ctx_id, nonce) and commit the application transition. Use one transaction where possible; otherwise use durable idempotency and a recovery rule. A claim conflict causes REJECT without application mutation. Emit ACCEPT only after the commit succeeds. A failed core check cannot be overridden by a later profile result. Jorgen Expires 3 April 2027 [Page 10] Internet-Draft TTTPS September 2026 2.6. JOSE and COSE Data Representations To facilitate seamless integration with modern identity, attestation, and cryptographic token frameworks (e.g., JWTs, CWTs, RATS Conceptual Message Wrappers [RFC9999]), a PoT Record v2 MAY be represented as either a COSE (CBOR Object Signing and Encryption) map or a JOSE (JSON Object Signing and Encryption) claim set. 2.6.1. COSE / CBOR Data Model (CWT Mapping) In CBOR Web Token (CWT) contexts, the PoT Record v2 is represented as a CBOR Map containing the following integer-keyed claims: +-------+-------------------+-------------------------------------+ | Claim | Key Name | CBOR Type & Value | +-------+-------------------+-------------------------------------+ | 1 | ver | unsigned integer (0x02) | | 2 | auth_type | unsigned integer (0x01 / 0x02) | | 3 | alg_id | unsigned integer (Section 4) | | 4 | ts | unsigned integer (microsecond TAI) | | 5 | dispersion | unsigned integer (microseconds) | | 6 | ctx_id | byte string (16 octets) | | 7 | nonce | byte string (16 octets) | | 8 | holder_auth_data | byte string (32 octets) | | 9 | integrity_tag | byte string (32 octets) | | 10 | issuer_key_id | unsigned integer (32 bits) | | 11 | issuer_sig | byte string (64 octets) | +-------+-------------------+-------------------------------------+ When encapsulated within a COSE_Sign1 structure, the 180-octet raw PoT record forms the COSE payload, and the binding_proof is carried in an unprotected COSE header attribute (Label: TBD_COSE_HEADER_TTTPS). 2.6.2. JOSE / JSON Data Model (JWS Mapping) In JSON Web Signature (JWS) and JWT contexts, the PoT Record v2 is represented as a JSON Object with deterministic Base64URL string encodings for byte arrays: Jorgen Expires 3 April 2027 [Page 11] Internet-Draft TTTPS September 2026 { "ver": 2, "auth_type": 1, "alg_id": 1, "ts": 1787184000000000, "dispersion": 5, "ctx_id": "Base64URL(16B)", "nonce": "Base64URL(16B)", "holder_auth_data": "Base64URL(32B)", "integrity_tag": "Base64URL(32B)", "issuer_key_id": 1001, "issuer_sig": "Base64URL(64B)" } When transmitted over HTTP APIs, a detached JWS header carries the binding_proof as a JOSE header parameter ("pot_bp"). 3. Relationship to Existing Mechanisms TLS supplies peer authentication, confidentiality, and channel integrity. DNSSEC supplies origin authentication and integrity for DNS data. RFC 3161 supplies timestamp tokens for document- preservation workflows. AUDIT and SCITT define audit and transparency records. TTTPS addresses a different point in the processing sequence: it evaluates a fixed record before the application commits a state change. A deployment MAY record the result in an AUDIT record or a SCITT log after admission. Those integrations do not change the TTTPS wire format, and this document does not claim that TTTPS replaces those mechanisms. 4. Integrity Algorithm Interface 4.1. Abstract Interface Each alg_id value selects an algorithm that computes integrity_tag over the 80-octet payload described in Section 2.1, and that a verifier uses to interpret integrity_tag against three possible outcomes: intact, resolved, or unresolvable (Section 2.5, step 3). This document defines SHA-256 as the core algorithm. Optional integrity profiles, including GRG, are defined outside the core and are identified here only through their profile documents. alg_id 0x0001 -- SHA-256 (Mandatory-to-Implement): Detection-only. Fully and publicly specified in Appendix B.1, All conformant implementations MUST support this algorithm. Jorgen Expires 3 April 2027 [Page 12] Internet-Draft TTTPS September 2026 Optional GRG profile: A verifier MAY select a GRG integrity profile only when the profile document is available and the deployment has separately evaluated interoperability and IPR applicability. The core does not assign a GRG algorithm definition or require its implementation. See [CONFIDENCE]. When the Confidence GRG profile is selected, its intact/resolved/ unresolvable integrity verdict is evaluated before freshness, replay, signature, confidence, or physical-context gates. A later gate MUST NOT convert unresolvable input into a valid PoT. Implementations of any registered algorithm MUST satisfy, at minimum: * Detection: a registered algorithm MUST state its detection and, if applicable, correction properties in its profile specification. * Context binding: the computation MUST incorporate ctx_id (via its presence in the protected octets), so that a record generated under one ctx_id cannot be revalidated as if generated under another. This revision does not allocate additional alg_id values. A future Working Group revision may define an allocation procedure after review. 4.2. Optional Integrity Profiles The core does not reproduce the internal construction, stage ordering, parameter choices, or correction claims of optional integrity profiles. The Confidence track [CONFIDENCE] is the independent profile reference for the optional GRG interface. A deployment MUST NOT infer that a profile is implemented, interoperable, or free of IPR constraints merely because the core accepts an algorithm identifier. 4.3. External GRG Interface The core does not define the internal construction, stage ordering, parameters, correction capacity, or transport framing of an optional GRG profile. A selected profile MUST be identified by an authenticated context and MUST declare its protected byte domain, decoder limits, and intact/resolved/unresolvable result contract. The core MUST process an unresolvable result as an integrity failure. A later freshness, issuer, holder, or policy result MUST NOT promote it to valid. The Confidence document is the companion specification for GRG-specific processing; this core document makes no IPR determination. Jorgen Expires 3 April 2027 [Page 13] Internet-Draft TTTPS September 2026 5. AdaptiveSwitch 5.1. State Machine AdaptiveSwitch maintains per-node TURBO or FULL mode. A node enters TURBO only after the configured promotion conditions are met. An integrity, freshness, or confidence failure moves it to FULL under the atomic transition in Appendix A. 5.2. Transition Conditions and Hysteresis The promotion threshold, maintenance threshold, observation window, and freshness window are deployment parameters. The promotion condition MUST include a valid integrity result and an in-window submission. The maintenance condition MUST be no less strict than the deployment policy declares. Implementations SHOULD use hysteresis to avoid rapid state flapping. 5.3. Penalty and Exponential Backoff A policy failure MAY transition the node to FULL and MAY increase a bounded backoff interval. The maximum backoff, reset condition, and counter scope MUST be configured and recorded. Backoff is an admission policy; it is not a cryptographic proof of malicious behaviour. 5.4. Policy Thresholds AdaptiveSwitch thresholds, freshness windows, backoff limits, and any cost or service policy are deployment parameters. An implementation MUST NOT treat example values in an implementation profile as protocol-wide guarantees. A deployment MAY use hysteresis and backoff to limit repeated policy failures, but these mechanisms do not establish an economic equilibrium or eliminate Byzantine behaviour. 5.5. External Policy and Profile Inputs TTTPS core verification ends after the integrity, freshness, replay, issuer-trust, and holder-binding checks in Section 2.5. A deployment MAY invoke a separate policy evaluator after those checks. The evaluator MAY consume G-Score, correlation-aware confidence, Epi- Entropy, effective-quorum, or propagation-aware context signals defined by the companion profiles [CONFIDENCE] and [DEEPSPACE]. Jorgen Expires 3 April 2027 [Page 14] Internet-Draft TTTPS September 2026 A policy result MUST NOT repair a failed core check, change the meaning of a PoT record, select a decoder, or modify the 180-octet record. It MAY return ACCEPT, HOLD, UNVERIFIABLE, or REJECT under its declared policy. HOLD MUST have a bounded terminal transition. 5.6. GRG Physical Framing Boundary The optional GRG integrity profile and any link-layer GRG framing profile are distinct contracts. The record is not automatically a Golay codeword stream because of its length. A deployment MUST declare the FEC code, interleaver, Rice parameter, protected byte domain, padding rule, and decoder limits before reception. The normative PoT record for this document is 180 octets. A framing profile MUST identify its own protected domain and length. Golay (23,12,7) and extended Golay [24,12,8] are not interchangeable, and a decoder MUST NOT select a code by length inference. The current checked GRG reference path uses Golay (23,12,7); any other code requires a separately identified profile and interoperability vectors. GRG parameter selection is session- and context-bound. The receiver MUST configure the selected profile before decoding and MUST fail closed on a profile or stream mismatch. FEC correction MUST NOT convert a failed cryptographic integrity result into PASS. After successful deinterleaving, FEC, and stream validation, the recovered 180-octet record is passed to the PoT parser. Epi-Entropy and G-Score operate only after that boundary and do not control FEC decoding. 6. Transport Binding 6.1. TLS 1.3 Binding After the TLS 1.3 handshake, the Holder and verifier derive binding material using the exporter interface of [RFC9846], Section 7.5. Labels below are literal ASCII octets; 0x00 is one zero octet and "||" is direct concatenation without length prefixes. The domain label "tttps-binding-v2" is 16 octets. record_hash and exporter_output are each 32 octets. The context hash input is exactly 49 octets and binding_input is exactly 81 octets. Hashing the complete record binds its ctx_id, nonce, holder data, issuer identifier, integrity tag, and issuer signature. Jorgen Expires 3 April 2027 [Page 15] Internet-Draft TTTPS September 2026 record_hash = SHA-256(pot_record[0:180]) context_value = SHA-256("tttps-binding-v2" || 0x00 || record_hash) exporter_output = TLS-Exporter( "EXPORTER-TTTPS-v2-Binding", context_value, 32) binding_input = "tttps-binding-v2" || 0x00 || exporter_output || record_hash if holder_auth_type == 0x01: binding_proof = Ed25519.Sign(holder_sk, binding_input) proof_len = 64 else if holder_auth_type == 0x02: binding_proof = HMAC-SHA256(k_h, binding_input) proof_len = 32 The verifier MUST check holder_auth_data and possession of the corresponding holder key or configured PSK. exporter_output MUST NOT be transmitted. The record/proof pair is exactly 244 or 212 octets. Session binding complements the replay ledger. This transcript is the draft-12 transport binding. It differs from the draft-11 transcript while retaining the same 180-octet record. Peers MUST select the binding revision explicitly in authenticated endpoint configuration or authenticated profile negotiation. A verifier MUST NOT infer that revision from record version 0x02, auto- detect an alternate transcript, or retry a legacy transcript after failure. Provision-stage identifiers are listed in Section 11. 6.2. QUIC Integration TTTPS operates over QUIC [RFC9000] post-handshake. The TLS Exporter is available after QUIC handshake completion. Holder Verifier |--Initial[CRYPTO]-------------->| (TLS ClientHello) |<-Initial[CRYPTO]--------------| (TLS ServerHello) |<-Handshake[CRYPTO]------------| (TLS EncryptedExtensions) |--Handshake[CRYPTO]----------->| (TLS Finished) | | | Holder computes binding_proof| | per Section 6.1 | | | |--1-RTT[STREAM:PoT frame]----->| |<-1-RTT[STREAM:PoT-Ack]--------| PoT frames MUST be sent in a dedicated QUIC stream. The stream identifier is a deployment parameter; this revision makes no IANA allocation. Jorgen Expires 3 April 2027 [Page 16] Internet-Draft TTTPS September 2026 6.3. HTTP/3 Content Mapping HTTP/3 carriage uses standard DATA frames (type 0x00) and the HTTP/3 h3 ALPN identifier [RFC9114]. No new HTTP/3 frame is defined. The endpoint URI and draft-12 binding revision MUST be explicitly selected. A request carrying one TTTPS object MUST use POST and: content-type: application/tttps Content-Length MUST be exactly 244 octets for holder type 0x01 or 212 octets for holder type 0x02. The message body is exactly pot_record[0:180] || binding_proof. It MAY span multiple DATA frames; reassembly MUST enforce the stated body-size bound before parsing. A different media type, inconsistent declared or received length, or mismatched holder proof length is a framing error. application/tttps is the provision-stage media type in Section 11. Its name carries no structured-syntax suffix. This mapping defines carriage; application bindings define the response semantics. Implementations apply standard HTTP/3 stream and unknown-frame handling. In particular, an ignored extension frame is not temporal evidence and does not select a TTTPS binding. 6.4. Backward Compatibility The PoT v2 core layout remains 180 octets. Record-version support and transport-binding revision support are separate capabilities. Peers MUST agree on both before exchanging a record and proof. Draft-11 and draft-12 holder proofs are not interchangeable. Direct TLS or QUIC application deployments use the tttps/1 ALPN provision-stage identifier in Section 11 when that protocol has been selected. A deployment MUST configure the binding revision independently of ALPN. HTTP/3 deployments continue to negotiate h3 and select TTTPS through the endpoint and media type in Section 6.3. The TTTPS ALPN identifier does not replace h3. No failed proof or unsupported binding may trigger an automatic downgrade. A peer that has not selected TTTPS uses its ordinary transport or HTTP error handling, rather than issuing a TTTPS admission result. Jorgen Expires 3 April 2027 [Page 17] Internet-Draft TTTPS September 2026 7. Clock Substrate Interface A deployment MUST provide the Issuer with a timestamp and an uncertainty bound in the units and time scale declared by the active context. The source, calibration state, age, and uncertainty bound MUST be retained as evidence. This document does not require a particular hardware clock, cloud provider, kernel interface, polling interval, or storage system. An implementation MAY use a pre-published clock sample for event sealing. If it does so, the sample age and accumulated uncertainty MUST be included in dispersion. A fixed-record implementation MAY implement the hot path with bounded constant work and no per-event allocation; this is an implementation property under fixed resource limits, not a guarantee about the clock substrate or the network. 8. Tier Structure The core protocol does not assign fixed freshness intervals to tier identifiers. A deployment MAY define tier identifiers for different operating policies. The authenticated context manifest MUST bind each identifier to a time scale, tier_window_us, max_clock_skew_us, and max_hold_window. The default future-skew limit is 500,000 microseconds; an override requires authenticated policy. For the core comparison in Section 2.5, now and ts are TAI microseconds, and tier_window_us, max_clock_skew_us, and dispersion are integer microseconds. A policy expressed in another unit MUST be converted explicitly before this comparison. The verifier MUST reject an arithmetic overflow and MUST NOT infer a tier from packet timing. Any max_hold_window used with core epochs is also in microseconds. A verifier MUST reject or return UNVERIFIABLE when the selected tier is absent, expired, or not authenticated by the active manifest. This section defines no fee, latency, or performance target. 9. Security Considerations 9.1. Compromised Time Sources and Path Attacks An Issuer may receive faulty source measurements or delayed and replayed responses from a compromised network path. Source authentication, freshness, and a declared independent-source policy are therefore required before timestamp synthesis. Jorgen Expires 3 April 2027 [Page 18] Internet-Draft TTTPS September 2026 For scalar observations, if fewer than half of the admitted sources are Byzantine and all honest values lie in the honest interval, their median lies in the honest interval. This bound does not state a 1/k attenuation factor, prove the physical correctness of the honest interval, or establish independence from source labels alone. A dispersion threshold can detect disagreement exceeding its configured bound; it cannot detect a shared bias that moves the sources together. NTS [NTS] can authenticate responses from supporting sources. Issuers SHOULD use authenticated, administratively distinct sources and MUST apply the declared provenance policy before counting them toward the required source population. Source diversity can include a national metrology laboratory, a GNSS- disciplined source, and an NTS-authenticated source. Sources from a single autonomous system MUST NOT be counted as independent. Administrative separation alone does not establish independence of the underlying clock, detector, or ephemeris. The declared provenance policy identifies shared dependencies before counting sources. Roughtime [I-D.ietf-ntp-roughtime] is related authenticated time work; its source evidence does not replace the TTTPS record, replay ledger, or application admission policy. 9.2. Replay Prevention Verifiers MUST maintain a replay ledger keyed by (ctx_id, nonce) across the authenticated acceptance window, including dispersion. Before issuer-key resolution, signature verification, or TLS exporter-proof verification, verifiers MUST perform a bounded, read- only lookup for the pair. An already consumed pair MUST be rejected before those cryptographic operations. A cache miss does not authenticate the request and MUST NOT insert or reserve the pair; this prevents an attacker from preempting a legitimate Holder with a forged record. The post-validation atomic claim remains mandatory to resolve concurrent first-use requests. The state-changing claim occurs only after all required checks and policy evaluation permit ACCEPT. Claim and application mutation MUST share one transaction where possible. Otherwise use a durable idempotency record and recovery rule so a crash cannot repeat an application transition. Concurrent verifiers MUST allow at most one claim. Expiry MUST NOT permit reuse within the record's valid window. Session binding does not replace this replay ledger. Jorgen Expires 3 April 2027 [Page 19] Internet-Draft TTTPS September 2026 9.3. Sybil Time Sources and Unique Quorum A valid signature or a fresh key does not establish a new independent physical source. Before constructing the agreement distribution, density operator, or robust aggregate, the verifier MUST validate D-chain freshness and map each stable_node_id to an authority-bound PhysicalEntity and provenance group. Duplicate labels for one physical entity count zero after the first admitted vote. The effective quorum is N_eff = | union over i in Roster PhysicalEntity(stable_node_id_i) |. Quorum and Byzantine aggregation MUST use N_eff rather than raw label or key count. The f < N_eff/2 condition MUST be checked before applying a Byzantine median. If the condition fails, the verifier MUST enter HOLD_AHE or InsufficientKnowledge and MUST NOT fabricate a quorum. This defense is bounded by the declared identity and provenance authority. It provides no universal guarantee against an attacker that can forge or compromise that authority. 9.4. Side-Channel Considerations Integrity-tag verification and Ed25519 verification MUST be implemented in constant time. Variable-time implementations risk timing side-channel attacks against secret key material. The nonce MUST be generated with a constant-time CSPRNG. 9.5. Resource and Ordering Attacks An attacker may submit stale, reordered, or high-rate records to consume verifier resources. A TTTPS verifier MUST complete the required integrity, freshness, replay, Issuer, and Holder checks before application state mutation. Queue limits and admission quotas are deployment controls. XDP/eBPF ingress filtering is an optional L4 deployment mitigation before the TTTPS parser. It imposes no requirement on a TTTPS implementation. An L4 filter cannot inspect TLS-encrypted agent context or 180-octet PoT fields. Source-IP buckets classify packets; they are not authenticated principals, independent peers, or quorum units. Jorgen Expires 3 April 2027 [Page 20] Internet-Draft TTTPS September 2026 L4 packet-source Shannon entropy is an unauthenticated traffic distribution heuristic. A conforming verifier implementing the Confidence profile MUST NOT use it in place of a G-Score, aligned von Neumann analysis, Epi-state entropy, or an authenticated evidence snapshot. The verifier MUST NOT use L4 metrics to select a TTTPS profile, change core verification, or drive Confidence AdaptiveSwitch or PolicyEvaluator decisions. Those decisions consume current, authenticated, generation-bound profile evidence. Packets dropped by an ingress filter, including XDP_DROP, do not reach the TTTPS parser. A verifier MUST NOT create a TTTPS disposition, reason code, or verification receipt for such a drop. Network telemetry may record it separately. A missing packet or peer response alone does not establish a signature failure. When packet loss or partition leaves an otherwise recoverable peer population below required quorum, the profile returns HOLD. UNVERIFIABLE is reserved for required evidence or authority that cannot be established from available inputs. 9.6. Delay-Based Temporal Attacks [NTS] Section 8.6 identifies delay attacks as a primary threat to time synchronisation security. TTTPS addresses this through two complementary gates, applied in sequence (Section 2.5): (1) Integrity-tag gate: a PoT generated under context ctx_id cannot be presented in a different context ctx_id' without the integrity check failing, because ctx_id is part of the protected octets (Section 4.1). This is analogous to the cookie freshness mechanism of [NTS] Section 5.4. (2) AdaptiveSwitch freshness gate (Section 5.3): a PoT submitted outside the tier freshness window is rejected regardless of cryptographic validity, and FULL mode is triggered immediately. FILO+Integrity processing discipline: among records that pass both gates, the most recent qualifying submission is processed first. A delayed record outside the freshness window is rejected. Queue limits and backoff are deployment policy and do not establish an economic guarantee. The full flow is diagrammed in Appendix D. Jorgen Expires 3 April 2027 [Page 21] Internet-Draft TTTPS September 2026 9.7. Integrity Algorithm Security The core SHA-256 algorithm has no correction capability and its security depends on its standard cryptographic assumptions. Optional GRG security and correction properties are profile-specific and MUST NOT be inferred by a core verifier. The Confidence profile [CONFIDENCE] is the source for any GRG interface claims; this core makes no independent GRG security claim. Implementations MUST NOT expose internal algorithm state, shard values, or intermediate pipeline results through public APIs or error messages. 9.8. Path Manipulation An adversary controlling only network paths (not the Issuer's Ed25519 private key, nor holder key material) cannot produce a PoT that passes verification: context binding (Section 4.1) rejects cross- context replay, the freshness gate (Section 2.5, step 4) rejects path-induced delay beyond the tier window, and the TLS binding (Section 6.1) rejects cross-session replay because binding_proof requires holder key material the path attacker does not possess. This holds independent of the network-layer substrate the PoT traverses, including legacy signaling gateways; a detailed per- substrate scenario walkthrough is out of scope for this revision. 9.9. Trust Model and Key Compromise Resilience 9.9.1. Trust Hierarchy TTTPS defines a two-level trust hierarchy: Level 0 (L0) Certificate Authority: An L0 CA issues certificates to PoT Issuers. Verifiers trust L0 CA public keys, published in a transparency log. Level 1 (L1) PoT Issuer: An L1 Issuer holds an Ed25519 key pair certified by an L0 CA, identified on the wire by issuer_key_id (Section 2.2). The Issuer generates PoT Records (Section 2.4) and signs them with its private key. Verifier: Any party that receives a (binding_proof, PoT Record) pair and verifies it per Section 2.5. This model is analogous to TLS PKI: L0 CAs are root CAs, L1 Issuers are intermediate CAs, and verifiers are TLS clients. Jorgen Expires 3 April 2027 [Page 22] Internet-Draft TTTPS September 2026 9.9.2. Issuer Key Compromise Response If an Issuer signing key is compromised, the authority revokes the affected credential, issues a replacement key identifier, and preserves an append-only incident record. Verifiers MUST apply the configured revocation and key-validity policy. A valid signature from a compromised key alone cannot distinguish records created before and after compromise; that distinction requires independent, authenticated issuance or transparency evidence. A source median does not constrain an Issuer that controls signing unless the verifier also checks independently bound source evidence. 9.9.3. Untrusted Substrate Scope The preceding controls provide bounded guarantees only under their stated assumptions: valid issuer and holder key material, an authority-backed context, a configured freshness window, and the declared source and quorum bounds. They prevent a verifier from accepting a record that fails those checks. They do not guarantee the correctness of a compromised trust authority, an incorrect time source, or an application policy, and they do not provide a universal Byzantine or unlinkability guarantee. 10. Privacy Considerations 10.1. Unlinkability The random nonce prevents deterministic reuse of one nonce value under the assumed generator. It does not make records unlinkable: issuer_key_id, holder_auth_data, ctx_id, timing, and application metadata can correlate them. TLS exporter binding is session specific, but it does not erase identifiers carried in the record. Deployments requiring unlinkability need a separate privacy profile and a documented key and context rotation policy. 10.2. Minimal Disclosure The PoT Record wire format (Section 2.1) does not include participant identity or address, transaction content, or economic parameters or bid values beyond holder_auth_data, which identifies only the Holder's public key or a shared-secret digest, not a real-world identity. ctx_id is an opaque, application-assigned context identifier and a public, non-sensitive value; because it is an opaque string to the protocol, its semantics can be extended by application convention without any change to the wire format (Section 2) or the integrity binding (Section 4). Jorgen Expires 3 April 2027 [Page 23] Internet-Draft TTTPS September 2026 11. IANA Considerations IANA provision is the stage described by this revision. The identifiers below document the draft's provision-stage configuration; they are not a formal registration request. This document does not assert that IANA has registered, reserved, or assigned these values. Media type: application/tttps Binary carriage of one 180-octet PoT v2 record followed by a 64-octet Ed25519 or 32-octet HMAC holder proof; see Section 6.3. The media-type procedures are described in [RFC6838]. TLS exporter label: EXPORTER-TTTPS-v2-Binding TLS 1.3 holder binding with a 32-octet context and 32-octet exporter output; see Section 6.1. The applicable registry is TLS Exporter Labels, maintained under [RFC9847]. ALPN identifier: tttps/1 The seven ASCII octets 0x74 0x74 0x74 0x70 0x73 0x2f 0x31, for direct TTTPS application carriage; see Section 6.4 and [RFC7301]. HTTP/3 carriage continues to use h3. Provision-stage use requires explicit endpoint configuration and agreement on the draft-12 binding revision. A matching identifier does not replace issuer, holder, freshness, context, or replay checks. No HTTP/3 frame type or new integrity algorithm identifier is provisioned by this revision. 12. Intellectual Property The core SHA-256 integrity mode is completely specified in Appendix B.1, and the optional GRG profile is not required for conformance. GRG is maintained independently in the Confidence track [CONFIDENCE]. IPR matters are handled only through the IETF disclosure process specified by BCP 79 [RFC8179]; this document makes no determination about the validity or scope of any IPR claim. 13. Implementation Status This section records the status of known implementations of TTTPS at the time of posting, per [RFC7942]. 13.1. Reference Implementation The implementation evidence below identifies its source revision and measured boundary, following [RFC7942]. Jorgen Expires 3 April 2027 [Page 24] Internet-Draft TTTPS September 2026 OpenTTT-MCP: @helm-protocol/ttt-mcp@0.4.7, source revision e60bae0686a232cc1593e04a70f8f70ff4d7ce5c, published Node.js/ TypeScript implementation. Its 180-octet record functions and draft-11 TLS binding were exercised locally. The draft-12 reference harness separately implements the revised transcript and dual windows. See Section 13.3 for commands, artifacts, and measured results. OpenTTT server: operator-identified revision 1a4c058. The preserved evidence does not include a complete revision-bound core-conformance run for that server. Its deployment identity is distinct from the published MCP source and the executable reference harness. Reference artifacts: reference.cjs, test_contract.cjs, tls_test.cjs, and check_admission.py accompany this revision's verification bundle. They provide executable protocol fixtures rather than a production deployment or an independent external reproduction. Optional GRG implementation evidence belongs to its independently selected integrity profile. Core interoperability uses the fully specified SHA-256 mode in Appendix B. 13.2. Deployment Evidence Optional XDP/eBPF ingress mitigation is operational deployment evidence. Source inspection of openttt-mcp revision e60bae0 identified C/Python code, a generic-XDP loader, systemd units, TCP ports 8443 and 8090, source-IP buckets, and the XDP_DROP path. Mocked BPF-map tests exercised packet-controller policies and update arguments. Operators identified canary revisions c5f7bda and 3571664 and generic XDP on ens4. Kernel flood-load performance is outside these measurements. A preserved HTTP canary run on 30 September 2026 sent ten sequential requests: one authorized action changed the canary DB, while nine replay, argument-substitution, record-mutation, truncated-record, or missing-record requests returned HTTP 403 with equal before/after DB hashes. live-results.json and live-manifest.json retain this run. The interactive HTTP canary publishes a one-use test capability for an unchanged action. Its first use may execute that action; consumption prevents subsequent reuse. It evaluates argument binding and replay, while holder possession and session separation are evaluated in the distinct TLS harness. A canary capability is not a claim of private holder authentication. Local source-snapshot tests preserve both first-use and subsequent-use observations in the verification bundle. Jorgen Expires 3 April 2027 [Page 25] Internet-Draft TTTPS September 2026 The participant QR image is 700 by 700 pixels. zxing-cpp decoded its URL as the canary's /go path. QR decoding verifies the encoded link. Neither this functional demonstration nor the bounded request cohort is a distributed flood-load or general availability measurement. 13.3. Formal Verification Artifacts Verification uses separately identified model, reference, and published-implementation cohorts. Results apply to their declared inputs and execution boundaries. The AdaptiveSwitch.tla module and separate AdaptiveSwitch.cfg in Appendix A were checked with TLC2 2.19, revision 5a47802. The preserved run generated 2017 states, found 56 distinct states, and completed at depth 7 with no errors. TypeInvariant, NoForcedTurbo, DelayTriggersFull, and FailureExcludesTurbo held in that finite configuration. The revised dual-window admission explorer checked two requests sharing one (ctx_id, nonce) over 22 ingress cases. It explored 18,052 states and 35,644 transitions to depth 22. All nine gate invariants and all 22 expected single-request dispositions held. Appendix A specifies the predicate abstraction and executable source identity. The executable draft-12 reference passed 28 numerical, synthesis, and framing checks, including future-skew equality and exceedance, past freshness equality and exceedance, uint64 overflow, sampled lower- median selection, source-domain fixture checks, issuance bounds, and both fixed holder frame lengths. These are reference fixtures; they do not measure physical independence of live clock sources or a live HTTP/3 stack. The draft-12 TLS harness established two actual local TLS 1.3 sessions with certificate and hostname verification. All 23 checks passed for the revised record-hash transcript, exporter agreement and session separation, Ed25519 and PSK holder proofs, cross-session token/proof reuse, missing or altered proof, context substitution, and dual-window boundaries. All 1,440 single-bit mutations of the 180-octet core were rejected. This is the revised executable reference, not a claim that the published npm package was updated. Jorgen Expires 3 April 2027 [Page 26] Internet-Draft TTTPS September 2026 A separate cohort tested the published 0.4.7 package's record helpers and legacy binding functions: 23 local TLS checks passed, with 1,440 single-bit core mutations rejected. That package uses the draft-11 transcript and symmetric freshness helper. Its passing cohort applies to that revision; it is not transferred to the changed draft-12 transport contract. Version compatibility is specified in Section 6.4. The bundle preserves source, results, input scope, and artifact hashes. Execute the reference with test_contract.cjs and tls_test.cjs; execute the admission model with python3 check_admission.py. These results establish bounded reproducibility, not production deployment or full profile conformance for uninspected components. 13.4. Interested Parties This subsection records organisations that have expressed interest in the deployment scenarios described in Section 1.6. Inclusion here does not constitute endorsement of any specific version of this draft. At the time of this revision, no interested-party statements have been received. Authors request that organisations wishing to be listed contact the authors directly; a non-binding expression of interest in the stated use cases is sufficient for inclusion. 14. Roadmap The following companion profiles are published in parallel with this revision and are cited informatively: * draft-helmprotocol-deepspace-02: propagation-aware OWLT, physical context, integer-preserving correction, sparse-peer handling, and conservative Epi-Entropy shadow qualification. * draft-helmprotocol-confidence-02: G-Score, correlation-aware von Neumann confidence, Epi-Entropy, AdaptiveSwitch, and InsufficientKnowledge semantics. * GRG-specific integrity mode extensions are maintained in the independent Confidence profile; the core remains vendor-neutral. Profile processing is optional. The companion drafts describe policy signals and propagation-aware context handling without changing the core wire record or its cryptographic integrity boundary. Jorgen Expires 3 April 2027 [Page 27] Internet-Draft TTTPS September 2026 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC7301] Friedl, S., "Transport Layer Security (TLS) Application- Layer Protocol Negotiation Extension", RFC 7301, July 2014, . [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, May 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [NTS] Franke, D., "Network Time Security for the Network Time Protocol", RFC 8915, September 2020, . [RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021, . [RFC9114] Bishop, M., "HTTP/3", RFC 9114, June 2022, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, July 2026, . [RFC9999] Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig, "Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)", RFC 9999, July 2026, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013, . [RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 9847, December 2025, . Jorgen Expires 3 April 2027 [Page 28] Internet-Draft TTTPS September 2026 15.2. Informative References [CONFIDENCE] Jorgen, H., "Oracle Confidence Gating: G-Score, Correlation-Aware von Neumann Confidence, and AdaptiveSwitch", Work in Progress, draft-helmprotocol-confidence-02, September 2026. [DEEPSPACE] Jorgen, H., "TTTPS Deep-space Profile: Propagation-Aware Time Attestation", Work in Progress, draft-helmprotocol-deepspace-02, September 2026. [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, July 2016, . [I-D.ietf-ntp-roughtime] Ladd, W. and M. Dansarie, "Roughtime", Work in Progress (draft-19). RFC Editor Queue; intended status Experimental (status verified on the IETF Datatracker, June 2026), Work in Progress, Internet-Draft, draft-ietf-ntp-roughtime-19, 2026, . Appendix A. AdaptiveSwitch State Contract This appendix includes an executable finite-state TLA+ model for the AdaptiveSwitch transition. DwellRequired counts consecutive admitted observations, not elapsed seconds. The model assumes the observation has already passed authentication; parser, TLS, replay, and application commit are outside its boundary. Complete module file: AdaptiveSwitch.tla ---- MODULE AdaptiveSwitch ---- EXTENDS Naturals, FiniteSets CONSTANTS NodeId, RateSet, FailureSet, DelaySet, EntryThreshold, MaintainThreshold, TierToleranceUs, DwellRequired ASSUME /\ IsFiniteSet(NodeId) /\ NodeId # {} /\ RateSet \subseteq 0..100 /\ FailureSet \subseteq Nat /\ DelaySet \subseteq Nat /\ EntryThreshold \in 0..100 /\ MaintainThreshold \in 0..EntryThreshold /\ TierToleranceUs \in Nat /\ DwellRequired \in Nat /\ DwellRequired > 0 Modes == {"TURBO", "FULL"} VARIABLES mode, match_rate, fail_count, delay_us, dwell vars == <> Jorgen Expires 3 April 2027 [Page 29] Internet-Draft TTTPS September 2026 TypeInvariant == /\ mode \in [NodeId -> Modes] /\ match_rate \in [NodeId -> RateSet] /\ fail_count \in [NodeId -> FailureSet] /\ delay_us \in [NodeId -> DelaySet] /\ dwell \in [NodeId -> 0..DwellRequired] Unsafe(mr, fc, sd) == \/ mr < MaintainThreshold \/ fc > 0 \/ sd > TierToleranceUs Good(mr, fc, sd) == /\ mr >= EntryThreshold /\ fc = 0 /\ sd <= TierToleranceUs Init == /\ mode = [n \in NodeId |-> "FULL"] /\ match_rate = [n \in NodeId |-> 0] /\ fail_count = [n \in NodeId |-> 0] /\ delay_us = [n \in NodeId |-> 0] /\ dwell = [n \in NodeId |-> 0] Observe(n, mr, fc, sd) == /\ n \in NodeId /\ mr \in RateSet /\ fc \in FailureSet /\ sd \in DelaySet /\ LET d == IF Good(mr, fc, sd) THEN IF dwell[n] < DwellRequired THEN dwell[n] + 1 ELSE DwellRequired ELSE 0 IN /\ mode' = [mode EXCEPT ![n] = IF Unsafe(mr, fc, sd) THEN "FULL" ELSE IF mode[n] = "FULL" /\ d >= DwellRequired THEN "TURBO" ELSE mode[n]] /\ match_rate' = [match_rate EXCEPT ![n] = mr] /\ fail_count' = [fail_count EXCEPT ![n] = fc] /\ delay_us' = [delay_us EXCEPT ![n] = sd] /\ dwell' = [dwell EXCEPT ![n] = d] Next == \E n \in NodeId : \E mr \in RateSet, fc \in FailureSet, sd \in DelaySet : Observe(n, mr, fc, sd) Spec == Init /\ [][Next]_vars NoForcedTurbo == \A n \in NodeId : mode[n] = "TURBO" => /\ match_rate[n] >= MaintainThreshold /\ fail_count[n] = 0 /\ delay_us[n] <= TierToleranceUs DelayTriggersFull == \A n \in NodeId : delay_us[n] > TierToleranceUs => mode[n] = "FULL" FailureExcludesTurbo == \A n \in NodeId : fail_count[n] > 0 => mode[n] = "FULL" ==== Jorgen Expires 3 April 2027 [Page 30] Internet-Draft TTTPS September 2026 Separate file: AdaptiveSwitch.cfg. This TLC configuration is not part of the preceding AdaptiveSwitch.tla module. CONSTANTS NodeId = {n1} RateSet = {0, 84, 85, 94, 95, 100} FailureSet = {0, 1} DelaySet = {0, 100000, 100001} EntryThreshold = 95 MaintainThreshold = 85 TierToleranceUs = 100000 DwellRequired = 3 SPECIFICATION Spec INVARIANT TypeInvariant INVARIANT NoForcedTurbo INVARIANT DelayTriggersFull INVARIANT FailureExcludesTurbo Execute the two files together using: java -cp tla2tools.jar tlc2.TLC -workers 1 -config AdaptiveSwitch.cfg AdaptiveSwitch.tla With TLC2 2.19 (revision 5a47802), this configuration generated 2017 states and 56 distinct states, with search depth 7 and zero remaining states. All four listed invariants passed. This result covers the exact finite configuration shown above. Wire-admission obligations are separate from AdaptiveSwitch. A core parser-and-gate model MUST include the following properties: * BoundedParse: parsing requires exactly 180 record octets plus the selected external proof length; the parser uses fixed field bounds and performs no input-sized loop over the received frame. * InvalidIngressNoMutation: failure of integrity, freshness, replay, issuer trust, or holder binding leaves application state and its commit marker unchanged. * ValidIngressMayCommit: application state mutation is enabled only after all required core predicates and admission policy succeed. These are core verification obligations. The AdaptiveSwitch TLC result above establishes the four mode invariants for its stated finite configuration, rather than a parser-and-gate proof. Jorgen Expires 3 April 2027 [Page 31] Internet-Draft TTTPS September 2026 A separate exhaustive admission exploration uses two once-submitted requests sharing one (ctx_id, nonce), and 22 declared ingress cases. The revised freshness predicate implements the distinct future-skew and past-delay windows in Section 2.5. Cases cover holder frame lengths, failed core predicates, uint64 boundaries, policy outcomes, and an L4 drop. Cryptographic outcomes are predicate inputs. The explorer visited 18,052 states and 35,644 transitions to depth 22. Nine invariants held: BoundedParse, InvalidIngressNoMutation, ValidIngressMayCommit, DropHasNoDisposition, ReceiptAfterCommit, NonAcceptNoMutation, GateOrder, AtomicReplayAtMostOneCommit, and CommitRequiresReplayClaim. All 22 single-request dispositions matched. A consumed replay key was rejected before issuer checks. A sensitivity experiment disabled the final atomic replay recheck. Its 23-state trace contained two application commits for the shared replay key, demonstrating why a read-only precheck is insufficient. The normative path retains the final claim and one-commit invariant. Execute the preserved revised source: python3 check_admission.py Source SHA-256: 43282bf256ecd440470f62ccd98e628e5399dc375efbd8bafc4daff129376d28 Appendix B. Integrity Algorithm Interface and SHA-256 This appendix specifies the core SHA-256 integrity algorithm. Optional profile algorithms are not defined by this appendix; the GRG profile is maintained in the independent Confidence track [CONFIDENCE]. B.1. alg_id 0x0001 -- SHA-256 (Mandatory-to-Implement) This algorithm is specified here and MUST be implemented by all conformant core implementations. integrity_tag = SHA-256(pot_record[0:80]) where pot_record[0:80] denotes octets 0 through 79 of the PoT Record (version through holder_auth_data, Section 2.1). Because the integrity_tag field is exactly 32 octets, the full SHA-256 output is used with no truncation. Verification: the verifier recomputes SHA-256(pot_record[0:80]) and compares it against integrity_tag. A match yields the *intact* verdict; a mismatch yields *unresolvable* (this algorithm has no Jorgen Expires 3 April 2027 [Page 32] Internet-Draft TTTPS September 2026 correction capability, so the *resolved* verdict of Section 2.5 never applies to it). The security of this check depends on the standard preimage and collision-resistance assumptions for SHA-256; this document does not assign a deployment probability to an undetected modification. B.2. Optional GRG Profile The optional GRG integrity profile is specified in the independent Confidence track [CONFIDENCE]. The core document intentionally does not reproduce its stage construction, parameters, correction claims, or implementation requirements. A core implementation remains conformant without GRG. B.3. Future Algorithm Extensions This revision does not allocate additional alg_id values. A future Working Group revision may define an allocation procedure after review. Any future specification MUST state the computation of integrity_tag, the detection and correction properties under stated assumptions, and the implementation status of the algorithm. Appendix C. Test Vectors Test vectors for the core PoT generation and verification are provided as property-based tests. Optional profile test vectors belong to their respective profile documents. Required properties (all MUST pass): C.1 Core integrity verification: Verify(Generate(P, ctx), ctx) = intact for the SHA-256 profile. C.2 Nonce and replay tests: Generation uses a 128-bit CSPRNG. A consumed (ctx_id, nonce) pair MUST be rejected before signature verification. Concurrent valid first-use requests for one pair MUST cause at most one committed application transition. A finite sample with no nonce collision does not prove global uniqueness. C.3 Context separation: integrity_tag(P, ctx_A) != integrity_tag(P, ctx_B) for ctx_A != ctx_B, subject to the collision-resistance assumptions of the selected integrity algorithm. C.4 Verification correctness: Verify(Generate(P, ctx), ctx) = intact. C.5 Tamper rejection: For a valid SHA-256-profile record, flip each record bit individually without recomputing its integrity tag or signature. Every modified record MUST be rejected by the complete Jorgen Expires 3 April 2027 [Page 33] Internet-Draft TTTPS September 2026 verifier. Bytes 0-111 are covered by the integrity-tag check; issuer-key and signature-field changes require the later issuer verification steps. The test does not attribute every record mutation to the integrity-tag gate alone. C.6 Dual-window rejection: A future timestamp 500,001 microseconds ahead MUST be rejected under the default skew policy, regardless of dispersion. A past delay one microsecond above tier_window_us + dispersion MUST be rejected and enter FULL. Equality passes each time check. An overflowing past bound MUST be rejected before addition. C.7 Integrity-first ordering: Integrity-tag verification (Section 2.5, step 3) MUST complete, and MUST yield unresolvable on failure, before issuer_sig or binding_proof are attempted (verified using call counters or instrumentation). An implementation test suite may instantiate these properties for the 180-octet record. The reference implementation status and test count are maintained separately from this protocol specification; this test-vector section does not claim conformance from an unreported test run. Appendix D. FILO+Integrity Delay Rejection Flow This appendix restates the integrity-first and dual-window checks in Section 2.5. now and ts use the same TAI microsecond scale. GATE 1: Check the bounded record integrity field. An UNRESOLVABLE result is rejected before issuer or holder-proof verification. GATE 2: If ts > now, subtract now from ts and compare the result with max_clock_skew_us. Reject a value above that limit. Dispersion does not extend this future-skew limit. Otherwise subtract ts from now. Before forming the past bound, reject if tier_window_us > UINT64_MAX - dispersion. Reject a delay above tier_window_us + dispersion and enter FULL. Equality passes either window. Wrapped arithmetic MUST NOT determine the result. FILO QUEUE: A deployment enabling this policy processes qualifying records in descending PoT.ts order. Queue bounds and backoff are deployment policy. The queue cannot change either window or permit a rejected record to proceed to issuer or holder verification. Author's Address Jorgen Expires 3 April 2027 [Page 34] Internet-Draft TTTPS September 2026 Heime Jorgen Kenosian Email: heime.jorgen@proton.me Jorgen Expires 3 April 2027 [Page 35]