Individual Submission Y. Filimonov Internet-Draft Independent Intended status: Experimental 18 November 2025 Expires: 22 May 2026 Outer-Inner TLS (OI-TLS) draft-filimonov-oitls-00 Abstract Outer-Inner TLS (OI-TLS) hides TLS ClientHello metadata (SNI, ALPN, cipher list, JA3) from on-path DPI by splitting a TLS session into two layers. The client first establishes an outer TLS 1.3 tunnel to an entry node with no SNI, then tunnels an ordinary TLS handshake for the backend inside that encrypted channel. This document describes the architecture, signaling, deployment considerations, and security trade-offs, together with laboratory evidence demonstrating the technique. 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 22 May 2026. Copyright Notice Copyright (c) 2025 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. Filimonov Expires 22 May 2026 [Page 1] Internet-Draft OI-TLS November 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation and Relationship to Existing Work . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 5. DNS Signaling . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 3 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction DPI appliances routinely block HTTPS connections based on TLS ClientHello contents such as SNI, ALPN, cipher lists, or JA3 fingerprints ([RFC8446]). OI-TLS inserts an entry node between the client and backend. On-path observers see only a normal TLS 1.3 connection to an IP address, whereas the true ClientHello is tunneled inside the outer channel. 2. Motivation and Relationship to Existing Work Encrypted Client Hello (ECH) [I-D.ietf-tls-esni] protects SNI within a single TLS handshake but requires clients, DNS, and origin servers to support ECH and to deploy DNSHPKE keys. OI-TLS targets operators that can deploy a terminating entry proxy in front of unmodified backends; only the entry node needs changes. OI-TLS also hides the entire ClientHello (cipher list, JA3, ALPN), not only SNI. Unlike domain-fronting techniques, OI-TLS does not rely on CDN misconfiguration; entry nodes are explicit infrastructure. 3. Terminology * OuterTLS – TLS 1.3 session between client and entry node, no SNI, certificate bound to entry IP. * InnerTLS – TLS 1.3 (or 1.2) session between client and backend, carried as application data inside OuterTLS. * Entry Node – Frontend proxy that terminates OuterTLS, parses the inner ClientHello, selects a backend, and relays InnerTLS records. * Backend – Origin server that terminates the InnerTLS connection. Filimonov Expires 22 May 2026 [Page 2] Internet-Draft OI-TLS November 2025 4. Architecture Client --OuterTLS--> Entry Node --InnerTLS--> Backend. 1) DNS discovery: client queries `_oitls.example.com TXT "v=1 ttl_outer=10"` or an HTTPS RR `example.com HTTPS ... oi-tls=1` to learn that OI-TLS is supported. 2) OuterTLS: client connects to the entry IP (A/AAAA answer) with TLS 1.3, no SNI, ordinary extensions. 3) InnerTLS: client generates a standard ClientHello with the real SNI and transmits it as encrypted application data. 4) Session lifetime: outer tunnel normally stays up for the session, but entry nodes MUST enforce an advertised TTL and drop tunnels where the inner handshake never starts. After the inner handshake completes, entry nodes MAY close the outer tunnel. 5. DNS Signaling Clients SHOULD retrieve `_oitls` TXT/HTTPS records using DoH/DoT ([RFC8484], [RFC7858]) to hide the signal from DPI; UDP queries still work but leak metadata. The TXT record may carry parameters such as outer TTL or ALPN hints. The entry IP is taken from the original A/ AAAA answer. If no OI-TLS record exists, the client falls back to plain TLS. 6. Deployment Considerations * Entry Integration: OI-TLS can run within HAProxy/nginx modules or standalone proxies. The entry node inspects only the first inner record. * Backend Requirements: none—backends see an ordinary TLS session and can host HTTP/1.1, HTTP/2, WebSocket, etc. * Certificate Validation: OuterTLS MUST use trusted certificates (e.g., ACME for entry IPs). DNS discovery SHOULD use trusted DoH/ DoT. * OuterTLS TTL: entry nodes MUST enforce an advertised TTL (e.g., 5–10s) and drop tunnels with no inner ClientHello. After the inner handshake, outer tunnels MAY be closed. * Rate Limiting: operators SHOULD cap concurrent OuterTLS sessions and inner handshakes to mitigate CPU-based DDoS. Filimonov Expires 22 May 2026 [Page 3] Internet-Draft OI-TLS November 2025 7. Implementation Status Reference code and Docker labs are available at https://github.com/EvrkMs/OI-TLS. The labs include a baseline HTTPS flow where DPI observes SNI and an OI-TLS flow where DPI’s SNI extractor fails. These labs demonstrate the logic and are not production SDKs; real deployments require separate client/entry implementations. 8. Security Considerations OI-TLS hides ClientHello metadata but does not defend against IP blocking, volumetric DDoS, or backend compromise. Entry nodes become trusted points of failure; if compromised they reveal all SNI values. Proper certificate validation and DoH/DoT are required to avoid MITM. Entry nodes must be protected via Anycast, load balancing, and rate limiting. 9. IANA Considerations This document makes no requests of IANA. 10. References [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, October 2018, . [RFC7858] Hu, Z., "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, May 2016, . [I-D.ietf-tls-esni] Rescorla, E., "TLS Encrypted Client Hello", 2024, . Author's Address Filimonov Yaroslav Aleksandrovich Independent Email: evrk.msn@gmail.com Filimonov Expires 22 May 2026 [Page 4]