Encrypted Client Hello Deployment Considerations
draft-campling-ech-deployment-considerations-12

ISE                                                       A. J. Campling
Internet-Draft                                    419 Consulting Limited
Intended status: Informational                                  P. Vixie
Expires: 6 January 2027                                         Red Barn
                                                               D. Wright
                                                UK Safer Internet Centre
                                                               A. Taddei
                                                              S. Edwards
                                                                Broadcom
                                                             6 July 2026

            Encrypted Client Hello Deployment Considerations
          draft-campling-ech-deployment-considerations-12

Abstract

   This document discusses operational and policy considerations 
   related to the deployment of TLS Encrypted Client Hello (ECH). It
   describes the impact of encrypting the TLS Server Name Indication
   (SNI) on operational practices such as threat detection, network
   security controls, and content filtering in private, edge, and 
   public network environments, with a particular focus on education,
   enterprise, and public operator use cases.

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 6 January 2027.

Campling, et al.          Expires 6 January 2027                [page 1]

Internet-Draft        ECH Deployment Considerations             July 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.  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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Background and Scope. . . . . . . . . . . . . . . . . . . . .   4
   3.  The Operational Usage of ClientHello Metadata. . . . . .. . .   4
     3.1.  Threat Detection. . . . . . . . . . . . . . . . . . . . .   4
     3.2.  TLS 1.3 without ECH . . . . . . . . . . . . . . . . . . .   5
     3.3.  Proxies . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Sector-Specific Deployment Considerations . . . . . . . . . .   7
     4.1.  Education Sector. . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Enterprises . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Small and Medium-Sized Businesses . . . . . . . . . . . .   8
     4.4.  Public Network Operators . . . . . . . . . . . .. . . . .   9
     4.5.  Child Online Protection. . . . . . . . . . . . .. . . . .  10
   5.  Mitigations for the Impacts of ECH . . . . . .. . . . . . . .  10
     5.1.  Managed Environments. . . . . . . . . . . . . . . . . . .  10
     5.2.  Unmanaged Environments. . . . . . . . . . . . . . . . . .  11
     5.3.  Other Options . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  12
   7. Security Considerations. . . . . . . . . . . . . . . . . . . .  13
   8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  13
   9. References . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References. . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References. . . . . . . . . . . . . . . . . .  13
   Appendix A.  Acknowledgment . . . . . . . . . . . . . . . . . . .  15
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

Campling, et al.          Expires 6 January 2027                [page 2]

Internet-Draft        ECH Deployment Considerations             July 2026

1.  Introduction

   In order to establish a secure session, TLS starts with an initial
   handshake message called the ClientHello.  As this message is sent 
   in cleartext TLS 1.3, it exposes metadata, including the Server Name
   Indication (SNI), which can be observed by on-path entities such as
   middleboxes.  This information can be used for a range of purposes,
   including the enforcement of local policies for security or 
   compliance reasons.  

   As part of a wider initiative to encrypt metadata, an extension to
   TLS 1.3 called Encrypted Client Hello (ECH) [RFC9849] aims to encrypt 
   the remaining cleartext metadata in the ClientHello, including the 
   SNI.  

There are use cases where encryption of SNI may be a useful precaution to
   reduce the risk of pervasive monitoring, and it can offer benefits
   such as improved privacy for end users.  At the same time, ECH
   presents challenges for other use cases, such as enterprises and other
   organisations that deploy network security controls to meet risk
   management and compliance obligations.  

   The Internet was originally conceived as a network of networks, each
   able to determine what data to transmit and receive from its peers. 
   Developments like ECH represent a significant architectural change by
   allowing opaque paths to be established from endpoints to services,
   potentially without the knowledge or permission of device owners.  

   While Virtual Private Networks (VPNs) also establish opaque paths,
   there is an important distinction: the use of a VPN is typically a
   deliberate act by the user, whereas ECH may be enabled by client
   software without the explicit knowledge or consent of the end user 
   or device owner.  

   [RFC7258] recognises that making networks unmanageable in order to
   mitigate pervasive monitoring is not an acceptable outcome.  [RFC8404]
   further discusses security and network operations practices that may
   be impacted by increased encryption and highlights the implications
   for enterprises that own the data on their networks, or that have
   explicit agreements to monitor user traffic, differ from those for
   service providers accessing content without such agreements. 
   
   [RFC8890] further notes that the Internet should serve end users,
   including the operators of the networks they rely on, and that
   decisions affecting users and device owners should not be taken 
   solely by client software vendors without their knowledge.

