rfc9849v6.txt		rfc9849.txt
	skipping to change at line 230 ¶		skipping to change at line 230 ¶
	See Section 10 for more discussion about the ECH threat model and how		See Section 10 for more discussion about the ECH threat model and how
	it relates to the client, client-facing server, and backend server.		it relates to the client, client-facing server, and backend server.
	3.2. Encrypted ClientHello (ECH)		3.2. Encrypted ClientHello (ECH)
	A client-facing server enables ECH by publishing an ECH		A client-facing server enables ECH by publishing an ECH
	configuration, which is an encryption public key and associated		configuration, which is an encryption public key and associated
	metadata. Domains which wish to use ECH must publish this		metadata. Domains which wish to use ECH must publish this
	configuration, using the key associated with the client-facing		configuration, using the key associated with the client-facing
	server. This document defines the ECH configuration's format, but		server. This document defines the ECH configuration's format, but
	delegates DNS publication details to [RFC9460]. See [RFCYYY1] for		delegates DNS publication details to [RFC9460]. See [RFC9848] for
	specifics about how ECH configurations are advertised in SVCB and		specifics about how ECH configurations are advertised in SVCB and
	HTTPS records. Other delivery mechanisms are also possible. For		HTTPS records. Other delivery mechanisms are also possible. For
	example, the client may have the ECH configuration preconfigured.		example, the client may have the ECH configuration preconfigured.
	When a client wants to establish a TLS session with some backend		When a client wants to establish a TLS session with some backend
	server, it constructs a private ClientHello, referred to as the		server, it constructs a private ClientHello, referred to as the
	ClientHelloInner. The client then constructs a public ClientHello,		ClientHelloInner. The client then constructs a public ClientHello,
	referred to as the ClientHelloOuter. The ClientHelloOuter contains		referred to as the ClientHelloOuter. The ClientHelloOuter contains
	innocuous values for sensitive extensions and an		innocuous values for sensitive extensions and an
	"encrypted_client_hello" extension (Section 5), which carries the		"encrypted_client_hello" extension (Section 5), which carries the
	skipping to change at line 1046 ¶		skipping to change at line 1046 ¶
	enforcing the single retry limit from Section 6.1.6. The reason for		enforcing the single retry limit from Section 6.1.6. The reason for
	this requirement is that if the server sends a "retry_config" and		this requirement is that if the server sends a "retry_config" and
	then immediately rejects the resulting connection, it is most likely		then immediately rejects the resulting connection, it is most likely
	misconfigured. However, if the server sends a "retry_config" and		misconfigured. However, if the server sends a "retry_config" and
	then the client tries to use that to connect some time later, it is		then the client tries to use that to connect some time later, it is
	possible that the server has changed its configuration again and is		possible that the server has changed its configuration again and is
	now trying to recover.		now trying to recover.
	Any persisted information MUST be associated with the ECHConfig		Any persisted information MUST be associated with the ECHConfig
	source used to bootstrap the connection, such as a DNS SVCB		source used to bootstrap the connection, such as a DNS SVCB
	ServiceMode record [RFCYYY1]. Clients MUST limit any sharing of		ServiceMode record [RFC9848]. Clients MUST limit any sharing of
	persisted ECH-related state to connections that use the same		persisted ECH-related state to connections that use the same
	ECHConfig source. Otherwise, it might become possible for the client		ECHConfig source. Otherwise, it might become possible for the client
	to have the wrong public name for the server, making recovery		to have the wrong public name for the server, making recovery
	impossible.		impossible.
	ECHConfigs learned from ECH rejection can be used as a tracking		ECHConfigs learned from ECH rejection can be used as a tracking
	vector. Clients SHOULD impose the same lifetime and scope		vector. Clients SHOULD impose the same lifetime and scope
	restrictions that they apply to other server-based tracking vectors		restrictions that they apply to other server-based tracking vectors
	such as PSKs.		such as PSKs.
	skipping to change at line 1576 ¶		skipping to change at line 1576 ¶
	Specifically, the GREASE ECH extension described in Section 6.2 does		Specifically, the GREASE ECH extension described in Section 6.2 does
	not change the security properties of the TLS handshake at all. Its		not change the security properties of the TLS handshake at all. Its
	goal is to provide "cover" for the real ECH protocol (Section 6.1),		goal is to provide "cover" for the real ECH protocol (Section 6.1),
	as a means of addressing the "do not stick out" requirements of		as a means of addressing the "do not stick out" requirements of
	[RFC8744]. See Section 10.10.4 for details.		[RFC8744]. See Section 10.10.4 for details.
	10.2. Unauthenticated and Plaintext DNS		10.2. Unauthenticated and Plaintext DNS
	ECH supports delivery of configurations through the DNS using SVCB or		ECH supports delivery of configurations through the DNS using SVCB or
	HTTPS records without requiring any verifiable authenticity or		HTTPS records without requiring any verifiable authenticity or
	provenance information [RFCYYY1]. This means that any attacker which		provenance information [RFC9848]. This means that any attacker which
	can inject DNS responses or poison DNS caches, which is a common		can inject DNS responses or poison DNS caches, which is a common
	scenario in client access networks, can supply clients with fake ECH		scenario in client access networks, can supply clients with fake ECH
	configurations (so that the client encrypts data to them) or strip		configurations (so that the client encrypts data to them) or strip
	the ECH configurations from the response. However, in the face of an		the ECH configurations from the response. However, in the face of an
	attacker that controls DNS, no encryption scheme can work because the		attacker that controls DNS, no encryption scheme can work because the
	attacker can replace the IP address, thus blocking client		attacker can replace the IP address, thus blocking client
	connections, or substitute a unique IP address for each DNS name that		connections, or substitute a unique IP address for each DNS name that
	was looked up. Thus, using DNS records without additional		was looked up. Thus, using DNS records without additional
	authentication does not make the situation significantly worse.		authentication does not make the situation significantly worse.
	skipping to change at line 2132 ¶		skipping to change at line 2132 ¶
	Extension Name: Name of the ECHConfigExtension		Extension Name: Name of the ECHConfigExtension
	Recommended: A "Y" or "N" value indicating if the TLS Working Group		Recommended: A "Y" or "N" value indicating if the TLS Working Group
	recommends that the extension be supported. This column is		recommends that the extension be supported. This column is
	assigned a value of "N" unless explicitly requested. Adding a		assigned a value of "N" unless explicitly requested. Adding a
	value of "Y" requires Standards Action [RFC8126].		value of "Y" requires Standards Action [RFC8126].
	Reference: The specification where the ECHConfigExtension is defined		Reference: The specification where the ECHConfigExtension is defined
	Notes: Any notes associated with the entry		Notes: Any notes associated with the entry
	New entries in the "TLS ECHConfig Extension" registry are subject to		New entries in the "TLS ECHConfig Extension" registry are subject to
	the Specification Required registration policy ([RFC8126],		the Specification Required registration policy ([RFC8126],
	Section 4.6), with the policies described in [RFC8447], Section 17.		Section 4.6), with the policies described in [RFC9847], Section 16.
	IANA has added the following note to the "TLS ECHConfig Extension"		IANA has added the following note to the "TLS ECHConfig Extension"
	registry:		registry:
	Note: The role of the designated expert is described in RFC 8447.		Note: The role of the designated expert is described in RFC 9847.
	The designated expert [RFC8126] ensures that the specification is		The designated expert [RFC8126] ensures that the specification is
	publicly available. It is sufficient to have an Internet-Draft (that		publicly available. It is sufficient to have an Internet-Draft (that
	is posted and never published as an RFC) or a document from another		is posted and never published as an RFC) or a document from another
	standards body, industry consortium, university site, etc. The		standards body, industry consortium, university site, etc. The
	expert may provide more in-depth reviews, but their approval should		expert may provide more in-depth reviews, but their approval should
	not be taken as an endorsement of the extension.		not be taken as an endorsement of the extension.
	This document defines several Reserved values for ECH configuration		This document defines several Reserved values for ECH configuration
	extensions to be used for "greasing" as described in Section 6.2.2.		extensions to be used for "greasing" as described in Section 6.2.2.
	skipping to change at line 2195 ¶		skipping to change at line 2195 ¶
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
	and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
	<https://www.rfc-editor.org/info/rfc8447>.
	[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The		[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,		1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
	<https://www.rfc-editor.org/info/rfc9147>.		<https://www.rfc-editor.org/info/rfc9147>.
	[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding		[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
	and Parameter Specification via the DNS (SVCB and HTTPS		and Parameter Specification via the DNS (SVCB and HTTPS
	Resource Records)", RFC 9460, DOI 10.17487/RFC9460,		Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
	November 2023, <https://www.rfc-editor.org/info/rfc9460>.		November 2023, <https://www.rfc-editor.org/info/rfc9460>.
	[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",		[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
	RFC 9525, DOI 10.17487/RFC9525, November 2023,		RFC 9525, DOI 10.17487/RFC9525, November 2023,
	<https://www.rfc-editor.org/info/rfc9525>.		<https://www.rfc-editor.org/info/rfc9525>.
			[RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
			and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025,
			<https://www.rfc-editor.org/info/rfc9847>.
	12.2. Informative References		12.2. Informative References
	[DNS-TERMS]		[DNS-TERMS]
	Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,		Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
	RFC 9499, DOI 10.17487/RFC9499, March 2024,		RFC 9499, DOI 10.17487/RFC9499, March 2024,
	<https://www.rfc-editor.org/info/rfc9499>.		<https://www.rfc-editor.org/info/rfc9499>.
	[ECH-Analysis]		[ECH-Analysis]
	Bhargavan, K., Cheval, V., and C. Wood, "A Symbolic		Bhargavan, K., Cheval, V., and C. Wood, "A Symbolic
	Analysis of Privacy for TLS 1.3 with Encrypted Client		Analysis of Privacy for TLS 1.3 with Encrypted Client
	skipping to change at line 2289 ¶		skipping to change at line 2289 ¶
	[RFC8744] Huitema, C., "Issues and Requirements for Server Name		[RFC8744] Huitema, C., "Issues and Requirements for Server Name
	Identification (SNI) Encryption in TLS", RFC 8744,		Identification (SNI) Encryption in TLS", RFC 8744,
	DOI 10.17487/RFC8744, July 2020,		DOI 10.17487/RFC8744, July 2020,
	<https://www.rfc-editor.org/info/rfc8744>.		<https://www.rfc-editor.org/info/rfc8744>.
	[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over		[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
	Dedicated QUIC Connections", RFC 9250,		Dedicated QUIC Connections", RFC 9250,
	DOI 10.17487/RFC9250, May 2022,		DOI 10.17487/RFC9250, May 2022,
	<https://www.rfc-editor.org/info/rfc9250>.		<https://www.rfc-editor.org/info/rfc9250>.
	[RFCYYY1] Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping		[RFC9848] Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping
	TLS Encrypted ClientHello with DNS Service Bindings",		TLS Encrypted ClientHello with DNS Service Bindings",
	RFC YYY1, DOI 10.17487/RFCYYY1, December 2025,		RFC 9848, DOI 10.17487/RFC9848, February 2026,
	<https://www.rfc-editor.org/info/rfcYYY1>.		<https://www.rfc-editor.org/info/rfc9848>.
	[WHATWG-IPV4]		[WHATWG-IPV4]
	WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May		WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May
	2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>.		2021, <https://url.spec.whatwg.org/>. Commit snapshot:
			<https://url.spec.whatwg.org/commit- snapshots/1b8b8c55eb4
			bed9f139c9a439fb1c1bf5566b619/#concept- ipv4-parser>.
	Appendix A. Linear-Time Outer Extension Processing		Appendix A. Linear-Time Outer Extension Processing
	The following procedure processes the "ech_outer_extensions"		The following procedure processes the "ech_outer_extensions"
	extension (see Section 5.1) in linear time, ensuring that each		extension (see Section 5.1) in linear time, ensuring that each
	referenced extension in the ClientHelloOuter is included at most		referenced extension in the ClientHelloOuter is included at most
	once:		once:
	1. Let I be initialized to zero and N be set to the number of		1. Let I be initialized to zero and N be set to the number of
	extensions in ClientHelloOuter.		extensions in ClientHelloOuter.
End of changes. 10 change blocks.
	13 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48.