The TLS TimeToken Secure Protocol (TTTPS)
draft-helmprotocol-tttps-11
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | 장동호 | ||
| Last updated | 2026-09-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | Experimental | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-helmprotocol-tttps-11
Network Working Group H. Jorgen
Internet-Draft Kenosian
Intended status: Experimental 22 September 2026
Expires: 21 February 2027
The TLS TimeToken Secure Protocol (TTTPS)
draft-helmprotocol-tttps-11
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.
Discussion Note
This document is prepared for discussion in the AUDIT BOF and related
IETF venues. Comments should be directed through the venue selected by
the responsible IETF process.
Changes from -10:
* Clarified the 180-octet v2 layout and removed the overlapping
reserved field.
* Added issuer trust-anchor and certificate resolution before issuer
signature verification.
* Kept confidence and propagation processing outside the core wire and
cryptographic verification path.
* Clarified the separate TLS exporter binding proof and the scope of
the bounded single-record processing claim.
* Limited this revision to the core protocol; profile mathematics and
physical-context algorithms belong in companion drafts.
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/.
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 21 February 2027.
Jorgen Expires 21 February 2027 [Page 3]
Internet-Draft TTTPS September 2026
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.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Motivation . . . . . . . . . . . . . . . 7
1.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6.1. Financial Infrastructure Timestamping . . . . . . . . 11
1.6.2. AI Agent Networks . . . . . . . . . . . . . . . . . . 11
1.6.3. Operational Requirements Summary . . . . . . . . . . 11
1.7. Problem Statement . . . . . . . . . . . . . . . . . . . . 12
2. Proof-of-Time Structure . . . . . . . . . . . . . . . . . . . 14
2.1. PoT Record v2 Wire Format . . . . . . . . . . . . . . . . 14
2.2. Field Definitions . . . . . . . . . . . . . . . . . . . . 15
2.3. Holder Authentication Types . . . . . . . . . . . . . . . 17
2.4. Generation Algorithm . . . . . . . . . . . . . . . . . . 17
2.5. Verification Procedure . . . . . . . . . . . . . . . . . 18
2.6. JOSE and COSE Data Representations . . . . . . . . . . . 19
2.6.1. COSE / CBOR Data Model (CWT Mapping) . . . . . . . . 19
2.6.2. JOSE / JSON Data Model (JWS Mapping) . . . . . . . . 19
3. Gap Analysis vs Existing Timestamping Standards . . . . . . . 20
4. Integrity Algorithm Interface . . . . . . . . . . . . . . . . 21
4.1. Abstract Interface . . . . . . . . . . . . . . . . . . . 21
4.2. Optional Integrity Profiles . . . . . . . . . . . . . . .
22
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.
5.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Transition Conditions and Hysteresis . . . . . . . . . . 22
5.3. Penalty and Exponential Backoff . . . . . . . . . . . . . 23
5.4. Policy Thresholds
5.5. External Policy and Profile Inputs
5.6. GRG Physical Framing Boundary
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).
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
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.
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
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 = median(T_1, ..., T_k), k >= 3 sources
from independent administrative domains. TAI microseconds since
the TAI epoch. 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.
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 of this record. Detection and correction
semantics
are defined by the selected algorithm profile; the core SHA-256
path
is detection-only.
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 Integrity Property: the Issuer cannot forge a timestamp
without detection. A forged ts' != ts produces a different
integrity_tag', and issuer_sig over the changed record then fails
verification against the published Issuer public key. This is a
mathematical consequence of EUF-CMA security, not a procedural
control. The remaining trust assumption is that the Issuer's private
key is not compromised; this is the same trust model as PKI
(Certificate Authority), applied to time rather than identity.
Issuer misbehaviour is auditable via an append-only commitment log of
published PoT records.
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.
2.4. Generation Algorithm
1. Query k >= 3 time sources from independent administrative
domains.
2. Compute ts = median(T_1, ..., T_k), in TAI microseconds.
3. Compute dispersion = max|T_i - ts|.
4. If dispersion > stratum_tolerance: ABORT.
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
Implementations MUST verify a received (binding_proof, PoT Record)
pair in the following order. Reordering this sequence, in particular
performing step 3 later, reintroduces the -06 binding weakness
described in the Discussion Note.
1. Frame length check: the received frame MUST equal
len(binding_proof) + 180 octets, where len(binding_proof) is 64
(holder_auth_type 0x01) or 32 (holder_auth_type 0x02); otherwise
REJECT.
2. Support check: version, alg_id, and holder_auth_type MUST all be
values the verifier supports; otherwise REJECT.
3. Integrity-tag interpretation (single fixed-cost pass): apply the
algorithm profile identified by alg_id to octets 0-79 and compare
against integrity_tag. The result is *intact*, *resolved* only
when the selected profile defines bounded correction and confirms
recovery, or *unresolvable* (REJECT immediately). This check MUST
be performed before freshness, replay, certificate resolution,
signature, or holder-binding checks.
4. Freshness: if |now - ts| > tier_window + dispersion: REJECT.
Trigger FULL mode per Section 5.3.
5. Anti-replay: if the (ctx_id, nonce) pair has been seen before
within the freshness window: REJECT.
6. Issuer trust resolution: resolve issuer_key_id through an
authenticated out-of-band trust bundle or an authenticated
in-band certificate or SVID exchange. The verifier MUST validate
the chain, key usage, validity interval, and configured revocation
or status policy. issuer_key_id is only a selector and MUST NOT
be treated as an unauthenticated trust anchor. Failure yields
UNVERIFIABLE or REJECT according to the trust policy.
7. issuer_sig verification: verify the Ed25519 signature over octets
0-115 against the resolved Issuer public key; otherwise REJECT.
8. binding_proof verification: recompute the expected binding_input
from the live TLS-Exporter output (Section 6.1) and verify
binding_proof against holder_auth_data per holder_auth_type;
otherwise REJECT.
9. Accept.
NOTE: performing integrity-tag interpretation first (step 3) gives
early, fixed-cost rejection of corrupted or foreign-context
submissions before the more expensive signature and binding-proof
checks are attempted.
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 [I-D.ietf-rats-msg-wrap]), 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
(core/profile-defined) |
| 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:
{
"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.
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.
5. AdaptiveSwitch
5.1. State Machine
AdaptiveSwitch maintains per-node state in {TURBO, FULL}. A node
enters TURBO only after the configured promotion conditions are met.
A node leaves TURBO on an integrity failure, a freshness failure, or a
confidence result below the configured maintenance threshold.
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].
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
TTTPS uses the TLS Exporter mechanism [RFC5705] to derive binding
material from an established TLS 1.3 session, following the model of
[NTS] Section 5.1. This requires NO new TLS Extension Type
codepoint and is fully backward-compatible with existing TLS 1.3
implementations.
Jorgen Expires 21 February 2027 [Page 24]
Internet-Draft TTTPS September 2026
Binding computation (normative), performed by both Holder and
verifier:
record_hash = SHA-256(pot_record) [all 180 octets]
context_value = SHA-256("tttps-binding-v2" || 0x00 ||
record_hash || ctx_id || nonce)
exporter_output = TLS-Exporter("EXPORTER-TTTPS-v2-Binding",
context_value, 32)
binding_input = "tttps-binding-v2" || 0x00 || exporter_output ||
ctx_id || nonce
binding_proof is then computed by the Holder according to
holder_auth_type (Section 2.3):
0x01: binding_proof = Ed25519.Sign(holder_sk, binding_input) (64
octets)
0x02: binding_proof = HMAC-SHA256(k_h, binding_input) (32
octets)
exporter_output MUST NOT be transmitted; only binding_proof and the
PoT Record are sent. Because exporter_output is derived from the TLS
session's master secret [RFC5705] Section 4, a PoT captured from
session A cannot be replayed into session B: recomputing
binding_input in session B yields a different value, and
binding_proof over session A's binding_input fails verification.
Because binding_proof additionally requires holder key material the
session alone does not provide, a party present in the session but
not in possession of holder_sk or k_h cannot produce a valid
binding_proof even for its own session -- the defect this revision
corrects (Discussion Note).
PoT Frame format:
holder_auth_type 0x01: pot_record(180) || binding_proof(64) = 244B
holder_auth_type 0x02: pot_record(180) || binding_proof(32) = 212B
The verifier's procedure is given in Section 2.5.
6.2. QUIC Integration
TTTPS operates over QUIC [RFC9000] post-handshake. The TLS Exporter
is available after QUIC handshake completion.
Jorgen Expires 21 February 2027 [Page 25]
Internet-Draft TTTPS September 2026
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.
6.3. HTTP/3 Frame Type
Over HTTP/3 [RFC9114], PoT records are conveyed in a dedicated HTTP/3
frame type.
Frame Type: deployment-specific value; this revision requests no IANA
allocation
Frame Length: variable (244 octets with a type-0x01
binding_proof, 212 octets with type-0x02)
Frame Body: PoT Record || binding_proof (Section 2.1)
PoT frames MAY appear in any HTTP/3 request or response stream.
Servers MUST NOT reject requests solely on the basis of absent PoT
frames (backward compatibility).
6.4. Backward Compatibility
Servers that do not implement TTTPS MUST be able to process TLS 1.3,
QUIC, and HTTP/3 connections that include TTTPS binding material.
TTTPS MUST NOT modify the TLS handshake in a way that causes
negotiation failure with non-TTTPS peers.
Implementations SHOULD use ALPN [RFC7301] extension identifier
"tttps/1" or another deployment-specific identifier; this revision
does not request IANA allocation to negotiate TTTPS
capability between peers. The ALPN identifier negotiates TTTPS
capability at the transport layer; it is not tied to the PoT Record
version, which is negotiated separately via the version field
(Section 2.2).
Jorgen Expires 21 February 2027 [Page 26]
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, but the active context manifest MUST bind each
identifier to a time scale, an interval, a tier_window, and a
max_hold_window. These values are policy inputs and are not inferred
from the record or from the transport.
A verifier MUST reject or return UNVERIFIABLE when the selected tier is
absent, expired, or not authenticated by the active context manifest.
The freshness decision in Section 2.5 uses the authenticated
tier_window and dispersion. This section defines no fee, latency, or
performance target.
9. Security Considerations
9.1. Compromised Time Sources and Path Attacks
This section addresses two threat models: compromised time sources
and compromised network paths between the PoT Issuer and its sources
(the standard IETF network adversary model).
Compromised source: a single compromised time source biases the
synthesised timestamp by at most 1/k of the manipulation, where k >=
3 is the source count. For k=4 independent sources, single-source
bias impact <= 0.25 of manipulation magnitude.
Compromised network path: an attacker controlling the path between
the Issuer and one source can inject delayed or replayed responses.
Two mitigations apply: (a) multi-source median (ts = median(T_1, ...,
T_k), k >= 3, distinct administrative domains) -- a path-level
attacker must simultaneously compromise paths to a majority of
sources to bias the median; (b) the stratum tolerance check
(Section 2.4, step 4) -- a single-path delay injection that pushes
one source beyond tolerance is detected and rejected.
NTS [NTS] on the path between Issuer and sources provides an
additional layer of path authentication; implementations SHOULD use
NTS-authenticated sources where available. Implementations MUST use
sources from distinct administrative domains (e.g., a national
metrology laboratory, a GNSS-disciplined source, and an NTS-
authenticated source) to maximise independence. Sources from a
single autonomous system MUST NOT be counted as independent.
Jorgen Expires 21 February 2027 [Page 30]
Internet-Draft TTTPS September 2026
9.2. Replay Prevention
Each PoT Record includes a 128-bit cryptographically random nonce
(Section 2.2). Verifiers MUST maintain a nonce cache, keyed on
(ctx_id, nonce), for the duration of the tier freshness window.
Duplicate pairs MUST be rejected.
issuer_sig seals the nonce against Issuer-side forgery. Cross-
session replay is additionally prevented by the TLS binding of
Section 6.1.
_Implementations MUST perform the nonce-cache duplicate-check and the
nonce-cache insertion as a single atomic operation._ Split-phase
implementations (check-then-insert without atomicity) are subject to
a Time-of-Check to Time-of-Use (TOCTOU) race under concurrent request
load, permitting an attacker to replay a captured record N times by
issuing N concurrent verifications faster than the cache-insert phase
completes.
The reference implementation uses Redis with SET pot:{event_id} NX EX
<ttl>, which is atomic on the Redis server; equivalent atomic
primitives include PostgreSQL INSERT ... ON CONFLICT DO NOTHING
RETURNING, DynamoDB ConditionalPutItem, and in-process
std::collections::HashSet guarded by a std::sync::Mutex.
Empirical validation: a split-phase implementation deployed with 20
concurrent identical requests observed 20/20 duplicate acceptances
(100 percent TOCTOU exploitation success). After conversion to
atomic SET-NX, the same load produced 1 acceptance and 19 rejections,
matching the correct behaviour.
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.
Jorgen Expires 21 February 2027 [Page 31]
Internet-Draft TTTPS September 2026
9.5. Resource and Ordering Attacks
An attacker may submit stale, reordered, or high-rate records to
consume verifier resources or influence an application policy. The
verifier MUST apply the fixed-record integrity and freshness checks
before state mutation. Queue limits, admission quotas, and backoff
MAY be configured by the deployment. TTTPS does not claim that these
controls make an attack economically irrational or remove the need for
application-level rate limiting.
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.
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.
Jorgen Expires 21 February 2027 [Page 32]
Internet-Draft TTTPS September 2026
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 (analogous to
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 21 February 2027 [Page 33]
Internet-Draft TTTPS September 2026
9.9.2. Issuer Key Compromise Response
If an L1 Issuer's Ed25519 private key is compromised: (1) Key
rotation -- the L0 CA revokes the compromised certificate and issues
a new one under a new issuer_key_id (Section 2.2), which verifiers
use to select the correct public key without ambiguity. (2)
Transparency audit -- all PoTs generated by the compromised key are
logged with their timestamps; third parties can determine which PoTs
were generated before versus after the compromise window. (3) Source
independence -- the multi-source median (Section 2.4) provides an
independent check on Issuer-reported timestamps; even after key
compromise, the attacker cannot generate PoTs with timestamps outside
the source consensus window without also compromising k/2 sources.
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
PoT Records include a 128-bit random nonce (Section 2.2) that MUST be
freshly generated for each record. This prevents linkage of PoT
Records from the same Issuer across sessions. The TLS binding of
Section 6.1 ensures PoT Records are bound to specific TLS sessions
and cannot be used to correlate activity across sessions. Issuers
SHOULD NOT include in PoT Records any information beyond the fields
defined in Section 2.2 that could enable participant identification.
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
Jorgen Expires 21 February 2027 [Page 34]
Internet-Draft TTTPS September 2026
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).
11. IANA Considerations
This revision makes no IANA request. It is an individual draft
prepared for discussion and does not create registries, allocate
protocol identifiers, or claim provisional registration. A future
Working Group revision may request assignments for a TLS exporter
label, ALPN identifier, HTTP/3 frame type, or TTTPS parameters after
the wire semantics, allocation policy, and IPR disclosures have been
reviewed.
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
Name: OpenTTT
URL: https://github.com/Helm-Protocol/OpenTTT
Level: Partial (verifier SDK, QUIC transport)
The following implementation results were recorded before the v2
wire-format update and are not v2 conformance evidence.
Earlier tests covered the wire and external integrity interface.
AdaptiveSwitch model. QUIC/TLS binding, source-median synthesis, and
no_std verifier results are implementation evidence only.
Jorgen Expires 21 February 2027 [Page 37]
Internet-Draft TTTPS September 2026
Earlier implementation results were recorded before the v2
wire-format update and are not independently verified in this revision.
They are not v2 conformance evidence. Coverage of v2 will be recorded
only with the implementation revision, test harness, and measurement
method identified.
Private Issuer implementation:
Name: Helm grg-core (reported profile implementation)
Level: Not a core-conformance claim
Note: Any GRG implementation status belongs to the independent
Confidence profile and is not evidence of core TTTPS
conformance.
13.2. Deployment Evidence
No v2 deployment or flight-validation result is claimed in this
revision. Earlier implementation measurements, if cited by a
deployment, MUST identify the implementation revision, wire format,
test harness, collection interval, and measurement method. They are
not protocol requirements and are not evidence of universal latency or
attack resistance.
13.3. Formal Verification Artifacts
The TLA+ appendix contains the current AdaptiveSwitch model and records
the finite parameter set used for its bounded TLC check. That model
does not model the 180-octet parser, cryptographic verification,
certificate resolution, or application state mutation. This document
therefore makes no formal-verification claim for those components.
A future parser-and-gate model MAY specify the BoundedParse,
InvalidIngressNoMutation, and ValidIngressMayCommit obligations listed
in Appendix A. Any result for that model MUST identify the model, tool
version, configuration, and checked state space.
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-00: propagation-aware OWLT, physical
context, integer-preserving correction, sparse-peer handling, and
conservative Epi-Entropy shadow qualification.
* draft-helmprotocol-confidence-00: 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.
15. References
15.1. Normative References
Jorgen Expires 21 February 2027 [Page 39]
Internet-Draft TTTPS September 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010,
<https://www.rfc-editor.org/info/rfc5705>.
[RFC7301] Friedl, S., "Transport Layer Security (TLS) Application-
Layer Protocol Negotiation Extension", RFC 7301, July
2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights
in IETF Technology", BCP 79, RFC 8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[NTS] Franke, D., "Network Time Security for the Network Time
Protocol", RFC 8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>.
[RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", RFC 9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9114] Bishop, M., "HTTP/3", RFC 9114, June 2022,
<https://www.rfc-editor.org/info/rfc9114>.
15.2. Informative References
Jorgen Expires 21 February 2027 [Page 40]
Internet-Draft TTTPS September 2026
[CONFIDENCE] Jorgen, H., "Oracle Confidence Gating:
G-Score,
Correlation-Aware von Neumann Confidence, and
AdaptiveSwitch,"
Work in Progress, draft-helmprotocol-confidence-00,
September 2026,
<https://datatracker.ietf.org/doc/draft-helmprotocol-tttp
-confidence/>.
[DEEPSPACE] Jorgen, H., "TTTPS Deep-space Profile: Propagation-Aware
Time Attestation," Work in Progress,
draft-helmprotocol-deepspace-00, September 2026,
<https://datatracker.ietf.org/doc/draft-helmprotocol-deep
pace/>.
Jorgen Expires 21 February 2027 [Page 41]
Internet-Draft TTTPS September 2026
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[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, <https://datatracker.ietf.org/doc/html/draft-ietf-
ntp-roughtime-19>.
Jorgen Expires 21 February 2027 [Page 42]
Internet-Draft TTTPS September 2026
Appendix A. AdaptiveSwitch TLA+ Specification
The following TLA+ module specifies the AdaptiveSwitch state
machine. The
model was checked with TLC using the finite parameter set MaxNodes=3,
MaxBlocks=10, TierToleranceMs=100, TurboEntry=95, and
TurboMaintain=85. This check covers the model and parameter set shown
here; it is not a proof of all implementations or deployments.
The module specifies:
* TypeInvariant: all five state variables are well-typed.
* S1 (NoForcedTurbo): TURBO requires match_rate >= 85 AND fail_count
= 0 -- conjunction, not disjunction.
* S2 (DelayRejectionTriggersFull): submission outside tier tolerance
is incompatible with TURBO.
* S3 (FailureExcludesTurbo): any integrity failure forces FULL.
* L1 (EventualTurbo): a node with sustained good behaviour
eventually reaches TURBO (liveness under weak fairness).
EnvStep models nondeterministic updates to match_rate, fail_count, and
submission_delay. The stated invariants are checked for the bounded
model; deployment-specific assumptions remain outside this appendix.
The wire-admission obligations are separate from this AdaptiveSwitch
model. A core parser model MUST include the following properties before
a TLC result is claimed for them:
* BoundedParse: an input frame is accepted for parsing only when its
declared length is 180 octets plus the selected external proof; the
parser visits a fixed set of offsets and performs no input-sized loop.
* InvalidIngressNoMutation: if integrity, freshness, replay, issuer
trust, or holder binding fails, the application state and commit
marker are unchanged.
* ValidIngressMayCommit: an application state transition is enabled
only after all required core predicates have succeeded.
This revision does not claim that the AdaptiveSwitch TLC run checks
these parser obligations. They are included as the required scope of
the next combined parser-and-gate model.
---- MODULE AdaptiveSwitch ----
EXTENDS Naturals, FiniteSets
CONSTANTS MaxNodes, MaxBlocks, TurboEntry, TurboMaintain,
TierToleranceMs
ASSUME /\ TurboEntry = 95 \* 95% match_rate required for TURBO
/\ TurboMaintain = 85 \* 85% minimum to stay in TURBO
/\ TierToleranceMs > 0 \* positive tier tolerance (ms)
NodeId == 1..MaxNodes \* finite set of node identifiers
Modes == { "TURBO", "FULL" }
VARIABLES
node_mode, \* [NodeId -> Modes] per-node state
match_rate, \* [NodeId -> 0..100] ordering-match percentage
fail_count, \* [NodeId -> Nat] consecutive failures
block_count, \* Nat current block number
submission_delay \* [NodeId -> Nat] ms since last PoT gen
vars == <<node_mode, match_rate, fail_count,
block_count, submission_delay>>
\* -- Helpers ------------------------------------------------------
SubmittedOutsideTolerance(n) ==
submission_delay[n] > TierToleranceMs
\* -- Type correctness ---------------------------------------------
TypeInvariant ==
/\ node_mode \in [NodeId -> Modes]
/\ match_rate \in [NodeId -> 0..100]
/\ fail_count \in [NodeId -> Nat]
/\ block_count \in Nat
/\ submission_delay \in [NodeId -> Nat]
\* -- Initial state (all nodes start in FULL, zero counters) -------
Init ==
/\ node_mode = [n \in NodeId |-> "FULL"]
/\ match_rate = [n \in NodeId |-> 0]
/\ fail_count = [n \in NodeId |-> 0]
/\ block_count = 0
/\ submission_delay = [n \in NodeId |-> 0]
\* -- Actions ------------------------------------------------------
\* Promote n from FULL to TURBO when match_rate sufficient
\* and no pending failures.
PromoteToTurbo(n) ==
/\ node_mode[n] = "FULL"
/\ match_rate[n] >= TurboEntry
/\ fail_count[n] = 0
/\ ~SubmittedOutsideTolerance(n)
/\ node_mode' = [node_mode EXCEPT ![n] = "TURBO"]
/\ UNCHANGED <<match_rate, fail_count,
block_count, submission_delay>>
\* Demote n from TURBO to FULL on poor match_rate, integrity
\* failure, or submission outside tier tolerance.
DemoteToFull(n) ==
/\ node_mode[n] = "TURBO"
/\ \/ match_rate[n] < TurboMaintain
\/ fail_count[n] > 0
\/ SubmittedOutsideTolerance(n)
/\ node_mode' = [node_mode EXCEPT ![n] = "FULL"]
/\ UNCHANGED <<match_rate, fail_count,
block_count, submission_delay>>
\* Environment step: update match_rate / fail_count / delay
\* (models external inputs; unconstrained for model checking)
EnvStep(n, mr, fc, sd) ==
/\ match_rate' = [match_rate EXCEPT ![n] = mr]
/\ fail_count' = [fail_count EXCEPT ![n] = fc]
/\ submission_delay' = [submission_delay EXCEPT ![n] = sd]
/\ block_count' = block_count + 1
/\ UNCHANGED node_mode
Next ==
\E n \in NodeId :
\/ PromoteToTurbo(n)
\/ DemoteToFull(n)
\/ \E mr \in 0..100, fc \in 0..5,
sd \in 0..(TierToleranceMs+50) :
EnvStep(n, mr, fc, sd)
Spec == Init /\ [] (Next \/ UNCHANGED vars) /\ WF_vars(Next)
\* -- Safety invariants --------------------------------------------
\* S1: TURBO requires healthy match_rate AND no integrity failures.
NoForcedTurbo ==
\A n \in NodeId :
node_mode[n] = "TURBO" =>
/\ match_rate[n] >= TurboMaintain
/\ fail_count[n] = 0
\* S2: Delay outside tier tolerance must not coexist with TURBO.
DelayRejectionTriggersFull ==
\A n \in NodeId :
SubmittedOutsideTolerance(n) => node_mode[n] = "FULL"
\* S3: fail_count > 0 must not coexist with TURBO.
FailureExcludesTurbo ==
\A n \in NodeId :
fail_count[n] > 0 => node_mode[n] = "FULL"
\* -- Liveness -----------------------------------------------------
\* L1: A node with sustained good behaviour eventually reaches TURBO.
EventualTurbo ==
\A n \in NodeId :
(match_rate[n] >= TurboEntry /\ fail_count[n] = 0
/\ ~SubmittedOutsideTolerance(n))
~> node_mode[n] = "TURBO"
\* -- TLC model values (for model checking) ------------------------
\* MaxNodes = 3, MaxBlocks = 10, TierToleranceMs = 100
\* TurboEntry = 95, TurboMaintain = 85
====
The invariant NoForcedTurbo corresponds to Safety Property S4 of the
Helm Autonomy Layer Yellow Paper v2.0 (AS score external
immutability).
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
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 uniqueness:
Two calls to Generate() MUST NOT produce equal nonces.
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 Forgery resistance:
Verify(tampered_record, ctx) = unresolvable for any single-bit
modification exceeding the algorithm's correction capacity.
C.6 Delay rejection:
A PoT submitted at ts + tier_window + dispersion + 1 microsecond
MUST trigger FULL mode.
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 (measurable via timing).
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 provides a normative ASCII diagram of the
FILO+Integrity delay rejection mechanism described in Section 9.6.
TIME AXIS:
|----ts-----|---(ts+window)---|---------(ts+Delta)------->
PoT gen tier freshness delayed submission
time window end zone
VALID SUBMISSION WINDOW: [ts, ts + tier_window + dispersion]
DELAYED ZONE: (ts + tier_window + dispersion, infinity)
GATE 1: Integrity-tag verification (fixed cost, alg_id-dependent)
--------------------------------------------------
Input: PoT Record
If integrity_tag verdict is unresolvable:
-> REJECT immediately
-> DO NOT invoke issuer_sig or binding_proof verification
Covers: wrong context, tampered payload
GATE 2: AdaptiveSwitch freshness check
--------------------------------------------------
Input: PoT Record + current time S
If (S - ts) > tier_window + dispersion:
-> REJECT
-> Trigger FULL mode
-> Apply exponential backoff
Covers: valid PoT submitted outside freshness window
FILO QUEUE (Gate 1 AND Gate 2 passed)
--------------------------------------------------
Queue discipline: most recently generated PoT first.
If multiple PoTs qualify:
Select max(PoT.ts) for processing.
Earlier PoTs remain in queue.
Effect on delayed submissions:
o A record outside the freshness window cannot pass Gate 2.
o A qualifying record is ordered by its timestamp according to the
configured queue policy.
o Repeated failures MAY trigger the configured backoff policy
COMPLEXITY NOTE:
Gate 1 (integrity tag): O(1) per record, fixed cost
Gate 2 (freshness): O(1) per record
Queue ordering: O(log q) for q queued records (priority queue)
Verification path: O(1) with respect to network size and queue length
when the verifier applies the configured bounded single-record path.
Queue selection is separate and remains O(log q) for the priority-queue
implementation described above.
Compare with BFT consensus protocols:
PBFT/Tendermint/HotStuff: O(n^2) network-wide message
exchanges to reach Byzantine tolerance for n total nodes. TTTPS does
not replace a quorum protocol and does not claim to eliminate Byzantine
principals. Its bounded per-record path protects the local admission
decision; peer aggregation and provenance checks remain profile and
deployment policy functions.
Author's Address
Heime Jorgen
Kenosian
Email: heime.jorgen@proton.me
Jorgen Expires 21 February 2027 [Page 50]