<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-tls-svcb-ech-08" number="9848" updates="" obsoletes="" submissionType="IETF" xml:lang="en" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" prepTime="2026-03-03T13:51:38" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9848" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ECH in SVCB">Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings</title>
    <seriesInfo name="RFC" value="9848" stream="IETF"/>
    <author initials="B." surname="Schwartz" fullname="Ben Schwartz">
      <organization showOnFrontPage="true">Meta Platforms, Inc.</organization>
      <address>
        <email>ietf@bemasc.net</email>
      </address>
    </author>
    <author initials="M." surname="Bishop" fullname="Mike Bishop">
      <organization showOnFrontPage="true">Akamai Technologies</organization>
      <address>
        <email>mbishop@evequefou.be</email>
      </address>
    </author>
    <author initials="E." surname="Nygren" fullname="Erik Nygren">
      <organization showOnFrontPage="true">Akamai Technologies</organization>
      <address>
        <email>erik+ietf@nygren.org</email>
      </address>
    </author>
    <date month="03" year="2026"/>
    <area>SEC</area>
    <workgroup>tls</workgroup>
    <keyword>ech SvcParamKey</keyword>
    <keyword>ech SvcParam</keyword>
    <keyword>ECH</keyword>
    <keyword>SVCB</keyword>
    <keyword>HTTPS Resource Records</keyword>
    <keyword>TLS SNI</keyword>
    <keyword>Encrypted SNI</keyword>
    <keyword>Server Name Indication</keyword>
    <keyword>Encrypted Server Name Indication</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">To use TLS Encrypted ClientHello (ECH), the client needs to learn the ECH configuration for a server before it attempts a connection to the server.  This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS resource record (RR).</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9848" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2026 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-svcparam-for-ech-configurat">SvcParam for ECH Configuration</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-server-dep">Requirements for Server Deployments</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-client-imp">Requirements for Client Implementations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-disabling-fallback">Disabling Fallback</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-clienthello-construction">ClientHello Construction</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-performance-optimizations">Performance Optimizations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-http-alt-s">Interaction with HTTP Alt-Svc</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-examples">Examples</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="overview" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-overview">Overview</name>
      <t indent="0" pn="section-1-1">The Service Bindings framework <xref target="RFC9460" format="default" sectionFormat="of" derivedContent="SVCB"/> allows server operators to publish a detailed description of their service in the Domain Name System (DNS) (see <xref target="RFC1034" format="default" sectionFormat="of" derivedContent="RFC1034"/> and <xref target="BCP219" format="default" sectionFormat="of" derivedContent="BCP219"/>) using SVCB or HTTPS records.  Each SVCB record describes a single "alternative endpoint" and contains a collection of "SvcParams" that can be extended with new kinds of information that may be of interest to a client.  Clients can use the SvcParams to improve the privacy, security, and performance of their connection to this endpoint.</t>
      <t indent="0" pn="section-1-2">This specification defines a new SvcParam to enable the use of TLS Encrypted ClientHello <xref target="RFC9849" format="default" sectionFormat="of" derivedContent="ECH"/> in TLS-based protocols.  This SvcParam can be used in SVCB, HTTPS, or any future SVCB-compatible DNS records and is intended to serve as the primary bootstrap mechanism for ECH.</t>
    </section>
    <section anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here. 