Campling, et al.          Expires 6 January 2027                [page 3]

Internet-Draft        ECH Deployment Considerations             July 2026

2.  Background and Scope

   This document considers the implications of ECH for private, edge, 
   and public networks, using examples drawn from education 
   establishments, enterprises, and public operators. It complements 
   and extends the analysis in [RFC8744] by providing additional 
   information about the issues raised by ECH for private networks that 
   rely on visibility of SNI data, including material from a roundtable 
   discussion [ECH_Roundtable].

   The objective of this document is to describe operational impacts of 
   ECH, with a particular focus on the effect of encrypting the SNI 
   field. Other elements of the ClientHello may also be relevant for 
   some on-path security mechanisms, but SNI is central to many current 
   deployment practices.

   The data encapsulated by ECH is often of legitimate interest to 
   on-path security functions. Examples include inline malware 
   detection, enterprise firewalls, parental controls, content 
   filtering to prevent access to malicious or high-risk resources, 
   and mandatory security controls such as Data Loss Prevention (DLP). 
   Beyond security, ECH also affects operational practices such as 
   network management and policy enforcement.

   This document:

   *  does not question the development of the ECH standard itself, 
      as there are use cases that benefit from its deployment;

   *  does not attempt to be exhaustive.1.2.  Scope, objectives and 
      limits of this document

3.  The Operational Usage of ClientHello Metadata

3.1  Threat Detection

   [RFC8404] identifies issues arising from increased encryption of 
   protocol elements, some of which are directly applicable to ECH. 
   For example, early triggers for DDoS mitigation often rely on the 
   ability to distinguish attacker traffic from legitimate user traffic,
   which becomes more difficult if key metadata is obscured.

   Network security capabilities are typically deployed as part of a 
   broader defence strategy (e.g., defence-in-depth [NIST-DID], Zero 
   Trust, Secure Access Service Edge (SASE), or Security Service Edge 
   (SSE)). Network security functions can trigger and enable other 
   security capabilities such as sandboxing, DLP, and Cloud Access 
   Security Broker (CASB) services. A common component is a web proxy 
   that combines TLS proxying and HTTP application-layer proxying.

Campling, et al.          Expires 6 January 2027                [page 4]

Internet-Draft        ECH Deployment Considerations             July 2026

   Similar to the analysis in [I-D.draft-ietf-opsec-ns-impact] for TLS 
   1.3, loss of visibility into SNI as an indicator of compromise has 
   significant operational consequences.  Indicators of Compromise (IoCs) 
   are documented in [RFC 9424], which also explains how they are used in 
   cyber defence. In that framework, SNI is one of several indicators 
   that can be combined to form a defence-in-depth strategy. When DNS 
   data is unavailable because of encrypted DNS protocols, SNI can remain 
   as an important signal; if SNI is also encrypted, defences may be 
   weakened and the attack surface enlarged.

3.2  Middleboxes   TLS 1.3 without ECH

   For many middleboxes to perform their role, they need to identify 
   the destination of a requested communication.  As deployment of 
   stronger encryption mechanisms has increased, the visibility of 
   suitable data sources has diminished. For example, encrypted DNS 
   protocols (such as DNS-over-TLS, DNS-over-HTTPS, and DNS-over-QUIC) 
   protect DNS traffic between clients and resolvers, reducing its 
   utility for on-path devices. Middlebox practice has therefore 
   adapted: in TLS 1.2 deployments operators relied largely on the 
   cleartext server certificate; in TLS 1.3 the certificate became 
   encrypted, and operators shifted to relying on the still-cleartext 
   SNI; with the deployment of ECH the SNI is also encrypted, and 
   another adaptation is required.

   SNI was originally introduced to address limitations in DNS data by 
   providing additional information to enable correct service selection.  
   Middlebox inspection capabilities that previously relied on the 
   cleartext certificate were adapted to instead make use of the SNI 
   field and other available metadata.   

   The most common inspection pattern for TLS 1.3 is to read the SNI from 
   the ClientHello (which remains in cleartext without ECH) and then 
   establish a separate TLS session from the proxy to the destination 
   server. Once the server certificate is retrieved, the proxy can derive
   a web category or reputation and decide whether to perform selective 
   inspection on the user's TLS session. 

   Proxies typically treat the SNI as a provisional signal and attempt to 
   validate it using additional checks. The resulting evaluation informs 
   policy decisions, such as whether to block the connection, allow it, 
   or adjust categorisation based on verified information. 

