Diff: rfc9369v2.txt - rfc9369.txt

	rfc9369v2.txt	rfc9369.txt

	Internet Engineering Task Force (IETF) M. Duke	Internet Engineering Task Force (IETF) M. Duke
	Request for Comments: 9369 Google LLC	Request for Comments: 9369 Google LLC

	Category: Standards Track February 2023	Category: Standards Track May 2023
	ISSN: 2070-1721	ISSN: 2070-1721

	QUIC Version 2	QUIC Version 2

	Abstract	Abstract

	This document specifies QUIC version 2, which is identical to QUIC	This document specifies QUIC version 2, which is identical to QUIC
	version 1 except for some trivial details. Its purpose is to combat	version 1 except for some trivial details. Its purpose is to combat
	various ossification vectors and exercise the version negotiation	various ossification vectors and exercise the version negotiation
	framework. It also serves as a template for the minimum changes in	framework. It also serves as a template for the minimum changes in
	any future version of QUIC.	any future version of QUIC.

	Note that "version 2" is an informal name for this proposal that	Note that "version 2" is an informal name for this proposal that

	indicates it is the second standards-track QUIC version. The	indicates it is the second version of QUIC to be published as a
	protocol specified here uses a version number other than 2 in the	Standards Track document. The protocol specified here uses a version
	wire image, in order to minimize ossification risks.	number other than 2 in the wire image, in order to minimize
		ossification risks.

	Status of This Memo	Status of This Memo

	This is an Internet Standards Track document.	This is an Internet Standards Track document.

	This document is a product of the Internet Engineering Task Force	This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has	(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the	received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on	Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.	Internet Standards is available in Section 2 of RFC 7841.

	skipping to change at line 88 ¶	skipping to change at line 89 ¶
	Acknowledgments	Acknowledgments
	Author's Address	Author's Address

	1. Introduction	1. Introduction

	QUIC version 1 [QUIC] has numerous extension points, including the	QUIC version 1 [QUIC] has numerous extension points, including the
	version number that occupies the second through fifth bytes of every	version number that occupies the second through fifth bytes of every
	long header (see [QUIC-INVARIANTS]). If experimental versions are	long header (see [QUIC-INVARIANTS]). If experimental versions are
	rare, and QUIC version 1 constitutes the vast majority of QUIC	rare, and QUIC version 1 constitutes the vast majority of QUIC
	traffic, there is the potential for middleboxes to ossify on the	traffic, there is the potential for middleboxes to ossify on the

	version bytes always being 0x00000001.	version bytes that are usually 0x00000001.

	In QUIC version 1, Initial packets are encrypted with the version-	In QUIC version 1, Initial packets are encrypted with the version-
	specific salt, as described in Section 5.2 of [QUIC-TLS]. Protecting	specific salt, as described in Section 5.2 of [QUIC-TLS]. Protecting
	Initial packets in this way allows observers to inspect their	Initial packets in this way allows observers to inspect their
	contents, which includes the TLS Client Hello or Server Hello	contents, which includes the TLS Client Hello or Server Hello
	messages. Again, there is the potential for middleboxes to ossify on	messages. Again, there is the potential for middleboxes to ossify on
	the version 1 key derivation and packet formats.	the version 1 key derivation and packet formats.

	Finally, [QUIC-VN] describes two mechanisms endpoints can use to	Finally, [QUIC-VN] describes two mechanisms endpoints can use to
	negotiate which QUIC version to select. The "incompatible" version	negotiate which QUIC version to select. The "incompatible" version

	skipping to change at line 153 ¶	skipping to change at line 154 ¶
	* Initial: 0b01	* Initial: 0b01

	* 0-RTT: 0b10	* 0-RTT: 0b10

	* Handshake: 0b11	* Handshake: 0b11

	* Retry: 0b00	* Retry: 0b00

	3.3. Cryptography Changes	3.3. Cryptography Changes


	The values below were chosen randomly.

	3.3.1. Initial Salt	3.3.1. Initial Salt

	The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS]	The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS]
	changes to:	changes to:

	initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9	initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9

	This is the first 20 bytes of the sha256sum of "QUICv2 salt".	This is the first 20 bytes of the sha256sum of "QUICv2 salt".

	3.3.2. HMAC-based Key Derivation Function (HKDF) Labels	3.3.2. HMAC-based Key Derivation Function (HKDF) Labels

	skipping to change at line 268 ¶	skipping to change at line 267 ¶
	The client MUST NOT send 0-RTT packets using the negotiated version,	The client MUST NOT send 0-RTT packets using the negotiated version,
	even after processing a packet of that version from the server.	even after processing a packet of that version from the server.
	Servers can accept 0-RTT and then process 0-RTT packets from the	Servers can accept 0-RTT and then process 0-RTT packets from the
	original version.	original version.

	5. TLS Resumption and NEW_TOKEN Tokens	5. TLS Resumption and NEW_TOKEN Tokens

	TLS session tickets and NEW_TOKEN tokens are specific to the QUIC	TLS session tickets and NEW_TOKEN tokens are specific to the QUIC
	version of the connection that provided them. Clients MUST NOT use a	version of the connection that provided them. Clients MUST NOT use a
	session ticket or token from a QUIC version 1 connection to initiate	session ticket or token from a QUIC version 1 connection to initiate

	a QUIC version 2 connection, and vice versa.	a QUIC version 2 connection, and vice versa. When a connection
		includes compatible version negotiation, any issued server tokens are
		considered to originate from the negotiated version, not the original
		one.

	Servers MUST validate the originating version of any session ticket	Servers MUST validate the originating version of any session ticket
	or token and not accept one issued from a different version. A	or token and not accept one issued from a different version. A
	rejected ticket results in falling back to a full TLS handshake,	rejected ticket results in falling back to a full TLS handshake,
	without 0-RTT. A rejected token results in the client address	without 0-RTT. A rejected token results in the client address
	remaining unverified, which limits the amount of data the server can	remaining unverified, which limits the amount of data the server can
	send.	send.

	After compatible version negotiation, any resulting session ticket	After compatible version negotiation, any resulting session ticket
	maps to the negotiated version rather than the original one.	maps to the negotiated version rather than the original one.

	skipping to change at line 302 ¶	skipping to change at line 304 ¶
	Clients interested in combating middlebox ossification can initiate a	Clients interested in combating middlebox ossification can initiate a
	connection using version 2 if they are reasonably certain the server	connection using version 2 if they are reasonably certain the server
	supports it and if they are willing to suffer a round-trip penalty if	supports it and if they are willing to suffer a round-trip penalty if
	they are incorrect. In particular, a server that issues a session	they are incorrect. In particular, a server that issues a session
	ticket for version 2 indicates an intent to maintain version 2	ticket for version 2 indicates an intent to maintain version 2
	support while the ticket remains valid, even if support cannot be	support while the ticket remains valid, even if support cannot be
	guaranteed.	guaranteed.

	7. Applicability	7. Applicability


	This version of QUIC provides no change from QUIC version 1 relating	QUIC version 2 provides no change from QUIC version 1 for the
	to the capabilities available to applications. Therefore, all	capabilities available to applications. Therefore, all Application-
	Application-Layer Protocol Negotiation (ALPN) [RFC7301] codepoints	Layer Protocol Negotiation (ALPN) [RFC7301] codepoints specified to
	specified to operate over QUIC version 1 can also operate over this	operate over QUIC version 1 can also operate over this version of
	version of QUIC. In particular, both the "h3" [HTTP/3] and "doq"	QUIC. In particular, both the "h3" [HTTP/3] and "doq" [RFC9250]
	[RFC9250] ALPNs can operate over QUIC version 2.	ALPNs can operate over QUIC version 2.

	Unless otherwise stated, all QUIC extensions defined to work with	Unless otherwise stated, all QUIC extensions defined to work with
	version 1 also work with version 2.	version 1 also work with version 2.

	8. Security Considerations	8. Security Considerations

	QUIC version 2 introduces no changes to the security or privacy	QUIC version 2 introduces no changes to the security or privacy
	properties of QUIC version 1.	properties of QUIC version 1.

	The mandatory version negotiation mechanism guards against downgrade	The mandatory version negotiation mechanism guards against downgrade

	skipping to change at line 361 ¶	skipping to change at line 363 ¶
	[QUIC-RECOVERY]	[QUIC-RECOVERY]
	Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection	Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
	and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,	and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
	May 2021, <https://www.rfc-editor.org/info/rfc9002>.	May 2021, <https://www.rfc-editor.org/info/rfc9002>.

	[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure	[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
	QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,	QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
	<https://www.rfc-editor.org/info/rfc9001>.	<https://www.rfc-editor.org/info/rfc9001>.

	[QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version	[QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version

	Negotiation for QUIC", RFC 9368, DOI 10.17487/RFC9368,	Negotiation for QUIC", RFC 9368, DOI 10.17487/RFC9368, May
	February 2023, <https://www.rfc-editor.org/info/rfc9368>.	2023, <https://www.rfc-editor.org/info/rfc9368>.

	[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>.

	[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>.


End of changes. 7 change blocks.
	16 lines changed or deleted	18 lines changed or added
This html diff was produced by rfcdiff 1.48.