rfc9849v2.txt		rfc9849.txt
	Internet Engineering Task Force (IETF) E. Rescorla		Internet Engineering Task Force (IETF) E. Rescorla
	Request for Comments: 9849 Knight-Georgetown Institute		Request for Comments: 9849 Knight-Georgetown Institute
	Category: Standards Track K. Oku		Category: Standards Track K. Oku
	ISSN: 2070-1721 Fastly		ISSN: 2070-1721 Fastly
	N. Sullivan		N. Sullivan
	Cryptography Consulting LLC		Cryptography Consulting LLC
	C. A. Wood		C. A. Wood
	Cloudflare		Cloudflare
	November 2025		December 2025
	TLS Encrypted Client Hello		TLS Encrypted Client Hello
	Abstract		Abstract
	This document describes a mechanism in Transport Layer Security (TLS)		This document describes a mechanism in Transport Layer Security (TLS)
	for encrypting a ClientHello message under a server public key.		for encrypting a ClientHello message under a server public key.
	Status of This Memo		Status of This Memo
	skipping to change at line 191 ¶		skipping to change at line 191 ¶
	Client <-----> | private.example.org |		Client <-----> | private.example.org |
	| |		| |
	| public.example.com |		| public.example.com |
	| |		| |
	+---------------------+		+---------------------+
	Server		Server
	(Client-Facing and Backend Combined)		(Client-Facing and Backend Combined)
	Figure 1: Shared Mode Topology		Figure 1: Shared Mode Topology
	In Shared Mode, the provider is the origin server for all the domains		In shared mode, the provider is the origin server for all the domains
	whose DNS records point to it. In this mode, the TLS connection is		whose DNS records point to it. In this mode, the TLS connection is
	terminated by the provider.		terminated by the provider.
	+--------------------+ +---------------------+		+--------------------+ +---------------------+
	| | | |		| | | |
	| 2001:DB8::1111 | | 2001:DB8::EEEE |		| 2001:DB8::1111 | | 2001:DB8::EEEE |
	Client <----------------------------->| |		Client <----------------------------->| |
	| public.example.com | | private.example.org |		| public.example.com | | private.example.org |
	| | | |		| | | |
	+--------------------+ +---------------------+		+--------------------+ +---------------------+
	skipping to change at line 216 ¶		skipping to change at line 216 ¶
	In split mode, the provider is not the origin server for private		In split mode, the provider is not the origin server for private
	domains. Rather, the DNS records for private domains point to the		domains. Rather, the DNS records for private domains point to the
	provider, and the provider's server relays the connection back to the		provider, and the provider's server relays the connection back to the
	origin server, who terminates the TLS connection with the client.		origin server, who terminates the TLS connection with the client.
	Importantly, the service provider does not have access to the		Importantly, the service provider does not have access to the
	plaintext of the connection beyond the unencrypted portions of the		plaintext of the connection beyond the unencrypted portions of the
	handshake.		handshake.
	In the remainder of this document, we will refer to the ECH-service		In the remainder of this document, we will refer to the ECH-service
	provider as the "client-facing server" and to the TLS terminator as		provider as the "client-facing server" and to the TLS terminator as
	the "backend server". These are the same entity in Shared Mode, but		the "backend server". These are the same entity in shared mode, but
	in split mode, the client-facing and backend servers are physically		in split mode, the client-facing and backend servers are physically
	separated.		separated.
	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
	skipping to change at line 1201 ¶		skipping to change at line 1201 ¶
	indicated by the ECHClientHello.cipher_suite and that the version of		indicated by the ECHClientHello.cipher_suite and that the version of
	ECH indicated by the client matches the ECHConfig.version. If not,		ECH indicated by the client matches the ECHConfig.version. If not,
	the server continues to the next candidate ECHConfig.		the server continues to the next candidate ECHConfig.
	Next, the server decrypts ECHClientHello.payload, using the private		Next, the server decrypts ECHClientHello.payload, using the private
	key skR corresponding to ECHConfig, as follows:		key skR corresponding to ECHConfig, as follows:
	context = SetupBaseR(ECHClientHello.enc, skR,		context = SetupBaseR(ECHClientHello.enc, skR,
	"tls ech" || 0x00 || ECHConfig)		"tls ech" || 0x00 || ECHConfig)
	EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,		EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,
	ECHClientHello.payload)		ECHClientHello.payload)
	ClientHelloOuterAAD is computed from ClientHelloOuter as described in		ClientHelloOuterAAD is computed from ClientHelloOuter as described in
	Section 5.2. The info parameter to SetupBaseR is the concatenation		Section 5.2. The info parameter to SetupBaseR is the concatenation
	"tls ech", a zero byte, and the serialized ECHConfig. If decryption		"tls ech", a zero byte, and the serialized ECHConfig. If decryption
	fails, the server continues to the next candidate ECHConfig.		fails, the server continues to the next candidate ECHConfig.
	Otherwise, the server reconstructs ClientHelloInner from		Otherwise, the server reconstructs ClientHelloInner from
	EncodedClientHelloInner, as described in Section 5.1. It then stops		EncodedClientHelloInner, as described in Section 5.1. It then stops
	iterating over the candidate ECHConfig values.		iterating over the candidate ECHConfig values.
	Once the server has chosen the correct ECHConfig, it MAY verify that		Once the server has chosen the correct ECHConfig, it MAY verify that
	skipping to change at line 1278 ¶		skipping to change at line 1278 ¶
	extension. If not, it MUST abort the handshake with a		extension. If not, it MUST abort the handshake with a
	"missing_extension" alert. Otherwise, it checks that		"missing_extension" alert. Otherwise, it checks that
	ECHClientHello.cipher_suite and ECHClientHello.config_id are		ECHClientHello.cipher_suite and ECHClientHello.config_id are
	unchanged, and that ECHClientHello.enc is empty. If not, it MUST		unchanged, and that ECHClientHello.enc is empty. If not, it MUST
	abort the handshake with an "illegal_parameter" alert.		abort the handshake with an "illegal_parameter" alert.
	Finally, it decrypts the new ECHClientHello.payload as a second		Finally, it decrypts the new ECHClientHello.payload as a second
	message with the previous HPKE context:		message with the previous HPKE context:
	EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,		EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,
	ECHClientHello.payload)		ECHClientHello.payload)
	ClientHelloOuterAAD is computed as described in Section 5.2, but		ClientHelloOuterAAD is computed as described in Section 5.2, but
	using the second ClientHelloOuter. If decryption fails, the client-		using the second ClientHelloOuter. If decryption fails, the client-
	facing server MUST abort the handshake with a "decrypt_error" alert.		facing server MUST abort the handshake with a "decrypt_error" alert.
	Otherwise, it reconstructs the second ClientHelloInner from the new		Otherwise, it reconstructs the second ClientHelloInner from the new
	EncodedClientHelloInner as described in Section 5.1, using the second		EncodedClientHelloInner as described in Section 5.1, using the second
	ClientHelloOuter for any referenced extensions.		ClientHelloOuter for any referenced extensions.
	The client-facing server then forwards the resulting ClientHelloInner		The client-facing server then forwards the resulting ClientHelloInner
	to the backend server. It forwards all subsequent TLS messages		to the backend server. It forwards all subsequent TLS messages
	skipping to change at line 2203 ¶		skipping to change at line 2203 ¶
	[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>.
			[RFCYYY1] Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping
			TLS Encrypted ClientHello with DNS Service Bindings",
			RFC YYY1, DOI 10.17487/RFCYYY1, December 2025,
			<https://www.rfc-editor.org/info/rfcYYY1>.
	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 2279 ¶		skipping to change at line 2284 ¶
	[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
	TLS Encrypted ClientHello with DNS Service Bindings",
	RFC YYY1, DOI 10.17487/RFCYYY1, November 2025,
	<https://www.rfc-editor.org/info/rfcYYY1>.
	[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/#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:
End of changes. 7 change blocks.
	10 lines changed or deleted		10 lines changed or added
This html diff was produced by rfcdiff 1.48.