rfc9849v1.txt		rfc9849.txt
	Internet Engineering Task Force (IETF) E. Rescorla		Internet Engineering Task Force (IETF) E. Rescorla
	Request for Comments: 9849 Independent		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 |
	| | | |		| | | |
	+--------------------+ +---------------------+		+--------------------+ +---------------------+
	Client-Facing Server Backend Server		Client-Facing Server Backend Server
	Figure 2: Split Mode Topology		Figure 2: Split Mode Topology
	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 the TLS terminator as the		provider as the "client-facing server" and to the TLS terminator as
	"backend server". These are the same entity in Shared Mode, but in		the "backend server". These are the same entity in shared mode, but
	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
	metadata. Domains which wish to use ECH must publish this		metadata. Domains which wish to use ECH must publish this
	skipping to change at line 523 ¶		skipping to change at line 523 ¶
	struct {		struct {
	ClientHello client_hello;		ClientHello client_hello;
	uint8 zeros[length_of_padding];		uint8 zeros[length_of_padding];
	} EncodedClientHelloInner;		} EncodedClientHelloInner;
	The client_hello field is computed by first making a copy of		The client_hello field is computed by first making a copy of
	ClientHelloInner and setting the legacy_session_id field to the empty		ClientHelloInner and setting the legacy_session_id field to the empty
	string. In TLS, this field uses the ClientHello structure defined in		string. In TLS, this field uses the ClientHello structure defined in
	Section 4.1.2 of [RFC8446]. In DTLS, it uses the ClientHello		Section 4.1.2 of [RFC8446]. In DTLS, it uses the ClientHello
	structured defined in Section 5.3 of [RFC9147]. This does not		structure defined in Section 5.3 of [RFC9147]. This does not include
	include Handshake structure's four-byte header in TLS, nor twelve-		Handshake structure's four-byte header in TLS, nor twelve-byte header
	byte header in DTLS. The zeros field MUST be all zeroes of length		in DTLS. The zeros field MUST be all zeroes of length
	length_of_padding (see Section 6.1.3).		length_of_padding (see Section 6.1.3).
	Repeating large extensions, such as "key_share" with post-quantum		Repeating large extensions, such as "key_share" with post-quantum
	algorithms, between ClientHelloInner and ClientHelloOuter can lead to		algorithms, between ClientHelloInner and ClientHelloOuter can lead to
	excessive size. To reduce the size impact, the client MAY substitute		excessive size. To reduce the size impact, the client MAY substitute
	extensions which it knows will be duplicated in ClientHelloOuter. It		extensions which it knows will be duplicated in ClientHelloOuter. It
	does so by removing and replacing extensions from		does so by removing and replacing extensions from
	EncodedClientHelloInner with a single "ech_outer_extensions"		EncodedClientHelloInner with a single "ech_outer_extensions"
	extension, defined as follows:		extension, defined as follows:
	skipping to change at line 677 ¶		skipping to change at line 677 ¶
	order as in ClientHelloInner.		order as in ClientHelloInner.
	3. It MUST copy the legacy_session_id field from ClientHelloInner.		3. It MUST copy the legacy_session_id field from ClientHelloInner.
	This allows the server to echo the correct session ID for TLS		This allows the server to echo the correct session ID for TLS
	1.3's compatibility mode (see Appendix D.4 of [RFC8446]) when ECH		1.3's compatibility mode (see Appendix D.4 of [RFC8446]) when ECH
	is negotiated. Note that compatibility mode is not used in DTLS		is negotiated. Note that compatibility mode is not used in DTLS
	1.3, but following this rule will produce the correct results for		1.3, but following this rule will produce the correct results for
	both TLS 1.3 and DTLS 1.3.		both TLS 1.3 and DTLS 1.3.
	4. It MAY copy any other field from the ClientHelloInner except		4. It MAY copy any other field from the ClientHelloInner except
	ClientHelloInner.random. Instead, It MUST generate a fresh		ClientHelloInner.random. Instead, it MUST generate a fresh
	ClientHelloOuter.random using a secure random number generator.		ClientHelloOuter.random using a secure random number generator.
	(See Section 10.12.1.)		(See Section 10.12.1.)
	5. It SHOULD place the value of ECHConfig.contents.public_name in		5. It SHOULD place the value of ECHConfig.contents.public_name in
	the "server_name" extension. Clients that do not follow this		the "server_name" extension. Clients that do not follow this
	step, or place a different value in the "server_name" extension,		step, or place a different value in the "server_name" extension,
	risk breaking the retry mechanism described in Section 6.1.6 or		risk breaking the retry mechanism described in Section 6.1.6 or
	failing to interoperate with servers that require this step to be		failing to interoperate with servers that require this step to be
	done; see Section 7.1.		done; see Section 7.1.
	6. When the client offers the "pre_shared_key" extension in		6. When the client offers the "pre_shared_key" extension in
	ClientHelloInner, it SHOULD also include a GREASE		ClientHelloInner, it SHOULD also include a GREASE
	"pre_shared_key" extension in ClientHelloOuter, generated in the		"pre_shared_key" extension in ClientHelloOuter, generated in the
	manner described in Section 6.1.2. The client MUST NOT use this		manner described in Section 6.1.2. The client MUST NOT use this
	extension to advertise a Pre-Shared Key (PSK) to the client-		extension to advertise a PSK to the client-facing server. (See
	facing server. (See Section 10.12.3.) When the client includes		Section 10.12.3.) When the client includes a GREASE
	a GREASE "pre_shared_key" extension, it MUST also copy the		"pre_shared_key" extension, it MUST also copy the
	"psk_key_exchange_modes" from the ClientHelloInner into the		"psk_key_exchange_modes" from the ClientHelloInner into the
	ClientHelloOuter.		ClientHelloOuter.
	7. When the client offers the "early_data" extension in		7. When the client offers the "early_data" extension in
	ClientHelloInner, it MUST also include the "early_data" extension		ClientHelloInner, it MUST also include the "early_data" extension
	in ClientHelloOuter. This allows servers that reject ECH and use		in ClientHelloOuter. This allows servers that reject ECH and use
	ClientHelloOuter to safely ignore any early data sent by the		ClientHelloOuter to safely ignore any early data sent by the
	client per [RFC8446], Section 4.2.10.		client per [RFC8446], Section 4.2.10.
	The client might duplicate non-sensitive extensions in both messages.		The client might duplicate non-sensitive extensions in both messages.
	skipping to change at line 977 ¶		skipping to change at line 977 ¶
	connection and a node with configuration B in the second. Note that		connection and a node with configuration B in the second. Note that
	this guidance does not apply to the cases in the previous paragraph		this guidance does not apply to the cases in the previous paragraph
	where the server has securely disabled ECH.		where the server has securely disabled ECH.
	If a client does not retry, it MUST report an error to the calling		If a client does not retry, it MUST report an error to the calling
	application.		application.
	6.1.7. Authenticating for the Public Name		6.1.7. Authenticating for the Public Name
	When the server rejects ECH, it continues with the handshake using		When the server rejects ECH, it continues with the handshake using
	the plaintext "server_name" extension instead (see Section 7). Then,		the plaintext "server_name" extension instead (see Section 7).
	clients that offer ECH authenticate the connection with the public		Clients that offer ECH then authenticate the connection with the
	name as follows:		public name as follows:
	* The client MUST verify that the certificate is valid for		* The client MUST verify that the certificate is valid for
	ECHConfig.contents.public_name. If invalid, it MUST abort the		ECHConfig.contents.public_name. If invalid, it MUST abort the
	connection with the appropriate alert.		connection with the appropriate alert.
	* If the server requests a client certificate, the client MUST		* If the server requests a client certificate, the client MUST
	respond with an empty Certificate message, denoting no client		respond with an empty Certificate message, denoting no client
	certificate.		certificate.
	In verifying the client-facing server certificate, the client MUST		In verifying the client-facing server certificate, the client MUST
	interpret the public name as a DNS-based reference identity		interpret the public name as a DNS-based reference identity
	[RFC6125]. Clients that incorporate DNS names and IP addresses into		[RFC9525]. Clients that incorporate DNS names and IP addresses into
	the same syntax (e.g. Section 7.4 of [RFC3986] and [WHATWG-IPV4])		the same syntax (e.g. Section 7.4 of [RFC3986] and [WHATWG-IPV4])
	MUST reject names that would be interpreted as IPv4 addresses.		MUST reject names that would be interpreted as IPv4 addresses.
	Clients that enforce this by checking ECHConfig.contents.public_name		Clients that enforce this by checking ECHConfig.contents.public_name
	do not need to repeat the check when processing ECH rejection.		do not need to repeat the check when processing ECH rejection.
	Note that authenticating a connection for the public name does not		Note that authenticating a connection for the public name does not
	authenticate it for the origin. The TLS implementation MUST NOT		authenticate it for the origin. The TLS implementation MUST NOT
	report such connections as successful to the application. It		report such connections as successful to the application. It
	additionally MUST ignore all session tickets and session IDs		additionally MUST ignore all session tickets and session IDs
	presented by the server. These connections are only used to trigger		presented by the server. These connections are only used to trigger
	skipping to change at line 1131 ¶		skipping to change at line 1131 ¶
	application-level warning message when these are observed.		application-level warning message when these are observed.
	* By giving the extraneous configurations an invalid public key and		* By giving the extraneous configurations an invalid public key and
	a public name not associated with the server so that the initial		a public name not associated with the server so that the initial
	ClientHelloOuter will not be decryptable and the server cannot		ClientHelloOuter will not be decryptable and the server cannot
	perform the recovery flow described in Section 6.1.6.		perform the recovery flow described in Section 6.1.6.
	7. Server Behavior		7. Server Behavior
	As described in Section 3.1, servers can play two roles, either as		As described in Section 3.1, servers can play two roles, either as
	the client-facing server or as the back-end server. Depending on the		the client-facing server or as the backend server. Depending on the
	server role, the ECHClientHello will be different:		server role, the ECHClientHello will be different:
	* A client-facing server expects an ECHClientHello.type of outer,		* A client-facing server expects an ECHClientHello.type of outer,
	and proceeds as described in Section 7.1 to extract a		and proceeds as described in Section 7.1 to extract a
	ClientHelloInner, if available.		ClientHelloInner, if available.
	* A backend server expects an ECHClientHello.type of inner, and		* A backend server expects an ECHClientHello.type of inner, and
	proceeds as described in Section 7.2.		proceeds as described in Section 7.2.
	In split mode, a client-facing server which receives a ClientHello		In split mode, a client-facing server which receives a ClientHello
	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 1501 ¶		skipping to change at line 1501 ¶
	A middlebox that filters based on plaintext packet contents is one		A middlebox that filters based on plaintext packet contents is one
	example of a passive attacker. In contrast, active attackers can		example of a passive attacker. In contrast, active attackers can
	also write packets into the network for malicious purposes, such as		also write packets into the network for malicious purposes, such as
	interfering with existing connections, probing servers, and querying		interfering with existing connections, probing servers, and querying
	DNS. In short, an active attacker corresponds to the conventional		DNS. In short, an active attacker corresponds to the conventional
	threat model [RFC3552] for TLS 1.3 [RFC8446].		threat model [RFC3552] for TLS 1.3 [RFC8446].
	Passive and active attackers can exist anywhere in the network,		Passive and active attackers can exist anywhere in the network,
	including between the client and client-facing server, as well as		including between the client and client-facing server, as well as
	between the client-facing and backend servers when running ECH in		between the client-facing and backend servers when running ECH in
	Split Mode. However, for Split Mode in particular, ECH makes two		split mode. However, for split mode in particular, ECH makes two
	additional assumptions:		additional assumptions:
	1. The channel between each client-facing and each backend server is		1. The channel between each client-facing and each backend server is
	authenticated such that the backend server only accepts messages		authenticated such that the backend server only accepts messages
	from trusted client-facing servers. The exact mechanism for		from trusted client-facing servers. The exact mechanism for
	establishing this authenticated channel is out of scope for this		establishing this authenticated channel is out of scope for this
	document.		document.
	2. The attacker cannot correlate messages between a client and		2. The attacker cannot correlate messages between a client and
	client-facing server with messages between client-facing and		client-facing server with messages between client-facing and
	skipping to change at line 1709 ¶		skipping to change at line 1709 ¶
	adversary that observes this can deduce that the ECH-enabled		adversary that observes this can deduce that the ECH-enabled
	connection was made to a host that the client previously connected to		connection was made to a host that the client previously connected to
	and which is within the same anonymity set.		and which is within the same anonymity set.
	10.8. Cookies		10.8. Cookies
	Section 4.2.2 of [RFC8446] defines a cookie value that servers may		Section 4.2.2 of [RFC8446] defines a cookie value that servers may
	send in HelloRetryRequest for clients to echo in the second		send in HelloRetryRequest for clients to echo in the second
	ClientHello. While ECH encrypts the cookie in the second		ClientHello. While ECH encrypts the cookie in the second
	ClientHelloInner, the backend server's HelloRetryRequest is		ClientHelloInner, the backend server's HelloRetryRequest is
	unencrypted.This means differences in cookies between backend		unencrypted. This means differences in cookies between backend
	servers, such as lengths or cleartext components, may leak		servers, such as lengths or cleartext components, may leak
	information about the server identity.		information about the server identity.
	Backend servers in an anonymity set SHOULD NOT reveal information in		Backend servers in an anonymity set SHOULD NOT reveal information in
	the cookie which identifies the server. This may be done by handling		the cookie which identifies the server. This may be done by handling
	HelloRetryRequest statefully, thus not sending cookies, or by using		HelloRetryRequest statefully, thus not sending cookies, or by using
	the same cookie construction for all backend servers.		the same cookie construction for all backend servers.
	Note that, if the cookie includes a key name, analogous to Section 4		Note that, if the cookie includes a key name, analogous to Section 4
	of [RFC5077], this may leak information if different backend servers		of [RFC5077], this may leak information if different backend servers
	issue cookies with different key names at the time of the connection.		issue cookies with different key names at the time of the connection.
	In particular, if the deployment operates in Split Mode, the backend		In particular, if the deployment operates in split mode, the backend
	servers may not share cookie encryption keys. Backend servers may		servers may not share cookie encryption keys. Backend servers may
	mitigate this either by handling key rotation with trial decryption		mitigate this either by handling key rotation with trial decryption
	or by coordinating to match key names.		or by coordinating to match key names.
	10.9. Attacks Exploiting Acceptance Confirmation		10.9. Attacks Exploiting Acceptance Confirmation
	To signal acceptance, the backend server overwrites 8 bytes of its		To signal acceptance, the backend server overwrites 8 bytes of its
	ServerHello.random with a value derived from the		ServerHello.random with a value derived from the
	ClientHelloInner.random. (See Section 7.2 for details.) This		ClientHelloInner.random. (See Section 7.2 for details.) This
	behavior increases the likelihood of the ServerHello.random colliding		behavior increases the likelihood of the ServerHello.random colliding
	skipping to change at line 1859 ¶		skipping to change at line 1859 ¶
	10.10.5. Maintain Forward Secrecy		10.10.5. Maintain Forward Secrecy
	This design does not provide forward secrecy for the inner		This design does not provide forward secrecy for the inner
	ClientHello because the server's ECH key is static. However, the		ClientHello because the server's ECH key is static. However, the
	window of exposure is bound by the key lifetime. It is RECOMMENDED		window of exposure is bound by the key lifetime. It is RECOMMENDED
	that servers rotate keys regularly.		that servers rotate keys regularly.
	10.10.6. Enable Multi-party Security Contexts		10.10.6. Enable Multi-party Security Contexts
	This design permits servers operating in Split Mode to forward		This design permits servers operating in split mode to forward
	connections directly to backend origin servers. The client		connections directly to backend origin servers. The client
	authenticates the identity of the backend origin server, thereby		authenticates the identity of the backend origin server, thereby
	allowing the backend origin server to hide behind the client-facing		allowing the backend origin server to hide behind the client-facing
	server without the client-facing server decrypting and reencrypting		server without the client-facing server decrypting and reencrypting
	the connection.		the connection.
	Conversely, if the DNS records used for configuration are		Conversely, if the DNS records used for configuration are
	authenticated, e.g., via DNSSEC, spoofing a client-facing server		authenticated, e.g., via DNSSEC, spoofing a client-facing server
	operating in Split Mode is not possible. See Section 10.2 for more		operating in split mode is not possible. See Section 10.2 for more
	details regarding plaintext DNS.		details regarding plaintext DNS.
	Authenticating the ECHConfig structure naturally authenticates the		Authenticating the ECHConfig structure naturally authenticates the
	included public name. This also authenticates any retry signals from		included public name. This also authenticates any retry signals from
	the client-facing server because the client validates the server		the client-facing server because the client validates the server
	certificate against the public name before retrying.		certificate against the public name before retrying.
	10.10.7. Support Multiple Protocols		10.10.7. Support Multiple Protocols
	This design has no impact on application layer protocol negotiation.		This design has no impact on application layer protocol negotiation.
	skipping to change at line 2074 ¶		skipping to change at line 2074 ¶
	the number of extensions, the overall decoding process would take		the number of extensions, the overall decoding process would take
	O(M*N) time, where M is the number of extensions in		O(M*N) time, where M is the number of extensions in
	ClientHelloOuter and N is the size of OuterExtensions.		ClientHelloOuter and N is the size of OuterExtensions.
	* If the same ClientHelloOuter extension can be copied multiple		* If the same ClientHelloOuter extension can be copied multiple
	times, an attacker could cause the client-facing server to		times, an attacker could cause the client-facing server to
	construct a large ClientHelloInner by including a large extension		construct a large ClientHelloInner by including a large extension
	in ClientHelloOuter of length L and an OuterExtensions list		in ClientHelloOuter of length L and an OuterExtensions list
	referencing N copies of that extension. The client-facing server		referencing N copies of that extension. The client-facing server
	would then use O(N*L) memory in response to O(N+L) bandwidth from		would then use O(N*L) memory in response to O(N+L) bandwidth from
	the client. In split-mode, an O(N*L)-sized packet would then be		the client. In split mode, an O(N*L)-sized packet would then be
	transmitted to the backend server.		transmitted to the backend server.
	ECH mitigates this attack by requiring that OuterExtensions be		ECH mitigates this attack by requiring that OuterExtensions be
	referenced in order, that duplicate references be rejected, and by		referenced in order, that duplicate references be rejected, and by
	recommending that client-facing servers use a linear scan to perform		recommending that client-facing servers use a linear scan to perform
	decompression. These requirements are detailed in Section 5.1.		decompression. These requirements are detailed in Section 5.1.
	11. IANA Considerations		11. IANA Considerations
	11.1. Update of the TLS ExtensionType Registry		11.1. Update of the TLS ExtensionType Registry
	skipping to change at line 2113 ¶		skipping to change at line 2113 ¶
	11.3. ECH Configuration Extension Registry		11.3. ECH Configuration Extension Registry
	IANA has created a new "TLS ECHConfig Extension" registry in a new		IANA has created a new "TLS ECHConfig Extension" registry in a new
	"TLS Encrypted Client Hello (ECH) Configuration Extensions" registry		"TLS Encrypted Client Hello (ECH) Configuration Extensions" registry
	group. New registrations will list the following attributes:		group. New registrations will list the following attributes:
	Value: The two-byte identifier for the ECHConfigExtension, i.e., the		Value: The two-byte identifier for the ECHConfigExtension, i.e., the
	ECHConfigExtensionType		ECHConfigExtensionType
	Extension Name: Name of the ECHConfigExtension		Extension Name: Name of the ECHConfigExtension
	Recommended: A "Y" or "N" value indicating if the extension is TLS		Recommended: A "Y" or "N" value indicating if the TLS Working Group
	WG 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 with 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 [RFC8447], Section 17.
	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 8447.
	skipping to change at line 2147 ¶		skipping to change at line 2147 ¶
	The initial contents for this registry consists of multiple reserved		The initial contents for this registry consists of multiple reserved
	values with the following attributes, which are repeated for each		values with the following attributes, which are repeated for each
	registration:		registration:
	Value: 0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A,		Value: 0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A,
	0x7A7A, 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA,		0x7A7A, 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA,
	0xFAFA		0xFAFA
	Extension Name: RESERVED		Extension Name: RESERVED
	Recommended: Y		Recommended: Y
	Reference: RFC 9849		Reference: RFC 9849
	Notes: Grease entries		Notes: GREASE entries
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid		[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
	Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,		Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
	February 2022, <https://www.rfc-editor.org/info/rfc9180>.		February 2022, <https://www.rfc-editor.org/info/rfc9180>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5890] Klensin, J., "Internationalized Domain Names for		[RFC5890] Klensin, J., "Internationalized Domain Names for
	Applications (IDNA): Definitions and Document Framework",		Applications (IDNA): Definitions and Document Framework",
	RFC 5890, DOI 10.17487/RFC5890, August 2010,		RFC 5890, DOI 10.17487/RFC5890, August 2010,
	<https://www.rfc-editor.org/info/rfc5890>.		<https://www.rfc-editor.org/info/rfc5890>.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
	2011, <https://www.rfc-editor.org/info/rfc6125>.
	[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport		[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
	Layer Security (TLS) False Start", RFC 7918,		Layer Security (TLS) False Start", RFC 7918,
	DOI 10.17487/RFC7918, August 2016,		DOI 10.17487/RFC7918, August 2016,
	<https://www.rfc-editor.org/info/rfc7918>.		<https://www.rfc-editor.org/info/rfc7918>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	skipping to change at line 2206 ¶		skipping to change at line 2199 ¶
	[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>.
	[RFCYYY1] Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping		[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
	TLS Encrypted ClientHello with DNS Service Bindings",		RFC 9525, DOI 10.17487/RFC9525, November 2023,
	RFC YYY1, DOI 10.17487/RFCYYY1, November 2025,		<https://www.rfc-editor.org/info/rfc9525>.
	<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
	skipping to change at line 2287 ¶		skipping to change at line 2279 ¶
	[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, December 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:
	skipping to change at line 2326 ¶		skipping to change at line 2323 ¶
	This document draws extensively from ideas in [PROTECTED-SNI], but is		This document draws extensively from ideas in [PROTECTED-SNI], but is
	a much more limited mechanism because it depends on the DNS for the		a much more limited mechanism because it depends on the DNS for the
	protection of the ECH key. Richard Barnes, Christian Huitema,		protection of the ECH key. Richard Barnes, Christian Huitema,
	Patrick McManus, Matthew Prince, Nick Sullivan, Martin Thomson, and		Patrick McManus, Matthew Prince, Nick Sullivan, Martin Thomson, and
	David Benjamin also provided important ideas and contributions.		David Benjamin also provided important ideas and contributions.
	Authors' Addresses		Authors' Addresses
	Eric Rescorla		Eric Rescorla
	Independent		Knight-Georgetown Institute
	Email: ekr@rtfm.com		Email: ekr@rtfm.com
	Kazuho Oku		Kazuho Oku
	Fastly		Fastly
	Email: kazuhooku@gmail.com		Email: kazuhooku@gmail.com
	Nick Sullivan		Nick Sullivan
	Cryptography Consulting LLC		Cryptography Consulting LLC
	Email: nicholas.sullivan+ietf@gmail.com		Email: nicholas.sullivan+ietf@gmail.com
End of changes. 26 change blocks.
	43 lines changed or deleted		40 lines changed or added
This html diff was produced by rfcdiff 1.48.