</t>
    </section>
    <section anchor="ech-param" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-svcparam-for-ech-configurat">SvcParam for ECH Configuration</name>
      <t indent="0" pn="section-3-1">The "ech" SvcParamKey conveys the ECH configuration of an alternative endpoint.  It is applicable to all schemes that use TLS-based protocols (including DTLS <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/> and QUIC version 1 <xref target="RFC9001" format="default" sectionFormat="of" derivedContent="RFC9001"/>) unless otherwise specified.</t>
      <t indent="0" pn="section-3-2">In wire format, the value of the parameter is an ECHConfigList (<xref section="4" sectionFormat="of" target="RFC9849" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9849#section-4" derivedContent="ECH"/>), including the redundant length prefix.  In presentation format, the value is the ECHConfigList in Base 64 encoding (<xref section="4" sectionFormat="of" target="RFC4648" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4648#section-4" derivedContent="RFC4648"/>).  Base 64 is used here to simplify integration with TLS server software.  To enable simpler parsing, this SvcParam <bcp14>MUST NOT</bcp14> contain escape sequences.</t>
      <t indent="0" pn="section-3-3">This example uses line wrapping per <xref target="RFC8792" format="default" sectionFormat="of" derivedContent="RFC8792"/>.</t>
      <figure align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-ech-svcparam-with-a-public_">ECH SvcParam with a public_name of "ech-sites.example.net"</name>
        <sourcecode type="" markers="false" pn="section-3-4.1">
ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAE\
AAWQVZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="</sourcecode>
      </figure>
    </section>
    <section anchor="requirements-for-server-deployments" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-requirements-for-server-dep">Requirements for Server Deployments</name>
      <t indent="0" pn="section-4-1">When publishing a record containing an "ech" parameter, the publisher <bcp14>MUST</bcp14> ensure that all IP addresses of TargetName correspond to servers that have access to the corresponding private key or are authoritative for the public name. (See Sections <xref target="RFC9849" section="6.1.7" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9849#section-6.1.7" derivedContent="ECH"/> and <xref target="RFC9849" section="8.1.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9849#section-8.1.1" derivedContent="ECH"/> of <xref target="RFC9849" format="default" sectionFormat="of" derivedContent="ECH"/> for requirements related to the public name.)  Otherwise, connections will fail entirely.</t>
      <t indent="0" pn="section-4-2">These servers <bcp14>SHOULD</bcp14> support a protocol version that is 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 does not support a compatible version, each connection attempt will have to be retried, delaying the connection and wasting resources.</t>
    </section>
    <section anchor="ech-client-behavior" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-requirements-for-client-imp">Requirements for Client Implementations</name>
      <t indent="0" pn="section-5-1">This section describes client behavior in using ECH configurations provided in SVCB or HTTPS records.</t>
      <section anchor="disabling-fallback" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-disabling-fallback">Disabling Fallback</name>
        <t indent="0" pn="section-5.1-1">The SVCB-optional client behavior specified in <xref section="3" sectionFormat="of" target="RFC9460" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9460#section-3" derivedContent="SVCB"/> permits clients to fall back to a direct connection if all SVCB options fail.  This behavior is not suitable for ECH, because fallback would negate the privacy benefits of ECH.  Accordingly, ECH-capable, SVCB-optional clients <bcp14>MUST</bcp14> switch to SVCB-reliant connection establishment if SVCB resolution succeeded (as defined in <xref section="3" sectionFormat="of" target="RFC9460" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9460#section-3" derivedContent="SVCB"/>) and all alternative endpoints have an "ech" SvcParam.</t>
      </section>
      <section anchor="clienthello-construction" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-clienthello-construction">ClientHello Construction</name>
        <t indent="0" pn="section-5.2-1">When ECH is in use, the TLS ClientHello is divided into an unencrypted "outer" and an encrypted "inner" ClientHello.  The outer ClientHello is an implementation detail of ECH, and its contents are controlled by the ECHConfig in accordance with <xref target="RFC9849" format="default" sectionFormat="of" derivedContent="ECH"/>.  The inner ClientHello is used for establishing a connection to the service, so its contents may be influenced by other SVCB parameters.  For example, the requirements related to Application-Layer Protocol Negotiation (ALPN) protocol identifiers in <xref section="7.1.2" sectionFormat="of" target="RFC9460" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9460#section-7.1.2" derivedContent="SVCB"/> apply only to the inner ClientHello.  Similarly, it is the inner ClientHello whose Server Name Indication (SNI) identifies the desired service.</t>
      </section>
      <section anchor="performance-optimizations" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-performance-optimizations">Performance Optimizations</name>
        <t indent="0" pn="section-5.3-1">Prior to retrieving the SVCB records, the client does not know whether they contain an "ech" parameter.  As a latency optimization, clients <bcp14>MAY</bcp14> prefetch DNS records that will only be used if this parameter is not present (i.e., only in SVCB-optional mode).</t>
        <t indent="0" pn="section-5.3-2">The "ech" SvcParam alters the contents of the TLS ClientHello if it is present.  Therefore, clients that support ECH <bcp14>MUST NOT</bcp14> issue any TLS ClientHello until after SVCB resolution has completed.  (See <xref section="5.1" sectionFormat="of" target="RFC9460" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9460#section-5.1" derivedContent="SVCB"/>.)</t>
      </section>
    </section>
    <section anchor="interaction-with-http-alt-svc" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-interaction-with-http-alt-s">Interaction with HTTP Alt-Svc</name>
      <t indent="0" pn="section-6-1">HTTP clients that implement both HTTP Alt-Svc <xref target="RFC7838" format="default" sectionFormat="of" derivedContent="RFC7838"/> and the HTTPS record type <xref target="RFC9460" format="default" sectionFormat="of" derivedContent="SVCB"/> can use them together, provided that they only perform connection attempts that are "consistent" with both sets of parameters (<xref section="9.3" sectionFormat="of" target="RFC9460" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9460#section-9.3" derivedContent="SVCB"/>).  At the time of writing, there is no defined parameter related to ECH for Alt-Svc.  Accordingly, a connection attempt that uses ECH is considered "consistent" with an Alt-Svc field value that does not mention ECH.</t>
      <t indent="0" pn="section-6-2">Origins that publish an "ech" SvcParam in their HTTPS record <bcp14>SHOULD</bcp14> also publish an HTTPS record with the "ech" SvcParam for every alt-authority offered in its Alt-Svc field values.  Otherwise, clients might reveal the name of the server in an unencrypted ClientHello to an alt-authority.</t>
      <t indent="0" pn="section-6-3">If all HTTPS records for an alt-authority contain "ech" SvcParams, the client <bcp14>MUST</bcp14> adopt SVCB-reliant behavior (as in <xref target="disabling-fallback" format="default" sectionFormat="of" derivedContent="Section 5.1"/>) for that resource record set (RRSet).  This precludes the use of certain connections that Alt-Svc would otherwise allow, as discussed in <xref section="9.3" sectionFormat="of" target="RFC9460" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9460#section-9.3" derivedContent="SVCB"/>.</t>
    </section>
    <section anchor="examples" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-examples">Examples</name>
      <figure align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-simple-example-zone-with-th">Simple Example Zone with the Same Configuration on the Apex and Web Domain</name>
        <sourcecode type="dns-rr" markers="false" pn="section-7-1.1">
$ORIGIN simple.example. ; Simple example zone
@ 300 IN A     192.0.2.1
         AAAA  2001:db8::1
         HTTPS 1 . ech=ABC...
www 300 IN A 192.0.2.1
           AAAA 2001:db8::1
           HTTPS 1 . ech=ABC...</sourcecode>
      </figure>
      <t indent="0" pn="section-7-2">The example above is compatible with clients that do or do not support HTTPS records.</t>
      <figure align="left" suppress-title="false" pn="figure-3">
        <name slugifiedName="name-service-that-allows-clients">Service That Allows Clients to Choose Between Two Server Pools with Different ECH Configurations</name>
        <sourcecode type="dns-rr" markers="false" pn="section-7-3.1">
$ORIGIN heterogeneous.example. ; Example zone with 2 pools of servers
pool1 300 IN    A    192.0.2.1
                AAAA 2001:db8:1::a
pool2 300 IN    A    192.0.2.2
                AAAA 2001:db8:2::a
service 300 IN SVCB 1 pool1 ech=ABC...
               SVCB 1 pool2 ech=DEF...
               A 192.0.2.1
               A 192.0.2.2
               AAAA 2001:db8:1::a
               AAAA 2001:db8:2::a</sourcecode>
      </figure>
      <figure align="left" suppress-title="false" pn="figure-4">
        <name slugifiedName="name-ech-usage-pattern-for-an-al">ECH Usage Pattern for an Aliasing-Based CDN</name>
        <sourcecode type="dns-rr" markers="false" pn="section-7-4.1">
$ORIGIN cdn.example. ; CDN operator zone
pool 300 IN A 192.0.2.1
            AAAA 2001:db8::1
            HTTPS 1 . ech=ABC...

$ORIGIN customer.example. ; CDN customer's zone
@   3600 IN HTTPS 0 pool.cdn.example.
; Apex IP records for compatibility with clients that do not support
; HTTPS records.
@   300  IN A    192.0.2.1
            AAAA 2001:db8::1

www 300  IN CNAME pool.cdn.example.</sourcecode>
      </figure>
      <figure align="left" suppress-title="false" pn="figure-5">
        <name slugifiedName="name-a-domain-that-is-only-reach">A Domain That is Only Reachable Using ECH</name>
        <sourcecode type="dns-rr" markers="false" pn="section-7-5.1">
$ORIGIN secret.example. ; High confidentiality zone
www     3600 IN HTTPS 1 backend ech=ABC... mandatory=ech
backend 300  IN A     192.0.2.1
                AAAA  2001:db8::1</sourcecode>
      </figure>
      <figure align="left" suppress-title="false" pn="figure-6">
        <name slugifiedName="name-multi-cdn-configuration-usi">Multi-CDN Configuration Using Server-Side Selection</name>
        <sourcecode type="dns-rr" markers="false" pn="section-7-6.1">
$ORIGIN cdn1.example. ; First CDN operator zone
pool 300 IN A     192.0.2.1
            AAAA  2001:db8::1
            HTTPS 1 . ech=ABC...

$ORIGIN cdn2.example. ; Second CDN operator zone
pool 300 IN A     192.0.2.2
            AAAA  2001:db8::2
            HTTPS 1 . ech=DEF...

;; Multi-CDN customer zone (version 1)
$ORIGIN customer.example.
@   3600 IN HTTPS 0 pool.cdn1.example.
; Apex IP records for compatibility with clients that do not support
; HTTPS records.
@   300  IN A    192.0.2.1
            AAAA 2001:db8::1
www 3600  IN CNAME pool.cdn1.example.

;; Multi-CDN customer zone (version 2)
@   3600 IN HTTPS 0 pool.cdn2.example.
@   300  IN A    192.0.2.2
            AAAA 2001:db8::2
www 3600  IN CNAME pool.cdn2.example.</sourcecode>
      </figure>
      <figure align="left" suppress-title="false" pn="figure-7">
        <name slugifiedName="name-example-of-a-dns-server-tha">Example of a DNS Server That Supports ECH</name>
        <sourcecode type="dns-rr" markers="false" pn="section-7-7.1">
$ORIGIN dns.example. ; DNS server example.
@    3600 IN A     192.0.2.1
             AAAA  2001:db8::1
             HTTPS 1 . ech=ABC... alpn=h3 dohpath=/q{?dns}

_dns 3600 IN SVCB  1 @ ech=ABC... alpn=dot,doq,h3 dohpath=/q{?dns}</sourcecode>
      </figure>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">A SVCB RRSet containing some RRs with "ech" and some without is vulnerable to a downgrade attack: A network intermediary can block connections to the endpoints that support ECH, causing the client to fall back to a non-ECH endpoint.  This configuration is <bcp14>NOT RECOMMENDED</bcp14>, but it may be unavoidable when combining endpoints from different providers or conducting a staged rollout. Zone owners who do use such a mixed configuration <bcp14>SHOULD</bcp14> mark the RRs with "ech" as more preferred (i.e., lower SvcPriority value) than those without, in order to maximize the likelihood that ECH will be used in the absence of an active adversary.</t>
      <t indent="0" pn="section-8-2">When Encrypted ClientHello is deployed, the inner TLS SNI is protected from disclosure to attackers. However, there are still many ways that an attacker might infer the SNI. Even in an idealized deployment, ECH's protection is limited to an anonymity set consisting of all the ECH-enabled server domains supported by a given client-facing server that share an ECH configuration. An attacker who can enumerate this 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 may achieve much greater accuracy using traffic analysis, popularity weighting, and other mechanisms (e.g., see <xref target="CLINIC" format="default" sectionFormat="of" derivedContent="CLINIC"/>).</t>
      <t indent="0" pn="section-8-3">ECH ensures that TLS does not disclose the SNI, but the same information is also present in the DNS queries used to resolve the server's hostname.  This specification does not conceal the server name from the DNS resolver.  If DNS messages are sent between the client and resolver without authenticated encryption, an attacker on this path can also 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.</t>
      <t indent="0" pn="section-8-4">An attacker who can prevent SVCB resolution can deny clients any associated security benefits. A hostile recursive resolver can always deny service to SVCB queries, but network intermediaries can often prevent resolution as well, even when the client and recursive resolver validate DNSSEC <xref target="RFC9364" format="default" sectionFormat="of" derivedContent="RFC9364"/> and use a secure transport. These downgrade attacks can prevent a client from being aware that "ech" is configured, which could result in the client sending the ClientHello in cleartext. To prevent downgrades, <xref section="3.1" sectionFormat="of" target="RFC9460" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9460#section-3.1" derivedContent="SVCB"/> recommends that clients abandon the connection attempt when such an attack is detected.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">IANA has modified the entry for "ech" in the "DNS SVCB Service Parameter Keys (SvcParamKeys)" registry in the "DNS Service Bindings (SVCB)" registry group as follows:</t>
      <table align="center" pn="table-1">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Number</th>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">Meaning</th>
            <th align="left" colspan="1" rowspan="1">Change Controller</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">5</td>
            <td align="left" colspan="1" rowspan="1">ech</td>
            <td align="left" colspan="1" rowspan="1">TLS Encrypted ClientHello Config</td>
            <td align="left" colspan="1" rowspan="1">IETF</td>
            <td align="left" colspan="1" rowspan="1">RFC 9848</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9460" to="SVCB"/>
    <displayreference target="RFC9849" to="ECH"/>
    <references anchor="sec-combined-references" pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC9849" target="https://www.rfc-editor.org/info/rfc9849" quoteTitle="true" derivedAnchor="ECH">
          <front>
            <title>TLS Encrypted Client Hello</title>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization showOnFrontPage="true">Independent</organization>
            </author>
            <author initials="K." surname="Oku" fullname="Kazuho Oku">
              <organization showOnFrontPage="true">Fastly</organization>
            </author>
            <author initials="N." surname="Sullivan" fullname="Nick Sullivan">
              <organization showOnFrontPage="true">Cryptography Consulting LLC</organization>
            </author>
            <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
              <organization showOnFrontPage="true">Cloudflare</organization>
            </author>
            <date month="March" year="2026"/>
          </front>
          <seriesInfo name="RFC" value="9849"/>
          <seriesInfo name="DOI" value="10.17487/RFC9849"/>
        </reference>
        <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034" quoteTitle="true" derivedAnchor="RFC1034">
          <front>
            <title>Domain names - concepts and facilities</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
            <date month="November" year="1987"/>
            <abstract>
              <t indent="0">This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1034"/>
          <seriesInfo name="DOI" value="10.17487/RFC1034"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" quoteTitle="true" derivedAnchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t indent="0">This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9364" target="https://www.rfc-editor.org/info/rfc9364" quoteTitle="true" derivedAnchor="RFC9364">
          <front>
            <title>DNS Security Extensions (DNSSEC)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="February" year="2023"/>
            <abstract>
              <t indent="0">This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="237"/>
          <seriesInfo name="RFC" value="9364"/>
          <seriesInfo name="DOI" value="10.17487/RFC9364"/>
        </reference>
        <reference anchor="RFC9460" target="https://www.rfc-editor.org/info/rfc9460" quoteTitle="true" derivedAnchor="SVCB">
          <front>
            <title>Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)</title>
            <author fullname="B. Schwartz" initials="B." surname="Schwartz"/>
            <author fullname="M. Bishop" initials="M." surname="Bishop"/>
            <author fullname="E. Nygren" initials="E." surname="Nygren"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9460"/>
          <seriesInfo name="DOI" value="10.17487/RFC9460"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <referencegroup anchor="BCP219" target="https://www.rfc-editor.org/info/bcp219" derivedAnchor="BCP219">
          <reference anchor="RFC9499" target="https://www.rfc-editor.org/info/rfc9499" quoteTitle="true">
            <front>
              <title>DNS Terminology</title>
              <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
              <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
              <date month="March" year="2024"/>
              <abstract>
                <t indent="0">The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
                <t indent="0">This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="219"/>
            <seriesInfo name="RFC" value="9499"/>
            <seriesInfo name="DOI" value="10.17487/RFC9499"/>
          </reference>
        </referencegroup>
        <reference anchor="CLINIC" quoteTitle="true" target="https://doi.org/10.1007/978-3-319-08506-7_8" derivedAnchor="CLINIC">
          <front>
            <title>I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis</title>
            <author fullname="Brad Miller" initials="B." surname="Miller">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="Ling Huang" initials="L." surname="Huang">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="A. D. Joseph" initials="A." surname="Joseph">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="J. D. Tygar" initials="J." surname="Tygar">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014"/>
          </front>
          <seriesInfo name="DOI" value="10.1007/978-3-319-08506-7_8"/>
          <refcontent>Lecture Notes in Computer Science, vol. 8555, pp. 143-163</refcontent>
        </reference>
        <reference anchor="RFC7838" target="https://www.rfc-editor.org/info/rfc7838" quoteTitle="true" derivedAnchor="RFC7838">
          <front>
            <title>HTTP Alternative Services</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="P. McManus" initials="P." surname="McManus"/>
            <author fullname="J. Reschke" initials="J." surname="Reschke"/>
            <date month="April" year="2016"/>
            <abstract>
              <t indent="0">This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7838"/>
          <seriesInfo name="DOI" value="10.17487/RFC7838"/>
        </reference>
        <reference anchor="RFC8792" target="https://www.rfc-editor.org/info/rfc8792" quoteTitle="true" derivedAnchor="RFC8792">
          <front>
            <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="June" year="2020"/>
            <abstract>
              <t indent="0">This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8792"/>
          <seriesInfo name="DOI" value="10.17487/RFC8792"/>
        </reference>
        <reference anchor="RFC9001" target="https://www.rfc-editor.org/info/rfc9001" quoteTitle="true" derivedAnchor="RFC9001">
          <front>
            <title>Using TLS to Secure QUIC</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="S. Turner" initials="S." role="editor" surname="Turner"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document describes how Transport Layer Security (TLS) is used to secure QUIC.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9001"/>
          <seriesInfo name="DOI" value="10.17487/RFC9001"/>
        </reference>
        <reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9147" quoteTitle="true" derivedAnchor="RFC9147">
          <front>
            <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
            <date month="April" year="2022"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t>
              <t indent="0">This document obsoletes RFC 6347.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9147"/>
          <seriesInfo name="DOI" value="10.17487/RFC9147"/>
        </reference>
      </references>
    </references>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="B." surname="Schwartz" fullname="Ben Schwartz">
        <organization showOnFrontPage="true">Meta Platforms, Inc.</organization>
        <address>
          <email>ietf@bemasc.net</email>
        </address>
      </author>
      <author initials="M." surname="Bishop" fullname="Mike Bishop">
        <organization showOnFrontPage="true">Akamai Technologies</organization>
        <address>
          <email>mbishop@evequefou.be</email>
        </address>
      </author>
      <author initials="E." surname="Nygren" fullname="Erik Nygren">
        <organization showOnFrontPage="true">Akamai Technologies</organization>
        <address>
          <email>erik+ietf@nygren.org</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
