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, . 9.2. Informative References [ECH_Roundtable] 419 Consulting, "Encrypted Client Hello - Notes from an ECH Roundtable", 18 August 2021, . [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, . 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., . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of Pervasive Encryption on Operators", RFC 8404, DOI 10.17487/RFC8404, July 2018, . [RFC8744] Huitema, C., "Issues and Requirements for Server Name Identification (SNI) Encryption in TLS", RFC 8744, DOI 10.17487/RFC8744, July 2020, . [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, DOI 10.17487/RFC8890, August 2020, . [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, . [RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849, March 2026, . 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]