RFC 9848
Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings 🎀
okay so this one is an Internet Standards Track doc from the IETF 💅 It's a real product of the IETF community, it got public review, and the IESG signed off on it. It came out in March 2026 as RFC 9848, and the ISSN is 2070-1721. The authors are B. Schwartz (Meta Platforms, Inc.), M. Bishop, and E. Nygren (Akamai Technologies). The header doesn't list anything it obsoletes or updates, so no drama there 🧚
Abstract ✨
bestie, the whole problem is this: to use TLS Encrypted ClientHello (ECH), the client has to learn the server's ECH configuration before it even tries to connect 😭 This spec gives you a way to hand that config over through DNS, using a SVCB or HTTPS resource record (RR). it's giving bootstrapping glow-up 🌸
Status of This Memo
this is an Internet Standards Track document 🦋 It's a product of the IETF and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want the deeper lore on Internet Standards, check Section 2 of RFC 7841.
for the current status, errata, or feedback, go to https://www.rfc-editor.org/info/rfc9848 💜
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, which you can find at https://trustee.ietf.org/license-info as they were in effect when this was published. please actually read those, they spell out your rights and restrictions 🙈 Also, any Code Components pulled out of this doc have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty under the Revised BSD License.
Table of Contents
1. Overview
2. Terminology
3. SvcParam for ECH Configuration
4. Requirements for Server Deployments
5. Requirements for Client Implementations
5.1. Disabling Fallback
5.2. ClientHello Construction
5.3. Performance Optimizations
6. Interaction with HTTP Alt-Svc
7. Examples
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Authors' Addresses1. Overview 🧚
okay so the Service Bindings framework [SVCB] lets server operators publish a detailed description of their service in the Domain Name System (DNS) (see [RFC1034] and [BCP219]) using SVCB or HTTPS records 📡 Each SVCB record describes one "alternative endpoint" and carries a bunch of "SvcParams." Those are extensible, so new kinds of info can keep getting added for clients. And clients can use SvcParams to level up the privacy, security, and performance of their connection to that endpoint 🫶
this spec defines a brand new SvcParam that turns on TLS Encrypted ClientHello [ECH] for TLS-based protocols 🔥 It works in SVCB, HTTPS, or any future SVCB-compatible DNS record, and it's meant to be the primary bootstrap mechanism for ECH. main character energy 👑
2. Terminology 💅
the all-caps words are the important ones here. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" only count as BCP 14 [RFC2119] [RFC8174] keywords when they show up in all capitals like that ✨ Anywhere else they're just regular words, so no accidental requirements 🙈
3. SvcParam for ECH Configuration 🎀
the "ech" SvcParamKey carries the ECH configuration of an alternative endpoint. It applies to every scheme that uses TLS-based protocols (including DTLS [RFC9147] and QUIC version 1 [RFC9001]), unless something else says otherwise 🦋
in wire format, the value is an ECHConfigList (Section 4 of [ECH]), and that includes the redundant length prefix. In presentation format, the value is that ECHConfigList in Base 64 encoding (Section 4 of [RFC4648]). Base 64 is used because it makes integration with TLS server software easier 🌈 For simpler parsing, this SvcParam MUST NOT contain escape sequences. this is a hard no, bestie 🚫
here's an example, with line wrapping per [RFC8792] 🍓
ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAE\
AAWQVZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="Figure 1: ECH SvcParam with a public_name of "ech-sites.example.net"
4. Requirements for Server Deployments 🧁
when you publish a record with an "ech" parameter, you MUST make sure that all IP addresses of TargetName belong to servers that either have access to the matching private key or are authoritative for the public name. (For the public name rules, see Sections 6.1.7 and 8.1.1 of [ECH].) If you skip this, connections will fail entirely 💀
these servers SHOULD support a protocol version that's compatible with ECH. At the time of writing, the compatible versions are TLS 1.3, DTLS 1.3, and QUIC version 1. If the server doesn't support a compatible version, every connection attempt has to be retried, which delays the connection and wastes resources 😭
5. Requirements for Client Implementations 💖
this section is all about how clients should use ECH configurations that come through SVCB or HTTPS records 🫶
5.1. Disabling Fallback 🚫
the SVCB-optional client behavior from Section 3 of [SVCB] lets clients fall back to a direct connection if all the SVCB options fail. That's a no for ECH, because fallback would cancel out the privacy benefits 🙅♀️ So ECH-capable, SVCB-optional clients MUST switch to SVCB-reliant connection establishment if SVCB resolution succeeded (as defined in Section 3 of [SVCB]) and every alternative endpoint has an "ech" SvcParam.
5.2. ClientHello Construction 🦋
when ECH is in use, the TLS ClientHello gets split into an unencrypted "outer" ClientHello and an encrypted "inner" ClientHello 🔐 The outer one is an ECH implementation detail, and its contents are controlled by the ECHConfig in accordance with [ECH]. The inner ClientHello is what actually sets up the connection to the service, so other SVCB parameters can influence it. For example, the Application-Layer Protocol Negotiation (ALPN) rules in Section 7.1.2 of [SVCB] only apply to the inner ClientHello. Same vibe with the Server Name Indication (SNI): it's the inner ClientHello's SNI that identifies the desired service 🎀
5.3. Performance Optimizations ⚡
before the client gets the SVCB records, it has no idea whether they contain an "ech" parameter. As a latency optimization, clients MAY prefetch DNS records that only get used if that parameter is missing (so, only in SVCB-optional mode) ✨
the "ech" SvcParam changes the contents of the TLS ClientHello when it's present. So clients that support ECH MUST NOT issue any TLS ClientHello until SVCB resolution has completed. (See Section 5.1 of [SVCB].) no peeking early, periodt 🙈
part 1 of 2 🌈
8. Security Considerations 🔐
okay bestie, this is the serious section, so buckle up 💀. A SVCB RRSet where some RRs have ech and some don't is vulnerable to a downgrade attack. A network intermediary can block connections to the endpoints that support ECH, and then the client just falls back to a non-ECH endpoint 😭. This configuration is NOT RECOMMENDED, but it may be unavoidable when you're mixing endpoints from different providers or doing a staged rollout 🫠. If zone owners do run a mixed setup anyway, they SHOULD make the RRs with ech more preferred (aka a lower SvcPriority value) than the ones without. That way ECH gets used as often as possible when there's no active adversary 💅✨.
When Encrypted ClientHello is deployed, the inner TLS SNI is hidden from attackers, and that's the whole point 🙈🔒. BUT there are still lots of ways an attacker could infer the SNI anyway 👀. Even in an ideal deployment, ECH's protection only covers an anonymity set made up of all the ECH-enabled server domains behind a given client-facing server that share an ECH configuration. An attacker who can list that whole set can always guess the encrypted SNI with a probability of at least 1/K, where K is the number of domains in the set. Some attackers can get way more accurate with traffic analysis, popularity weighting, and other tricks (see [CLINIC] if you want the spooky details) 🫣.
ECH keeps TLS from revealing the SNI, but the same info is still sitting in the DNS queries used to resolve the server's hostname 😬. This specification does not hide the server name from the DNS resolver. If DNS messages go between the client and resolver without authenticated encryption, an attacker on that path can still learn the destination server name. A similar attack applies if the client can be linked to a request from the resolver to a DNS authority 🕵️♀️.
An attacker who can stop SVCB resolution can deny clients any of the security benefits that come with it 🚫. A hostile recursive resolver can always deny service to SVCB queries, and network intermediaries can often stop resolution too, even when the client and recursive resolver validate DNSSEC [RFC9364] and use a secure transport. These downgrade attacks can stop a client from ever knowing that "ech" is configured, which could end with the client sending the ClientHello in cleartext 💀💀. To prevent downgrades, Section 3.1 of [SVCB] recommends that clients abandon the connection attempt when such an attack is detected. Don't let the attacker win, periodt 👑.
9. IANA Considerations 🎀
IANA has modified the entry for "ech" in the "DNS SVCB Service Parameter Keys (SvcParamKeys)" registry in the "DNS Service Bindings (SVCB)" registry group, and here's the tea ☕:
+========+======+====================+============+===========+
| Number | Name | Meaning | Change | Reference |
| | | | Controller | |
+========+======+====================+============+===========+
| 5 | ech | TLS Encrypted | IETF | RFC 9848 |
| | | ClientHello Config | | |
+--------+------+--------------------+------------+-----------+Table 1
10. References 📚
10.1. Normative References
[ECH] 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/info/rfc9849.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, https://www.rfc-editor.org/info/rfc1034.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, https://www.rfc-editor.org/info/rfc4648.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, https://www.rfc-editor.org/info/rfc9364.
[SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, https://www.rfc-editor.org/info/rfc9460.
10.2. Informative References
[BCP219] Best Current Practice 219, https://www.rfc-editor.org/info/bcp219. At the time of writing, this BCP comprises the following:
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, https://www.rfc-editor.org/info/rfc9499.
[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis", Lecture Notes in Computer Science, vol. 8555, pp. 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014, https://doi.org/10.1007/978-3-319-08506-7_8.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, https://www.rfc-editor.org/info/rfc7838.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, https://www.rfc-editor.org/info/rfc8792.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, https://www.rfc-editor.org/info/rfc9001.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, https://www.rfc-editor.org/info/rfc9147.
Authors' Addresses 🦋
Ben Schwartz Meta Platforms, Inc. Email: ietf@bemasc.net
Mike Bishop Akamai Technologies Email: mbishop@evequefou.be
Erik Nygren Akamai Technologies Email: erik+ietf@nygren.org
📦 where this page comes from
- ietf: rfc9848 2026-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms