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
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]