Campling, et al.          Expires 6 January 2027                [page 5]

Internet-Draft        ECH Deployment Considerations             July 2026

   It is important to note that the SNI can differ from the destination
    service, particularly for IoT devices and machine to machine API 
   traffic.  This is why operational practice combines the SNI with other 
   indicators (DNS, server certificate, IP reputation) rather than 
   treating it as authoritative. ECH does not replace this need; it 
   removes the most widely used indicator without providing an equivalent 
   network-visible substitute and consequently increases the operational 
   reliance on the remaining signals.

3.3  Proxies

   A proxy server is an intermediary application that receives requests 
   from clients and forwards them to servers, optionally enforcing policy 
   or performing additional processing. Proxies can be deployed for load 
   balancing, privacy, security, or other purposes.

   Proxies can operate in explicit or transparent modes:
   *  In the explicit proxy model, user devices or applications are 
      configured to send traffic to the proxy instead of directly to the 
      target destination.
   *  In the transparent proxy model, the proxy intercepts traffic 
      addressed to the intended destination and handles it in a way that 
      is transparent to the client.

   A key advantage of transparent proxies is that they can operate 
   without requiring configuration changes on user devices or software.  
   They are commonly used by organisations, including many education 
   environments, to provide content filtering for devices they do not 
   own, such as BYOD devices that connect to institutional networks.

   Transparent proxies often use SNI data to infer the nature of the 
   destination service and to enforce policies such as blocking 
   inappropriate content without inspecting payload data beyond the SNI 
   field.  Encrypting SNI via ECH disrupts this approach and may require 
   significantly more intrusive inspection techniques to achieve 
   equivalent policy enforcement.

   The loss of visibility into SNI at the TLS layer prevents transparent 
   proxies from applying corporate policies for risk management and 
   compliance. For example:

   *  categories of compromised or high-risk sites can no longer be 
      enforced based on SNI alone, exposing employees and organisations 
      to additional risk and requiring alternative blocking techniques;
   *  corporate lists of excluded sites (e.g., for regulatory or policy 
      reasons) require new mechanisms for enforcement.

Campling, et al.          Expires 6 January 2027                [page 6]

Internet-Draft        ECH Deployment Considerations             July 2026

   TLS proxies can also perform selective interception to avoid 
   inspecting or modifying application payload when not necessary. This 
   selective model relies heavily on knowing the origin server hostname, 
   which is derived from the cleartext SNI in current deployments.

   The loss of SNI visibility makes it more difficult to target such 
   controls and may be impossible in BYOD contexts where proxies cannot 
   be explicitly configured. This can introduce operational 
   inefficiencies, increased resource consumption, and elevated security 
   risk. It may also be counterproductive for privacy, as proxies may 
   resort to broader decryption of TLS sessions to compensate for the 
   loss of selective mechanisms.

4.  Sector-Specific Deployment Considerations

   The following is a non-exhaustive review of some of the use cases 
   where ECH deployment may pose specific challenges.  

4.1  Education Sector

   In the education sector, ECH may circumvent safeguards that rely on 
   content filtering to protect children from exposure to malicious, 
   adult, extremist, or otherwise inappropriate content. These safeguards 
   have already been affected by encrypted DNS protocols such as DNS-
   over-HTTPS [RFC8484].  

   Content filtering based on SNI data is widely used by educational 
   establishments to meet statutory or regulatory obligations to 
   implement appropriate filtering systems.  For example, schools in some 
   jurisdictions are required to deploy content filters as a condition 
   for funding or to meet statutory guidance.  Any bypassing of such 
   filters by client software that uses ECH may undermine these 
   obligations.  

   In addition to exposing students to age-inappropriate and possibly 
   harmful content, a lack of effective content filtering may have legal 
   or operational implications for the school authorities.

4.2     Enterprises 

   Enterprises and other large organisations need to protect themselves 
   for a variety of reasons, including:
   *  Risk reduction, as part of broader cyber resilience strategies.
   *  Protection of reputation and other intangible assets, such as brand 
      equity, market value, and creditworthiness, which may be affected 
      by successful cyber attacks.

Campling, et al.          Expires 6 January 2027                [page 7]

