<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" 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" version="3"><!-- xml2rfc v2v3 conversion 3.28.1 --><front> <title abbrev="ECH in SVCB">Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings</title> <seriesInfoname="Internet-Draft" value="draft-ietf-tls-svcb-ech-08"/>name="RFC" value="9848"/> <author initials="B." surname="Schwartz" fullname="Ben Schwartz"> <organization>Meta Platforms, Inc.</organization> <address> <email>ietf@bemasc.net</email> </address> </author> <author initials="M." surname="Bishop" fullname="Mike Bishop"> <organization>Akamai Technologies</organization> <address> <email>mbishop@evequefou.be</email> </address> </author> <author initials="E." surname="Nygren" fullname="Erik Nygren"> <organization>Akamai Technologies</organization> <address> <email>erik+ietf@nygren.org</email> </address> </author><date/> <area>Security</area> <workgroup>TLS Working Group</workgroup> <keyword>Internet-Draft</keyword><date month="December" year="2025"/> <area>SEC</area> <workgroup>tls</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><?line 36?><t>To use TLS Encrypted ClientHello(ECH)(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> </front> <middle><?line 40?><section anchor="overview"> <name>Overview</name> <t>The Service Bindings framework <xreftarget="SVCB"/>target="RFC9460"/> allows server operators to publish a detailed description of their service in the Domain Name System (DNS) (see <xreftarget="RFC1034"/>,target="RFC1034"/> and <xref target="BCP219"/>) using SVCB or HTTPS records. Each SVCB record describes a single "alternativeendpoint",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>This specification defines a new SvcParam to enable the use of TLS Encrypted ClientHello <xreftarget="ECH"/>target="RFC9849"/> in TLS-based protocols. This SvcParam can be used in SVCB,HTTPSHTTPS, or any future SVCB-compatible DNSrecords,records and is intended to serve as the primary bootstrap mechanism for ECH.</t> </section> <section anchor="terminology"> <name>Terminology</name><t>The<t> 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 inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <section anchor="ech-param"> <name>SvcParam for ECHconfiguration</name>Configuration</name> <t>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"/> and QUIC version 1 <xref target="RFC9001"/>) unless otherwise specified.</t> <t>In wire format, the value of the parameter is an ECHConfigList (<xref section="4" sectionFormat="of"target="ECH"/>),target="RFC9849"/>), including the redundant length prefix. In presentation format, the value is the ECHConfigList in Base 64Encodingencoding (<xref section="4" sectionFormat="of" target="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> <figure> <name>ECH SvcParam with a public_name of"ech-sites.example.net".</name> <artwork><![CDATA["ech-sites.example.net"</name> <sourcecode type=""><![CDATA[ ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQVZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA=" ]]></artwork>VZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="]]></sourcecode> </figure> </section> <section anchor="requirements-for-server-deployments"> <name>Requirements forserver deployments</name>Server Deployments</name> <t>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 <xreftarget="ECH"target="RFC9849" section="6.1.7" sectionFormat="bare"/> and <xreftarget="ECH"target="RFC9849" section="8.1.1" sectionFormat="bare"/> of <xreftarget="ECH"/>target="RFC9849"/> for requirements related to the public name.) Otherwise, connections will fail entirely.</t> <t>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"> <name>Requirements forclient implementations</name>Client Implementations</name> <t>This section describes client behavior in using ECH configurations provided in SVCB or HTTPS records.</t> <section anchor="disabling-fallback"> <name>Disablingfallback</name>Fallback</name> <t>The SVCB-optional client behavior specified in(<xref<xref section="3" sectionFormat="of"target="SVCB"/>)target="RFC9460"/> 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-capableECH-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="SVCB"/>)target="RFC9460"/>) and all alternative endpoints have an "ech" SvcParam.</t> </section> <section anchor="clienthello-construction"> <name>ClientHelloconstruction</name>Construction</name> <t>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 <xreftarget="ECH"/>.target="RFC9849"/>. 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 toALPNApplication-Layer Protocol Negotiation (ALPN) protocol identifiers in <xref section="7.1.2" sectionFormat="of"target="SVCB"/>target="RFC9460"/> 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"> <name>Performanceoptimizations</name>Optimizations</name> <t>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.(i.e., only in SVCB-optional mode).</t> <t>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="SVCB"/>).</t>target="RFC9460"/>.)</t> </section> </section> <section anchor="interaction-with-http-alt-svc"> <name>Interaction with HTTP Alt-Svc</name> <t>HTTP clients that implement both HTTP Alt-Svc <xref target="RFC7838"/> and the HTTPS record type <xreftarget="SVCB"/>target="RFC9460"/> 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="SVCB"/>).target="RFC9460"/>). 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-SvcField Valuefield value that does not mention ECH.</t> <t>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-SvcField Values.field values. Otherwise, clients might reveal the name of the server in an unencrypted ClientHello to an alt-authority.</t> <t>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"/>) for thatRRSet.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="SVCB"/>.</t>target="RFC9460"/>.</t> </section> <section anchor="examples"> <name>Examples</name><figure> <name>Simple<!--[rfced] FYI - We moved the second sentence in the title of Figure 2 out of the title. It now directly follows the figure. Please review and let us know of any objections. Original: Figure 2: Simple example zone with the same configuration on the apex and web domain. It is compatible with clients that do or do not support HTTPSrecords.</name> <artwork><![CDATA[records. Current: Figure 2: Simple Example Zone with the Same Configuration on the Apex and Web Domain The example above is compatible with clients that do or do not support HTTPS records. --> <figure> <name>Simple Example Zone with the Same Configuration on the Apex and Web Domain</name> <sourcecode type=""><![CDATA[ $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... ]]></artwork>ech=ABC...]]></sourcecode> </figure> <t>The example above is compatible with clients that do or do not support HTTPS records.</t> <figure> <name>Servicethat allows clientsThat Allows Clients tochoose between two server poolsChoose Between Two Server Pools withdifferentDifferent ECHconfigurations.</name> <artwork><![CDATA[Configurations</name> <sourcecode type=""><![CDATA[ $ORIGIN heterogeneous.example. ; Example zone with two 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 AAAA2001:db8:2::a ]]></artwork>2001:db8:2::a]]></sourcecode> </figure> <figure> <name>ECHusage patternUsage Pattern for analiasing-based CDN.</name> <artwork><![CDATA[Aliasing-Based CDN</name> <sourcecode type=""><![CDATA[ $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 CNAMEpool.cdn.example. ]]></artwork>pool.cdn.example.]]></sourcecode> </figure> <figure> <name>Adomain thatDomain That isonly reachable using ECH.</name> <artwork><![CDATA[Only Reachable Using ECH</name> <sourcecode type=""><![CDATA[ $ORIGIN secret.example. ; High confidentiality zone www 3600 IN HTTPS 1 backend ech=ABC... mandatory=ech backend 300 IN A 192.0.2.1 AAAA2001:db8::1 ]]></artwork>2001:db8::1]]></sourcecode> </figure> <figure> <name>Multi-CDNconfiguration using server-side selection.</name> <artwork><![CDATA[Configuration Using Server-Side Selection</name> <sourcecode type=""><![CDATA[ $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 CNAMEpool.cdn2.example. ]]></artwork>pool.cdn2.example.]]></sourcecode> </figure> <figure> <name>Example of a DNSserver that supports ECH.</name> <artwork><![CDATA[Server That Supports ECH</name> <sourcecode type=""><![CDATA[ $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,h3dohpath=/q{?dns} ]]></artwork>dohpath=/q{?dns}]]></sourcecode> </figure> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>A SVCB RRSet containing some RRs with "ech" and some without is vulnerable to a downgrade attack:aA 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.(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>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(see e.g.,(e.g., see <xref target="CLINIC"/>).</t> <t>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>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"/> and use a secure transport. These downgrade attacks can prevent a client from being aware that "ech" isconfiguredconfigured, which could result in the client sending the ClientHello in cleartext. To prevent downgrades, <xref section="3.1" sectionFormat="of"target="SVCB"/>target="RFC9460"/> recommends that clients abandon the connection attempt when such an attack is detected.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name><t>In<t>IANA has modified the entry for "ech" in the "DNS SVCB Service Parameter Keys (SvcParamKeys)" registryonin the "DNS Service Bindings (SVCB)"page, IANA is instructed to modify the entry for "ech"registry group as follows:</t> <table> <thead> <tr> <th align="left">Number</th> <th align="left">Name</th> <th align="left">Meaning</th> <thalign="left">Format Reference</th> <thalign="left">Change Controller</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">5</td> <td align="left">ech</td> <td align="left">TLS Encrypted ClientHello Config</td> <tdalign="left">(This document)</td> <tdalign="left">IETF</td> <td align="left">RFC 9848</td> </tr> </tbody> </table> </section> </middle> <back> <displayreference target="RFC9460" to="SVCB"/> <displayreference target="RFC9849" to="ECH"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="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>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> <reference anchor="RFC1034"> <front> <title>Domain names - concepts and facilities</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t>This<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/> <!-- [ECH] (RFC9849) draft-ietf-tls-esni-25 companion doc RFCis 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>9849 --> <referenceanchor="ECH">anchor="RFC9849" target="https://www.rfc-editor.org/info/rfc9849"> <front> <title>TLS Encrypted Client Hello</title> <authorfullname="Eric Rescorla"initials="E."surname="Rescorla">surname="Rescorla" fullname="Eric Rescorla"> <organization>Independent</organization> </author> <authorfullname="Kazuho Oku"initials="K."surname="Oku">surname="Oku" fullname="Kazuho Oku"> <organization>Fastly</organization> </author> <authorfullname="Nick Sullivan"initials="N."surname="Sullivan">surname="Sullivan" fullname="Nick Sullivan"> <organization>Cryptography Consulting LLC</organization> </author> <authorfullname="Christopher A. Wood"initials="C. A."surname="Wood">surname="Wood" fullname="Christopher A. Wood"> <organization>Cloudflare</organization> </author> <dateday="14" month="June"month="December" year="2025"/><abstract> <t> This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-25"/> </reference> <reference anchor="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>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="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>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> <seriesInfoname="BCP" value="14"/> <seriesInfoname="RFC"value="8174"/>value="9849"/> <seriesInfo name="DOI"value="10.17487/RFC8174"/> </reference> <reference anchor="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>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="RFC9364"> <front> <title>DNS Security Extensions (DNSSEC)</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="February" year="2023"/> <abstract> <t>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"/>value="10.17487/RFC9849"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="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/> </author> <author fullname="Ling Huang" initials="L." surname="Huang"> <organization/> </author> <author fullname="A. D. Joseph" initials="A." surname="Joseph"> <organization/> </author> <author fullname="J. D. Tygar" initials="J." surname="Tygar"> <organization/> </author> <date year="2014"/> </front> <seriesInfoname="Lecturename="DOI" value="10.1007/978-3-319-08506-7_8"/> <refcontent>Lecture Notes in ComputerScience" value="pp. 143-163"/> <seriesInfo name="DOI" value="10.1007/978-3-319-08506-7_8"/> <seriesInfo name="ISBN" value="["9783319085050", "9783319085067"]"/> <refcontent>Springer International Publishing</refcontent>Science, vol. 8555, pp. 143-163</refcontent> </reference><referencegroup anchor="BCP219" target="https://www.rfc-editor.org/info/bcp219"> <reference anchor="RFC9499" target="https://www.rfc-editor.org/info/rfc9499"> <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>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols,<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0219.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7838.xml"/> </references> </references> <!-- [rfced] Figures 1 andby operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions3 are too long formanythe line limit of theterms usedtext output (72 characters in theDNStext, which means 69 characters within the sourcecode element ina single document.</t> <t>This document updates RFC 2308 by clarifyingthedefinitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions canXML file). Please let us know how these figures should befound 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="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>This document specifies version 1.3 ofupdated. a) Figure 1 - perhaps break at theDatagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications"/" Original: ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQ VZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA=" Perhaps: ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/ KrWPgAEAAEAAWQVZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA=" b) Figure 3 - perhaps change "two" tocommunicate over"2" Original: $ORIGIN heterogeneous.example. ; Example zone with two pools of servers Perhaps: $ORIGIN heterogeneous.example. ; Example zone with 2 pools of servers --> <!-- [rfced] We updated <artwork> to <sourcecode> in theInternetfigures ina way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>The DTLS 1.3 protocolthis document. Currently, the "type" attribute isbased onnot set. Please review theTransport Layer Security (TLS) 1.3 protocoltypes at https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types, andprovides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics oflet us know if one is applicable. If theunderlying transport are preserved bylist does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave theDTLS protocol.</t> <t>This document obsoletes"type" attribute not set. Note: RFC6347.</t> </abstract> </front> <seriesInfo name="RFC" value="9147"/> <seriesInfo name="DOI" value="10.17487/RFC9147"/> </reference> <reference anchor="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>This document describes how Transport Layer Security (TLS) is9460 used type="dns-rr" for sourcecode similar tosecure QUIC.</t> </abstract> </front> <seriesInfo name="RFC" value="9001"/> <seriesInfo name="DOI" value="10.17487/RFC9001"/> </reference> <reference anchor="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>This document specifies "Alternative Services"Figures 2-7 in this document. --> <!-- [rfced] FYI - We have added expansions forHTTP, which allow an origin's resourcesthe following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Application-Layer Protocol Negotiation (ALPN) resource record set (RRSet) --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still beauthoritatively available at a separate network location, possibly accessed withreviewed as adifferent protocol configuration.</t> </abstract> </front> <seriesInfo name="RFC" value="7838"/> <seriesInfo name="DOI" value="10.17487/RFC7838"/> </reference> </references> </references> </back> <!-- ##markdown-source: H4sIAAAAAAAAA81a6XLbRrb+j6foYW7VSDckI1KKLTPjSWhJtlnWFku2x5ma SjWBJtlXWBg0IJqWlWeZZ5knm++cboANkpIz99ewvJBAL2f9ztLd6XSCQhex GogXWVaYIpfzuU6n4vr0SpykYb6cFyoSR7FWafFaxXEmFrqYiePzK3Gl8lsd KvFCpxGmmECOx7m6HYiTo9dCp+Lq/dGLIMrCVCZYPsrlpOhoVUw6RWw65jYc d1Q46+wdBpEsMODueHh9ch+E+DHN8uVAmCIKAj3PB6LIS1P09/ae7fUDmSs5 wN5hmetiGSyy/GaaZ+V8wCR/wE8i/xU9Cm7UEu+jgRilhcpTVXSOiYogMIVM o19lnKXYeKlMMNcD8fciC9vCZHmRq4nBt2VCX/4RBLIsZlk+CEQnEPjo1EBc XXEVzhYyLz7zQ8vlC5U2H2f5VKb6syx0lg7EmSqkuIxlMcnyBFuM0rDLw1Qi dTwQJJ6fxvhhwi7IbWx41oWkzSybe9ud6RvlP8VuAzG8kVhNXEO6aRZnUw3+ vD2SMY//Sd2q30o1ycruWDU2OumK8+U0V6m30Umub/ynf2QjhTnfMkcpT+xi EhSaEu+Qx60a0Oij09H56Gggji9G3d4e/uw9/e7Z08POfme/9wzW8f3ek87T Xw+DoNPpCDkmCw2hwetMlEY9YqY7sMJdUcyUCPmpSJWKjCgyESuZp/yGDDXM 0omeljlrSIA2IYWBZatcjCGdXAldCFkUKpkXBu8wPlUhD8ZatIod3RXieqaN MHMV6okO7XrzPLvVkaKJCcQEUzAJb4JlbtWSTHU7IbWY8P1WS3K4NjimCZI9 CyoQr6+vL69ErkxW5nDEXIWwdrHz9u1u18or0VEUqyD4RlzckreqBSSH/dZd V0xyqJl8Sdzd/YmWf/725dGzgyd79/dCQpwLUwklmyuQmOUsynk5jmFNICmC ZesYOgCzYa7nTHg2Ie50znNpP23lfpzBQlJxjj3F1dJAtmLHKEV7Y9ve3v7B /X0bv358cXTZ7z27v991rK8zTvwaSP5EhjP70snAUjFmwdPMWImWjAkE2PKE SqN5ptOi1RZAApI9yE+tfuPY6Rfkt65uw0sJ4ZgWKJeFCGUKuxDqU4ElwC6j YaoWArAD88IUX3M8JZFLmsKvQIEyBYlOOrsE9dZsDa9NRk0iqvelsTohO7Iv 5rm+leES8OQg0HIArfC2aahWYl+3VZhnxXiXDGHDXCM10SkLjViqaKDJKpXj 2FJAJGKLh10PaoRBPx91jrs13iuTatgStI55nbE0mAOmALlZbCrfqTd0Ui5p lIskbad0ctB0KSZlUcI36U0nzJI56Cf6KC45s7BywaokddYV2GAjFtJUokxk DuVUkW/NR8FEl3znWuWJZoRbWvdBXBEUWIxonb27uoYR8f/i/IK/vz35+d3o 7ckxfb96PTw9rb8EbsTV64t3p8erb6uZRxdnZyfnx3YynorGo6B1NvzobLZ1 cXk9ujgfnrasW4FTBNsyIaxDkCRux8qa3DxXpCNpgsovWKzwrn/9s3fg3K7f I09zPw57T+GDYjFTqd0tS+Ol+wnRLQOkCYBRWgXwAH3NdSFjkjlMapYtUjGD pUN6//t3ksw/BuIv43DeO/ire0AMNx5WMms8ZJltPtmYbIW45dGWbWppNp6v SbpJ7/Bj43cld+/hX36M4Tei0zv88a8BmUxtyc6O1tD97htKfeY04t6aVAsP WvW0NzAwGyHMA/EBDihJ9puQBmcaFWT3UFEMx2a3zVhNJpypRBkLSy58rvui 2NFpGJcUFsQx+ThgmGJB7+ApxQKYAhR1JBAKDNHRq97v7fUYp9NYGeAgqM4X Gls4gFERjGGUAi9hmhYg2ZLErYzLCrIESwS2mjP9KfF9xGyfaqDmzt3dlYOz A5pBKIM922JFMS2Sq6hMIwk3iFU6BTzD/Cf6E8mFArIy8JA62q/RoWt5e/uS q0BI4skBAV7GG23QAhkcPDk4BD3YqBqO5RjDyBkYfoDksZ4s2S2nTpUcQkjS LsKabFIggVSEijXw8ky8hIQonrWtw9dmVvlUFckE/FzOKTdBjoeYYCD933// PYCVPW8NT/7v2+OfX5wMfx5Oh0fDKPrWhO/03ujjS/O39N3o3dObrH8ePfv2 5eFZ/8l8+OqX9/PP373JP1xOhydD+vPh5+D9Lx/Os9O/nc+jV+8/nybvDz5+ 6C3Gr96V4+T93nA4fN7i/e6QvFN58bxFJlyTyyxLmz6Ev1KKycGWnMLoAtSq T5L4pSS41W3dk0u9BSswnoRDJbmVE1ek5nG25MdB8AEIVWUlNldyCYGTCz9L nbfV1mYtwE3DkixNlRqKMOwr5DyjSyGjCOZjFMf5a5lPVcE5DHbA83mWrmJM 7rxsJinehCE5hcsXV6OJGo7nhY0pFNuwpS03dGH9mlityQs5H++KnStOl5wJ GvGk2+s+Ze88xLfeyjt4eu6LLleoP2w0XF92V4iLynHbXvZgoDBIYIIMD2Ip sFS85ARCGVWz6xDXlPM5SijSroOUGitYILBaL16zIVCcFWJYMD2FtsawgACc oSt/hlvMsKTIa3rd/bZFKv62iVDk+BMvU0eYhAbTrPBo3dygLRQllV4K5YoA KwvWqw2xCK458K0NS4xlndL7E0HSQhpip07WTXerTbtahZ09qXDKuHhhX3bG CpvrLL+vUji3zSrndatUAwnAbP68EUdMVaHUedZmeg1CvxHH2gCHaI0JnGEs wxtXSVAClnG6L+ONjWvwp9U9yNxnA6W5FDPmlF8VFdnsJ7SJoF1sqhxBSGHh y1RP2CktxXPLCtlnlUqueK9UDX8i9bqA3MaIUFIMrPhBRlfGERLfKbmjl2pj ZIoAUrDXO1sNSTRUVyD9xqMOwJZX3yYOY/HEwNZhUOCHB8GHNMUojydUBpIh iHM4cOgqGpPFJQ8wJYBEkbJ2kGfZZJ1F+5BkyfJITNvyBOOwKV3LPay+/Xwe JCI9LnkDB7Hc4jHWsJT1UfJAfxblo7oyLdIixqaqLhhaWQmaWpZE8L56oSEQ vPDWYqUCFWjG+h6Y2/QWV4o6ZbkqgKwrozqgsMBBP3Kq9CIxXjZDPue0rF8u phih7u4YTB0dTOA6HRznybhqLdr4s71fgGKYWk1NwlyhiAIy5qDNtHEmZS2h jldUML2krWyUbLu0ZzvID08vz1dYDH0AwOGSuWkazlPEjT4JzdoOZ49Lm/Y7 ujfYBhVXOtGxzMkNdFFlT5vyWcwyY7sOeMEhc4To54rOnavz0e6KMLsGwAzM RJWwrFFe+kUunCxxjTUE/sucnB2UWjS+rWDYawqYtt8OqoPATZotqLJhOVNt U+dQm4kCuT5VxyTcFMjgE9FeufvwI+ecivzdq0htAOTwwXKtK9yJzeYa2S+R 5pJVpORdxHye41B6hTFJFqnd7rYiwnq9qaKRtTGXaG8468Tpz21pLT3nBtiK Maa/CpoEAXXaqY0pFRfm6yuX0CoAaFJUVuzh2UzaZCCm8hRbNrMa8b1LZBya ccTkTq4MV4kzxSoxjIsO2A4C/tUgtwYHlPlrw13p8vRw/9CVNiQaP/iJYjlX VUsMY7wODXVFpmw07VUM5R3ZhlhZrimzJYlwxBEUtQheUWaAxJZliQk1ympr 5fR+AH3WbQD94+lTrqxB1RFjZWgeTpA+Cb+ccNajnNyWClWFpKkCAvMSKfLc Tb4gvEryL7VCrH3PNRcvUrsjqYq2sM2Xi1xPqS/HY+pu43rIcn1F3cxcqoxU xibz5zbGMGHFpu8wkgOtluRFnSojh14nE+YOOxJ2b+GHwNnPop0xJno6K7Dr rYLT0oZV1eMlphZz/Cjpe5KNoQ1yqKa2iVAjZbNt7LWxNaw1OW2iIju0jIAu zSylTqco8eC4EVUJYadKoCjhsMUKdPX27ZUqqmQMoEIFuoN21z8MVc7k+GUG T61kavOxVSeB+9DcYcLeYWnMeu7TdAqGixMbIY2tfv/n4u3o1ejcFdN1kSl+ oDiGb1VAFZ+zVAU/if29PYHhQzrUEL1n/e5et9/t8RkHf1Dn4l1/b683iMaH g4H3yuqjJ7qCSu7hi6NutxssFovVmlvWcytuXfCBJZtF9hY2VhZubKna6CLZ frycq0+2SlFjeCI15+su0nqx1gDXKKNyAf/61VSzeqDi3Zf9jHAHyJmqrDS+ Ck42iV7AbzPqSUGrrswM6EGvkiJJ7AHdbBVobzCQvEL/oRX6X1mhTytUxxlu DQ5rPWEp83SztpA3rM/Djk9ebhn2gGU0X22QuYXPr/OxZjyOq6rjQYc+XkkW zjJK4saqWChUAKQcB1tWR6yySDM+psWWUnPDFMIo9Q3g6Pi8Pl2yHkgLf8Vh HvWY7S6z2r80RZYgq1sjonr+Z1MBgRD7TywZdsU95rnrMxD8IIbkRqPLBgpX 7qNjguCtHuT5DhZZq715b2xd49AflEKNNTTx6Hx4drKF5M0OXWnklNqwBdWL qzCiJbUPXKsYItpQpVEhEm9fkK8R76wBcGIvmX8WJ1EmNkTa43IfxamnKlRE aUTmsHyOh0E1oCGPr/l+QypNhocO6+rGFCdtOfV9uJiveybbLLfnM/tS56b4 qgF/RX3/XyuO0n4jlMF00ug/Iqb/KDH9R4hxEBb88IM4K+NCd3z/sVC+Uzfi dh/2vEd9rPff6mTsY0+2OplH8x8STn/3URH01yS1jdgtWvSV+Aix/YcgwSO7 kTdYz7Dw36GEH9/dqfmGr0RpI8xTPeziRoOlmvVHvfpxR9nqKYCvefp8tg8r mMFKZs+/++3uRxAFMn/Ff/W+HJ4x96eNuVFWtKPst/a2NdYg1OUwdDrnc+oX zqZGlG/qa0ziyNVNVTtjaMnhLNo/uzAwHTx10dZm8pS48XN6lpWMZLdlnGK1 6uwPdC/SaS6hKEA7YHTAR/wF3/jgI+JERZrOwvnkPc7Cm2ZebjtAq9bheicA dY60RuEVE5t93DRLOxRmvLNKLhDW7r4YsXYe2xZj4qu+S1Gm8jbTEfNHh9KE AGMroRWNkzxLvITEFemoo+31m4gamtyiMwWCXiSoHwjxdcUv5JkQGI1dzDKC D6pZTBnSoVWiP6lojWJXaSYS4iQBrGsI5R/dJOKmUE7lo+3oIMWirggqMepe kR3wKSRdW5IUlSjfckqlQ04QHiluciXyE/WdbJs61jeo0pCduf4DCZibTN4N Cs7yx0a56yEU1EPuBsuIEAia71ad3a21JzVz+ZyNzjlWPT5q9lydj2zjKCtg LtQEtXI3YZzZE7TMGR03Ll+D51t35EZnXfhrCqI2oe7RQi6r1khaz3K1s04n tkNHW3bFya1KXcUMtSK/+My3j6rDQO7L/7mmy9lVDLG5fgdtAHtcJiR3Y92M +hVkE5ktql1fuGPPYKPV+VHCl4Wc/ds+rRRTTRS5Q5qJDFcQ6dxlxod76WZq 3BVDj1syuZBb4mVCiKBsd5BJ5GyMhTQt+UiRvbLSGKmCzQ5Mj6ULh5LOwSXS k953b9rkLSDiTdWqxRZjutQ1qZlyxmKoer8iVKl1x86H3EhDfyIhZ5giV6Iu kgwBY3RS4iAgl5OJDsGqjJcQaRuBZl7Gki18oUiZ3JrieyXcdq3v3Rh7EUx1 p126AGYvB9ren8UNsihnIWR8ddvI2Zuq7MMiRl32+pey6NCAW0Kuu1pdSgNc /1aqnDrQ7DbcTDZZ7C5eWVXCouCWhT2F3Xbjr6YIGg6rXo8zA275sHtUG7oN cntGSU8SqBVwZI8pjD1NcxXXCllJctXUGvap00OpdsgdPWcV3Jj2fSlLq2Yz ZUlsT8a/ExkpcgHLi0c2tQOpb0LdfreYvWACSvXEp83d3Yp1euMcjY8m6Npb zXpNO78mtv2W1jZnmFPnLC02Wsj0DgXGsk74CEWkMVmoWQzVLbn6EA++xhrU MV+YLJF+3XoEeR7Gy1alvju2qyzEmteWCEryoDWySaFWVHsEIxYsAKlt6i6m NnhtKHaDKoQFTbekSVRXJ0fuktaz/ScHrnFN8UlaZhX5X2oImbrCHtGvR3/T EGl1E9GqZ6w4KC5kdffBhjAvSNOtx5nms3Fq0IFIZImVF7mlYLj1fZxGHCGA hK0V6hNRl9VE1CSatn+a2TgB4IQ9AbhXRym1zseQgetlbTuwJyHb6F1Zlg1o NmDZc4Xh+XAjCxvZJVt82520X7VILusG+hu6orXj3dsyuy3QOUUgyZdVf621 7bo8ZmHJXTpdmqq2JYCPVO1Zq/WdJIvoupCFeVqRyp06qZhk3KUZBMEXcW6R nD9f7Bmb9/kizpTk/Oixzxc6VUyoe6s4aQrVI0OPgNhTRTKzJ6m5+AIyOquP qH75szpbP+trbx+1Zd6WoUzG943lIK+1DR6+vOoOgXnUzrV/q3L3McGNTq5f rj0L/g2gB8hpXTEAAA==best practice. --> </back> </rfc>