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		November 2025
	TLS Encrypted Client Hello		TLS Encrypted Client Hello
	skipping to change at line 206 ¶		skipping to change at line 206 ¶
	| | | |		| | | |
	| 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 692 ¶		skipping to change at line 692 ¶
	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 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 1721 ¶		skipping to change at line 1721 ¶
	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 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, 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:
	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. 16 change blocks.
	30 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.48.