Internet-Draft        ECH Deployment Considerations             July 2026

   *  Compliance with a growing and diverse set of policies, regulations, 
      certifications, labelling schemes, and guidelines, often issued by 
      national and regional bodies and increasing in both scope and 
      complexity.

   Approaches to endpoint control vary among enterprises and 
   organisations, depending on size, use cases, and other factors.  
   Large organisations may exert substantial control over managed 
   endpoints, while still needing to support BYOD scenarios that are 
   harder to manage. Smaller organisations and many SMBs may have 
   limited ability to control endpoints and often depend on external 
   security service providers.

   Some client software (such as web browsers) may offer configuration 
   options to disable ECH, which provides one mitigation path for 
   enterprises for managed devices. However, this approach is not 
   holistic. Enterprises must also consider:
   *  clients that do not provide an option to disable ECH;
   *  the possibility that ECH may become non-optional in some software; 
      non-browser applications built on libraries that implement ECH 
      without exposing configuration controls; 
   *  BYOD and other unmanaged devices; and
   *  The risk that adversaries may leverage ECH to conceal command-and-
      control communications or other malicious activities.

   Organisations operating in some sectors will be required to implement 
   mitigation measures to counteract the effect of ECH.  For example, 
   companies operating in wholesale finance may typically be required to 
   have complete records of all inbound and outbound communications to 
   reduce the risk of insider trading.  An incomplete audit trail can 
   risk significant financial and other penalties.  

4.3     Small and Medium-Sized Businesses

   Definitions of SMBs vary by jurisdiction, but they range from very 
   small businesses (e.g., SOHO environments) to medium-sized 
   enterprises. Many SMBs have limited internal security capabilities 
   and outsource security to managed service providers or network 
   operators. Budget constraints further limit the level of support that 
   can be deployed.  Even if technical solutions exist that could help 
   them meet their operational and compliance obligations, affordability 
   and lack of in-house expertise may make such solutions difficult to 
   adopt.

   In common with some larger organisations, some small and medium-sized 
   businesses operate in regulated industries, so may have no choice 
   whether to implement measures to mitigate the impact of the 
   introduction of ECH.  

Campling, et al.          Expires 6 January 2027                [page 8]

Internet-Draft        ECH Deployment Considerations             July 2026

4.4     Public Network Operators

   Public network operators often have significant obligations imposed by 
   national, regional, or international legislation or regulation.  
   Broadly, two regulatory approaches can be distinguished:
   *  No specific legislation for blocking, filtering, or takedown of 
      illegal Internet content, relying instead on general legal 
      frameworks and self-regulation, with limited targeted 
      interventions.
   *  A specific legal framework for the regulation of Internet content, 
      including blocking, filtering, and the takedown of content, 
      typically specifying legal grounds, competent authorities, and 
      procedures.

   It is useful to distinguish between blocking and takedown:
   *  Blocking, filtering, or preventing access to content refers to 
      technical measures intended to restrict access to information or 
      resources, typically hosted in another jurisdiction. These measures 
      are usually implemented by Internet access providers using hardware 
      or software that prevents specified content from being received or 
      displayed by their customers.
   *  Takedown or removal refers to measures aimed at website operators 
      or hosting providers to remove or delete content. 

   ECH primarily impacts content blocking.  

   Content blocking can be implemented using several techniques, 
   including:
   *  blocking of DNS queries or responses;
   *  analysis of the SNI field; and
   *  analysis of URLs (where unencrypted).

   Because of widespread encryption of application data, effective 
   blocking often requires a combination of these techniques.

   For illegal content and national security threats, many countries use 
   centrally managed lists of domains or URLs that must be blocked.  
   These lists are updated regularly and shared with public network 
   operators, which must enforce blocking and may face legal consequences 
   for failing to do so.

   Historically, DNS-based blocking and proxy-based blocking have been 
   used. DNS-based blocking is effective for domain-level blocking, while 
   proxies can be used for domain-level and, where traffic is 
   unencrypted, URL-level blocking.

Campling, et al.          Expires 6 January 2027                [page 9]

Internet-Draft        ECH Deployment Considerations             July 2026

   As the vast majority of traffic is now encrypted, the share of traffic 
   suited to URL-based blocking has decreased; proxy blocking is often 
   comparable to DNS-based blocking in practice, suffering the same 
   limitations with encrypted traffic.  With the reduced effectiveness of 
   these techniques, operators may also rely on SNI analysis to meet 
   blocking obligations.

   The deployment of ECH introduces additional obstacles for operators 
   attempting to meet mandatory content-blocking obligations.  Operators 
   may therefore consider wider use of IP-based blocking as a fallback. 
   IP blocking is a relatively crude mechanism and risks significant 
   over-blocking where multiple services share the same IP address. They 
   may have limited options, however, as operators that do not meet their 
   legal obligations may be subject to enforcement actions or sanctions.

