DISPATCH G. Scalone Internet-Draft Vodafone Intended status: Informational 20 October 2025 Expires: 23 April 2026 Customer-Facing Relay (CFR): Enhancing Source Privacy in Encrypted Transport and CDN Scenarios draft-scalone-cfr-source-privacy-00 Abstract Encrypted Client Hello (ECH) improves destination privacy by encrypting the Server Name Indication in TLS, but the customer's source identity-- typically the IP address and network metadata-- remains observable to intermediaries such as CDNs, hosting providers, and recursive resolvers. This document introduces the _Customer- Facing Relay (CFR)_, a lightweight, transport-agnostic relay operated by access providers to decouple customer identity from encrypted destinations. By forwarding opaque encrypted payloads (TCP or UDP) without terminating TLS or QUIC, a CFR complements ECH encryption to strengthen source privacy and reduce metadata correlation. 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 23 April 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Scalone Expires 23 April 2026 [Page 1] Internet-Draft CFR Source Privacy October 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Customer-Facing Relay (CFR) Concept . . . . . . . . . . . . . 3 5. Relationship to Existing Work . . . . . . . . . . . . . . . . 4 6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Informative References . . . . . . . . . . . . . . . . . 5 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction While encryption technologies such as TLS 1.3 and Encrypted Client Hello (ECH) significantly enhance destination privacy, the source of connections remains exposed. Content delivery infrastructures can still observe customer IP addresses and associated metadata, enabling correlation of user behavior even when the content and destination name are protected. This document proposes the _Customer-Facing Relay (CFR)_ architecture, which introduces a minimal intermediary between the customer and the encrypted destination to partition visibility of metadata. The intent is to complement existing privacy mechanisms by focusing on the source side of communication. 2. Terminology *CFR*: _Customer-Facing Relay_, a privacy-enhancing network function located close to the end customer, for example within an ISP or enterprise access network. *CFS*: _Client-Facing Server_ as defined in ECH. The CFS terminates encrypted handshakes on behalf of multiple origins. In contrast, the _CFR does not terminate TLS or QUIC sessions._ It forwards encrypted Scalone Expires 23 April 2026 [Page 2] Internet-Draft CFR Source Privacy October 2025 packets while rewriting addressing information, similar to a NAT or tunnel endpoint, with the explicit goal of protecting customer source privacy. 3. Motivation Destination privacy has improved through encryption, but this progress has increased traffic centralization. A small number of CDNs now terminate most encrypted sessions, consolidating visibility over user traffic. This creates an architectural imbalance: encryption hides _what_ is accessed but not _who_ is accessing it. Observed effects: * CDNs acting as Client-Facing Servers can correlate customer IPs across thousands of hosted domains. * Aggregation of ECH traffic concentrates metadata in few entities. CFRs aim to rebalance this asymmetry by separating customer identity from destination visibility. 4. Customer-Facing Relay (CFR) Concept A Customer-Facing Relay (CFR) is a lightweight, privacy-oriented intermediary positioned at the customer's network edge. It relays encrypted transport flows toward upstream services without decrypting or terminating them, rewriting source addressing to prevent direct correlation between the customer's IP identity and the encrypted destination. Customer ---> CFR ---> CDN ---> Origin Server Characteristics: * *Transport-agnostic* - Works for both TCP and UDP, forwarding opaque encrypted packets. * *No TLS/QUIC termination* - The end-to-end encryption context is preserved. * *Deployable* - Can be operated by access providers and enterprises. * *Transparent* - Performs no content filtering, categorization, or inspection. * *Discoverable* - May be discovered via DNS-based mechanisms such as DDR or DNR. Scalone Expires 23 April 2026 [Page 3] Internet-Draft CFR Source Privacy October 2025 +==========+==============+===================+====================+ | Entity | Knows Source | Knows Destination | Content Visibility | +==========+==============+===================+====================+ | Customer | X | X | X | +----------+--------------+-------------------+--------------------+ | CFR | X | | | +----------+--------------+-------------------+--------------------+ | CDN | | X | | +----------+--------------+-------------------+--------------------+ Table 1 By splitting knowledge between the CFR and the CDN, no single entity can fully correlate source and destination metadata. Trust assumptions: * The customer trusts the CFR not to expose source IP mappings. * The CFR cannot read or modify encrypted traffic. * The upstream service cannot identify the original customer. 5. Relationship to Existing Work * *ECH (RFC9460)* - Protects destination identity; CFR complements it by protecting source identity. * *MASQUE (CONNECT-UDP / CONNECT-IP)* - Provides tunnel mechanisms; CFR can reuse similar encapsulation but for privacy rather than proxying. * *DPRIVE (DoH/DoT/DoQ)* - Encrypts DNS traffic; CFR addresses the transport-layer metadata. * *PEARG / HRPC* - Explore broader issues of privacy and decentralization in Internet architecture. 6. Open Questions * How should CFR discovery and trust bootstrapping be achieved? * What performance impacts arise from additional relay hops? * Should CFRs support chaining or federation? * How can abuse prevention coexist with privacy guarantees? * Which IETF area or WG should progress standardization? 7. Security Considerations CFRs enhance privacy by partitioning knowledge between multiple parties, but they also introduce new trust points and potential attack surfaces. Scalone Expires 23 April 2026 [Page 4] Internet-Draft CFR Source Privacy October 2025 * *Collusion or compromise* - A malicious or compromised CFR could share mapping data with CDNs, restoring correlation. Transparency and operational independence are essential. * *Inspection risk* - CFRs must not evolve into inspection or policy enforcement devices. The design goal is strict pass-through of opaque encrypted traffic. * *Denial-of-Service* - CFRs could be abused as open relays or DoS amplifiers. Operators must implement rate limits, authentication, or Privacy Pass-like tokens. * *Accountability vs. anonymity* - Further study is required to balance deployability with protection against abuse. 8. IANA Considerations This document makes no IANA requests. 9. References 9.1. Informative References * [RFC9460] Benjamin L. et al., _TLS Encrypted Client Hello_, RFC 9460, 2023. * [RFC9325] Thomson, M., _Recommendations for Secure Use of TLS and DTLS_, RFC 9325, 2022. * [I-D.ietf-masque-connect-udp] _The CONNECT-UDP Method for HTTP_, Internet-Draft, IETF MASQUE WG. * [I-D.ietf-add-ddr] _Discovery of Designated Resolvers (DDR)_, Internet-Draft, IETF ADD WG. * [I-D.ietf-add-dnr] _Discovery of Network-designated Resolvers (DNR)_, Internet-Draft, IETF ADD WG. 10. Acknowledgments The author acknowledges the helpful input and discussions from Andrew Campling, Arnaud Taddei, Kevin Smith, Lee Wilman, Tom Newton, and colleagues within Vodafone Group, DINRG, and DISPATCH. Author's Address Gianpaolo Angelo Scalone Vodafone Scalone Expires 23 April 2026 [Page 5]