%% You should probably cite draft-helmprotocol-tttps-06 instead of this revision.
@techreport{helmprotocol-tttps-04,
    number =    {draft-helmprotocol-tttps-04},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-helmprotocol-tttps/04/},
    author =    {장동호},
    title =     {{The TLS TimeToken Secure Protocol (tttps://)}},
    pagetotal = 51,
    year =      ,
    month =     ,
    day =       ,
    abstract =  {This document specifies the TLS TimeToken Secure Protocol (tttps://), a protocol extension that augments TLS 1.3 {[}RFC8446{]} with cryptographically verifiable temporal ordering. Internet infrastructure assumes that channels are passive: noise is random and channel operators have no ordering preferences. This assumption is structurally violated when ordering has economic value -- NTP servers, BGP routing authorities, DNS resolvers, and transaction sequencers all have incentive to misrepresent ordering. This document formalises the problem as the Strategic Channel Controller Problem (SCCP), absent from classical information theory. Temporal ordering attacks are structurally more acute for autonomous AI agents than for human participants: as agent reaction times converge toward symmetry, ordering advantage can no longer be earned through superior human latency. No existing protocol -- including O(n\textasciicircum{}2) BFT consensus, which tolerates but does not eliminate Byzantine nodes -- provides a cryptographic pre-ingestion defense for this case. TTTPS introduces Proof-of-Time (PoT): a multi-source synthesised timestamp protected by the GRG integrity pipeline (Golomb-Rice -\textgreater{} Reed-Solomon -\textgreater{} Golay(23,12,7) -\textgreater{} HMAC), whose stage ordering is mathematically necessary (Theorems 1-3 of the companion paper {[}POT2026{]}). PoT achieves Byzantine temporal elimination at O(1) per record, independent of network size. An AdaptiveSwitch mechanism makes ordering manipulation economically self-defeating; the equilibrium threshold is derived in closed form and empirically calibrated from deployed data (Section 6.4). Deployment on Base Sepolia produces 70,000+ verified records; 55\% are generated by autonomous AI agents -- an unanticipated finding that confirms the structural severity of the ordering problem in agent economies. This document has Experimental status. The GRG pipeline specification will be published upon conclusion of pending patent proceedings (Section 12). Discussion Note This note is to be removed before publishing as an RFC. This document is being discussed on the dispatch@ietf.org mailing list. The authors have submitted a BoF request for IETF 126 (Vienna, July 2026) targeting the DISPATCH working group. Comments and participation are welcome. Changes from -03: * Header: revision -03 -\textgreater{} -04; dates updated (23 June 2026 / Expires 25 December 2026). * New Section 15.3: Formal Verification Artifacts -- records the publicly available kenoslean PyPI package (version 0.1.0) and the Lean 4 / Mathlib formalisation of the G-Score / InsufficientKnowledge confidence primitive (sorry-free). (Existing 15.3 Interested Parties renumbered to 15.4.) * New Appendix E: Motivating Use Case -- a regulated therapeutic- design data-integrity scenario distinguishing record integrity (TTTPS) from computation integrity (formal verification), aligned with FDA 21 CFR Part 11. * References: {[}I-D.ietf-ntp-roughtime{]} (Roughtime, the protocol the D\_chain mechanism depends on) and {[}I-D.ietf-rats-msg-wrap{]} (CMW) added as informative references; both are in the RFC Editor Queue as of June 2026 (status verified on the IETF Datatracker). {[}KENOSLEAN{]} and {[}21CFR11{]} added. Changes from -02: * New Section 1.1: "Why This Protocol, Why Now" * New Section 2: Use Cases (satellite, 5G, financial, AI agents) * New Section 4.2: SS7/SCCP Legacy Infrastructure as SCCP Instance * New Section 10.8: Path Manipulation Attack Scenarios (3 scenarios) * New Section 10.9: Trust Model and Key Compromise Resilience * New Section 15: Implementation Status (RFC 7942) * Section 5.5 Verification: future-timestamp check, TLS binding step * References: SS7-VULN, GSMA-SS7, GPS-SPOOF, RFC6962, RFC9557},
}