4.5  Child Online Protection

   In Child Online Protection contexts, the primary objective for illegal 
   content is removal at source. Blocking and filtering are complementary 
   measures that reduce exposure and provide time for content removal 
   processes to operate.

   SNI-based blocking is an important tool for restricting access to 
   encrypted websites that host illegal content, especially when hosts 
   are slow to remove such content.  For legal but harmful content (e.g., 
   sexual content, gambling, self-harm, animal cruelty) that cannot be 
   removed at source, detection and blocking are often the only practical 
   measures available.

   In some countries, network operators are required or incentivised to 
   offer network-based parental control services, typically implemented 
   using DNS and/or SNI-based techniques. These controls may already be 
   subject to circumvention by users who change DNS settings to use 
   external resolvers, and ECH further compromises their effectiveness.

5.  Mitigations for the Impacts of ECH

5.1  Managed Environments

   Where it is desirable to counter the impact of ECH, a number of 
   general approaches can be employed, depending on the use case, 
   including: 

   *  The management of end-points centrally, restricting the ability of 
      users to change DNS settings or enable ECH capabilities, and 
      restricting their ability to load applications that may bypass 
      those controls;

Campling, et al.          Expires 6 January 2027               [page 10]

Internet-Draft        ECH Deployment Considerations             July 2026

   *  The enforced use of zero-trust DNS, routing all queries to a 
      designated DNS resolver
   *  Remove ECH parameters from HTTPS/SVCB records at the resolver, so 
      TLS falls back to a normal, non ECH ClientHello;
   *  Withdrawal of support for  Bring Your Own Device  or require 
      installation of full proxies and trust anchors on such devices as a 
      condition of network access;
   *  The routing of all of TLS traffic to destinations where visibility 
      of the source and destination is required (eg explicit proxies, 
      enterprise gateways, CDN edges) instead of relying on passive 
      middleboxes seeing the SNI data;
   *  Drop HTTPS (type 65) and SVCB (type 64) records so the end-point 
      never receives ECH configuration information;
   *  Use an  enterprise browser  that has been configured so that ECH 
      settings are neither visible nor operational.

   Even taken together, these managed-network controls leave several 
   coverage gaps.  As already noted, tThey do not address devices that 
   are not enrolled in management (BYOD and guest devices).  In addition, 
   non-browser applications that embed TLS libraries with ECH support but 
   no policy hook are not addressed, nor is traffic from compromised or 
   malicious endpoints inside the perimeter.  In addition, further 
   developments may see client software vendors progressively reduce or 
   remove the ability to disable ECH. These gaps are particularly 
   relevant to the education, SMB, and public-network-operator use cases 
   discussed earlier, where the assumption of a fully managed estate does 
   not hold.

5.2  Unmanaged Environments
   Other than in enterprises and other large, well-resourced 
   organisations, adopting enterprise-style device management 
   capabilities may be technically possible but difficult in practice, 
   given constraints on budgets and technical expertise.  Even where 
   suitable technical solutions exist, they may be unaffordable or 
   operationally challenging to deploy at scale.

   For BYOD and similar scenarios where devices are not institutionally 
   managed, transparent proxies have been used to enforce policy without 
   installing software on third-party devices. When ECH is deployed and 
   SNI is no longer visible, institutions may need to rely on endpoint-
   based controls, where feasible.  Otherwise, it may be necessary to 
   withdraw support for BYOD.

Campling, et al.          Expires 6 January 2027               [page 11]

Internet-Draft        ECH Deployment Considerations             July 2026

5.3  Other Options

   Several  zero trust DNS  implementations have been developed for
   enterprise environments.  These typically require the use of a 
   designated local resolver for all DNS queries, preventing an external 
   resolver from providing ECH configuration information to an endpoint.  
   All outbound IPv4/IPv6 traffic is blocked by default, allowing 
   connections solely to IP addresses resolved by these trusted servers, 
   which will usually be configured with a custom allow list that limits 
   access to specified content.  This option is primarily intended for 
   enterprise and similar environments.

   Where client software does not permit ECH to be disabled, 
   organisations may conclude that they must avoid or remove such 
   software from managed devices and replace it with alternatives, if 
   available.  This can have budgetary and operational consequences, 
   particularly where substantial investments have already been made in 
   particular applications.

   An alternative response to the loss of metadata at the network level 
   is to move safety and security tooling to endpoints.  This may be 
   effective in some environments (e.g., managed desktop operating 
   systems), but many mobile safety tools rely on local proxy mechanisms 
   that are also adversely impacted by ECH.

6.  Conclusions

   Access to SNI data in some environments is an important component of 
   organisational risk management and regulatory compliance.  The 
   introduction of ECH support in client software creates operational 
   challenges, particularly for organisations operating private networks 
   in sectors such as education and finance.  Some of these challenges 
   may be mitigated for managed devices if client software provides 
   policy controls that allow ECH to be disabled.

   Third-party and unmanaged devices pose additional challenges. ECH may 
   render transparent proxies ineffective, leading institutions to 
   require installation of full proxies and trust anchors on such devices 
   as a condition of network access, or alternatively to deny network 
   access to unmanaged devices. Both approaches carry financial, 
   complexity and other trade-offs.

   There are also negative impacts for public network operators, where 
   the inability to reliably use SNI data to fulfil regulatory 
   obligations may see increased use of IP-based blocking, with a 
   consequent increased risk of collateral damage through over-blocking 
   of sites or content.

Campling, et al.          Expires 6 January 2027               [page 12]

Internet-Draft        ECH Deployment Considerations             July 2026

7.  Security Considerations
   This document does not question the development of the ECH standard 
   itself, as there are use cases that benefit from its deployment.  
   However, in addition to introducing operational and financial impacts, 
   the encryption of SNI via ECH poses new challenges for threat 
   detection and incident response.  

   The document describes several contexts in which loss of SNI 
   visibility affects the ability of defenders to detect, block, or 
   investigate malicious activity.  It also notes instances where 
   alternative approaches may encroach further on user privacy.  

   Any mitigation strategy that attempts to restore visibility (for 
   example, by shifting controls to endpoints or by broader decryption of 
   traffic) must itself be evaluated against security and privacy 
   considerations, including risks of new attack surfaces, misuse of 
   monitoring capabilities, and compliance with applicable data 
   protection regulations.

8.  IANA Considerations

   This document has no IANA actions.

9.  References

9.1.  Normative References

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/rfc/rfc8484>.

9.2.  Informative References

   [ECH_Roundtable]
              419 Consulting, "Encrypted Client Hello - Notes from an
              ECH Roundtable", 18 August 2021,
              <https://419.consulting/encrypted-client-hello/>.

   [I-D.draft-ietf-opsec-ns-impact]
              Cam-Winget, N., Wang, E., Danyliw, R., and R. DuToit,
              "Impact of TLS 1.3 to Operational Network Security
              Practices", Work in Progress, Internet-Draft, draft-ietf-
              opsec-ns-impact-04, 26 January 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-
              ns-impact-04>.

Campling, et al.          Expires 6 January 2027               [page 13]

Internet-Draft        ECH Deployment Considerations             July 2026

   [NIST-DID] NIST, "Glossary - defense-in-depth", n.d.,
              <https://csrc.nist.gov/glossary/term/defense_in_depth#:~:t
              ext=Definition(s)%3A,and%20missions%20of%20the%20organizat
              ion.>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/rfc/rfc7258>.

   [RFC8404]  Moriarty, K., Ed. and A. Morton, Ed., "Effects of
              Pervasive Encryption on Operators", RFC 8404,
              DOI 10.17487/RFC8404, July 2018,
              <https://www.rfc-editor.org/rfc/rfc8404>.

   [RFC8744]  Huitema, C., "Issues and Requirements for Server Name
              Identification (SNI) Encryption in TLS", RFC 8744,
              DOI 10.17487/RFC8744, July 2020,
              <https://www.rfc-editor.org/rfc/rfc8744>.

   [RFC8890]  Nottingham, M., "The Internet is for End Users", RFC 8890,
              DOI 10.17487/RFC8890, August 2020,
              <https://www.rfc-editor.org/rfc/rfc8890>.

   [RFC9424]  Paine, K., Whitehouse, O., Sellwood, J., and A. Shaw,
              "Indicators of Compromise (IoCs) and Their Role in Attack
              Defence", RFC 9424, DOI 10.17487/RFC9424, August 2023, 
              <https://www.rfc-editor.org/rfc/rfc9424>.

   [RFC9849]  Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
              March 2026, <https://www.rfc-editor.org/rfc/rfc9849>.

Campling, et al.          Expires 6 January 2027               [page 14]

Internet-Draft        ECH Deployment Considerations             July 2026

Appendix A.  Acknowledgment

   In memory of Simon Edwards who passed away in the night of 8th-9th of
   January 2023.

   In addition to the authors, this document is the product of an
   informal group of experts including the people listed in the
   Contributors list in Appendix.

Contributors

   Eric Chien
   Broadcom
   Email: Eric.Chien@broadcom.com
   URI:   https://www.linkedin.com/in/eric-chien-66b4b258/

   Eric contributed to the analysis of the Man in the Browser attacks.

   Gianpaolo Scalone
   Vodafone
   Email: gianpaolo-angelo.scalone@vodafone.com
   URI:   https://www.linkedin.com/in/gianpaoloscalone/

   Contributed the research on the conflicts of ECH with local
   legislation on content blocking.

   Daniel Engberg
   Skandinaviska Enskilda Banken AB (SEB)
   Email: daniel.engberg@seb.se
   URI:   https://www.linkedin.com/in/daniel-engberg-1561aaa/

   Validated the issues for his organization.

   Celine Leroy
   Eight Advisory
   Email: celine.leroy@8advisory.com
   URI:   https://www.linkedin.com/in/celine-leroy-1a534252/

   Thank you to Celine for her work on cybersecurity financial impacts
   on enterprises.

Campling, et al.          Expires 6 January 2027               [page 15]

Internet-Draft        ECH Deployment Considerations             July 2026

   Gianpiero Tavano
   Broadcom
   Email: Gianpiero.Tavano@broadcom.com
   URI:   https://www.linkedin.com/in/gianpiero-tavano-5b975383/

   Reviewed the text, provided feedback and reminded us on the budgetary
   issues

   Roelof duToit
   Broadcom
   Email: roelof.dutoit@broadcom.com
   URI:   https://www.linkedin.com/in/roelof-du-toit-a66831/

   Roelof contributed many things including research, former I-D, text,
   the newly setup github, etc.

   Diego Lopez
   Telefonica
   Email: diego.r.lopez@telefonica.com
   URI:   https://www.linkedin.com/in/dr2lopez/

   Diego contributed in several aspects including MCPs.

   Gary Tomic
   Broadcom
   Email: gary.tomic@broadcom.com
   URI:   https://www.linkedin.com/in/garytomic/

   Gary contributed many things including research, keep us on scope,
   critique for when issues where not impacted by ECH as we initially
   thought.

   Bob Blair
   Broadcom
   Email: bob.blair@broadcom.com
   URI:   https://www.linkedin.com/in/bob-blair-8b7273/

   Bob contributed to several reviews, many calls, and the whole
   appendix A.

   Pascal Paisant
   BNP Paribas
   Email: pascal.paisant@bnpparibas.com
   URI:   https://www.linkedin.com/in/pascal-paisant-727a531/

   Pascal contributed to several parts, in particular in the general SNI
   section, on enterprises section and on migration issues.

Campling, et al.          Expires 6 January 2027               [page 16]

Internet-Draft        ECH Deployment Considerations             July 2026

   Zied Turki
   ZT Consulting
   Email: zied.turki@ztconsulting.fr
   URI:   https://www.linkedin.com/in/zied-turki/

   Zied contributed to several parts, in particular the rationale on SNI
   unreliability.

Authors' Addresses

   Andrew Campling
   419 Consulting Limited
   Email: Andrew.Campling@419.Consulting
   URI:   https://www.419.Consulting/

   Paul Vixie
   Red Barn
   Email: paul@redbarn.org
   URI:   http://www.redbarn.org/

   David Wright
   UK Safer Internet Centre
   Email: david.wright@swgfl.org.uk
   URI:   https://saferinternet.org.uk/

   Arnaud Taddei
   Email: arnaud.taddei.sdo@gmail.com
   URI:   https://www.linkedin.com/in/arnaudtaddei/

   Simon Edwards
   Broadcom
   1320 Ridder Park Dr
   San Jose, CA 95131
   United States of America
   Email: Simon.Edwards@broadcom.com
   URI:   https://www.linkedin.com/in/simononsecurity/

Campling, et al.          Expires 6 January 2027               [page 17]