rfc9369.original   rfc9369.txt 
QUIC M. Duke Internet Engineering Task Force (IETF) M. Duke
Internet-Draft Google LLC Request for Comments: 9369 Google LLC
Intended status: Standards Track 15 December 2022 Category: Standards Track May 2023
Expires: 18 June 2023 ISSN: 2070-1721
QUIC Version 2 QUIC Version 2
draft-ietf-quic-v2-10
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 risk. number other than 2 in the wire image, in order to minimize
ossification risks.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://quicwg.org/
quic-v2/draft-ietf-quic-v2.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-ietf-
quic-v2/.
Discussion of this document takes place on the QUIC Working Group
mailing list (mailto:quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/quic/. Subscribe at
https://www.ietf.org/mailman/listinfo/quic/.
Source for this draft and an issue tracker can be found at
https://github.com/quicwg/quic-v2.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 18 June 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9369.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions
3. Differences with QUIC Version 1 . . . . . . . . . . . . . . . 4 3. Differences with QUIC Version 1
3.1. Version Field . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Version Field
3.2. Long Header Packet Types . . . . . . . . . . . . . . . . 4 3.2. Long Header Packet Types
3.3. Cryptography changes . . . . . . . . . . . . . . . . . . 5 3.3. Cryptography Changes
3.3.1. Initial Salt . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Initial Salt
3.3.2. HKDF Labels . . . . . . . . . . . . . . . . . . . . . 5 3.3.2. HMAC-based Key Derivation Function (HKDF) Labels
3.3.3. Retry Integrity Tag . . . . . . . . . . . . . . . . . 5 3.3.3. Retry Integrity Tag
4. Version Negotiation Considerations . . . . . . . . . . . . . 6 4. Version Negotiation Considerations
4.1. Compatible Negotiation Requirements . . . . . . . . . . . 6 4.1. Compatible Negotiation Requirements
5. TLS Resumption and NEW_TOKEN Tokens . . . . . . . . . . . . . 7 5. TLS Resumption and NEW_TOKEN Tokens
6. Ossification Considerations . . . . . . . . . . . . . . . . . 8 6. Ossification Considerations
7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Applicability
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References
Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 10 Appendix A. Sample Packet Protection
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.1. Keys
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 11 A.2. Client Initial
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 13 A.3. Server Initial
A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.4. Retry
A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 14 A.5. ChaCha20-Poly1305 Short Header Packet
Acknowledgments
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Author's Address
Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 16
C.1. since draft-ietf-quic-v2-09 . . . . . . . . . . . . . . . 16
C.2. since draft-ietf-quic-v2-08 . . . . . . . . . . . . . . . 16
C.3. since draft-ietf-quic-v2-07 . . . . . . . . . . . . . . . 16
C.4. since draft-ietf-quic-v2-06 . . . . . . . . . . . . . . . 16
C.5. since draft-ietf-quic-v2-05 . . . . . . . . . . . . . . . 16
C.6. since draft-ietf-quic-v2-04 . . . . . . . . . . . . . . . 16
C.7. since draft-ietf-quic-v2-03 . . . . . . . . . . . . . . . 17
C.8. since draft-ietf-quic-v2-02 . . . . . . . . . . . . . . . 17
C.9. since draft-ietf-quic-v2-01 . . . . . . . . . . . . . . . 17
C.10. since draft-ietf-quic-v2-00 . . . . . . . . . . . . . . . 17
C.11. since draft-duke-quic-v2-02 . . . . . . . . . . . . . . . 17
C.12. since draft-duke-quic-v2-01 . . . . . . . . . . . . . . . 17
C.13. since draft-duke-quic-v2-00 . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
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] provides two mechanisms for endpoints to negotiate Finally, [QUIC-VN] describes two mechanisms endpoints can use to
the QUIC version to use. The "incompatible" version negotiation negotiate which QUIC version to select. The "incompatible" version
method can support switching from any QUIC version to any other negotiation method can support switching from any QUIC version to any
version with full generality, at the cost of an additional round-trip other version with full generality, at the cost of an additional
at the start of the connection. "Compatible" version negotiation round trip at the start of the connection. "Compatible" version
eliminates the round-trip penalty but levies some restrictions on how negotiation eliminates the round-trip penalty but levies some
much the two versions can differ semantically. restrictions on how much the two versions can differ semantically.
QUIC version 2 is meant to mitigate ossification concerns and QUIC version 2 is meant to mitigate ossification concerns and
exercise the version negotiation mechanisms. The changes provide an exercise the version negotiation mechanisms. The changes provide an
example of the minimum set of changes necessary to specify a new QUIC example of the minimum set of changes necessary to specify a new QUIC
version. However, note that the choice of the version number on the version. However, note that the choice of the version number on the
wire is randomly chosen instead of "2", and the two bits that wire is randomly chosen instead of "2", and the two bits that
identify each long header packet type are different from version 1; identify each Long Header packet type are different from version 1;
both of these properties are meant to combat ossification and are not both of these properties are meant to combat ossification and are not
strictly required of a new QUIC version. strictly required of a new QUIC version.
Any endpoint that supports two versions needs to implement version Any endpoint that supports two versions needs to implement version
negotiation to protect against downgrade attacks. negotiation to protect against downgrade attacks.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 4, line 38 skipping to change at line 139
the QUIC version 1 specification as described in [QUIC], [QUIC-TLS], the QUIC version 1 specification as described in [QUIC], [QUIC-TLS],
and [QUIC-RECOVERY]. The remainder of this section lists the and [QUIC-RECOVERY]. The remainder of this section lists the
differences. differences.
3.1. Version Field 3.1. Version Field
The Version field of long headers is 0x6b3343cf. This was generated The Version field of long headers is 0x6b3343cf. This was generated
by taking the first four bytes of the sha256sum of "QUICv2 version by taking the first four bytes of the sha256sum of "QUICv2 version
number". number".
*RFC Editor's Note:* Please remove the sentence below prior to
publication of a final version of this document.
This version number will not change in subsequent versions of this
draft, unless there is a behavior change that breaks compatibility.
3.2. Long Header Packet Types 3.2. Long Header Packet Types
All version 2 long header packet types are different. The Type field All version 2 Long Header packet types are different. The Type field
values are: values are:
* 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. HKDF Labels 3.3.2. HMAC-based Key Derivation Function (HKDF) Labels
*RFC Editor's Note:* Please ensure that the strings in quotes are
not split up in a line break in this section.
The labels used in [QUIC-TLS] to derive packet protection keys The labels used in [QUIC-TLS] to derive packet protection keys
(Section 5.1), header protection keys (Section 5.4), Retry Integrity (Section 5.1), header protection keys (Section 5.4), Retry Integrity
Tag keys (Section 5.8), and key updates (Section 6.1) change from Tag keys (Section 5.8), and key updates (Section 6.1) change from
"quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from
hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku" to meet
guidance for new versions in Section 9.6 of that document. the guidance for new versions in Section 9.6 of that document.
3.3.3. Retry Integrity Tag 3.3.3. Retry Integrity Tag
The key and nonce used for the Retry Integrity Tag (Section 5.8 of The key and nonce used for the Retry Integrity Tag (Section 5.8 of
[QUIC-TLS]) change to: [QUIC-TLS]) change to:
secret = secret =
0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f 0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f
key = 0x8fb4b01b56ac48e260fbcbcead7ccc92 key = 0x8fb4b01b56ac48e260fbcbcead7ccc92
nonce = 0xd86969bc2d7c6d9990efb04a nonce = 0xd86969bc2d7c6d9990efb04a
skipping to change at page 6, line 15 skipping to change at line 196
4. Version Negotiation Considerations 4. Version Negotiation Considerations
QUIC version 2 is not intended to deprecate version 1. Endpoints QUIC version 2 is not intended to deprecate version 1. Endpoints
that support version 2 might continue support for version 1 to that support version 2 might continue support for version 1 to
maximize compatibility with other endpoints. In particular, HTTP maximize compatibility with other endpoints. In particular, HTTP
clients often use Alt-Svc [RFC7838] to discover QUIC support. As clients often use Alt-Svc [RFC7838] to discover QUIC support. As
this mechanism does not currently distinguish between QUIC versions, this mechanism does not currently distinguish between QUIC versions,
HTTP servers SHOULD support multiple versions to reduce the HTTP servers SHOULD support multiple versions to reduce the
probability of incompatibility and the cost associated with QUIC probability of incompatibility and the cost associated with QUIC
version negotiation or TCP fallback. For example, an origin version negotiation or TCP fallback. For example, an origin
advertising support for "h3" in Alt-Svc should support QUIC version 1 advertising support for "h3" in Alt-Svc should support QUIC version
as it was the original QUIC version used by HTTP/3, and therefore 1, as it was the original QUIC version used by HTTP/3; therefore,
some clients will only support that version. some clients will only support that version.
Any QUIC endpoint that supports QUIC version 2 MUST send, process, Any QUIC endpoint that supports QUIC version 2 MUST send, process,
and validate the version_information transport parameter specified in and validate the version_information transport parameter specified in
[QUIC-VN] to prevent version downgrade attacks. [QUIC-VN] to prevent version downgrade attacks.
Note that version 2 meets the [QUIC-VN] definition of a compatible Note that version 2 meets the definition in [QUIC-VN] of a compatible
version with version 1, and version 1 is compatible with version 2. version with version 1, and version 1 is compatible with version 2.
Therefore, servers can use compatible negotiation to switch a Therefore, servers can use compatible negotiation to switch a
connection between the two versions. Endpoints that support both connection between the two versions. Endpoints that support both
versions SHOULD support compatible version negotiation to avoid a versions SHOULD support compatible version negotiation to avoid a
round trip. round trip.
4.1. Compatible Negotiation Requirements 4.1. Compatible Negotiation Requirements
Compatible version negotiation between versions 1 and 2 follow the Compatible version negotiation between versions 1 and 2 follows the
same requirements in either direction. This section uses the terms same requirements in either direction. This section uses the terms
"original version" and "negotiated version" from [QUIC-VN]. "original version" and "negotiated version" from [QUIC-VN].
If the server sends a Retry packet, it MUST use the original version. If the server sends a Retry packet, it MUST use the original version.
The client ignores Retry packets using other versions. The client The client ignores Retry packets using other versions. The client
MUST NOT use a different version in the subsequent Initial packet MUST NOT use a different version in the subsequent Initial packet
that contains the Retry token. The server MAY encode the QUIC that contains the Retry token. The server MAY encode the QUIC
version in its Retry token to validate that the client did not switch version in its Retry token to validate that the client did not switch
versions, and drop the packet if it switched, to enforce client versions, and drop the packet if it switched, to enforce client
compliance. compliance.
skipping to change at page 7, line 12 skipping to change at line 239
connection IDs used in the exchange, as described in Section 7.3 of connection IDs used in the exchange, as described in Section 7.3 of
[QUIC]. [QUIC].
The server cannot send CRYPTO frames until it has processed the The server cannot send CRYPTO frames until it has processed the
client's transport parameters. The server MUST send all CRYPTO client's transport parameters. The server MUST send all CRYPTO
frames using the negotiated version. frames using the negotiated version.
The client learns the negotiated version by observing the first long The client learns the negotiated version by observing the first long
header Version field that differs from the original version. If the header Version field that differs from the original version. If the
client receives a CRYPTO frame from the server in the original client receives a CRYPTO frame from the server in the original
version, that indicates that the negotiated version is equal to the version, it indicates that the negotiated version is equal to the
original version. original version.
Before the server is able to process transport parameters from the Before the server is able to process transport parameters from the
client, it might need to respond to Initial packets from the client. client, it might need to respond to Initial packets from the client.
For these packets, the server uses the original version. For these packets, the server uses the original version.
Once the client has learned the negotiated version, it SHOULD send Once the client has learned the negotiated version, it SHOULD send
subsequent Initial packets using that version. The server MUST NOT subsequent Initial packets using that version. The server MUST NOT
discard its original version Initial receive keys until it discard its original version Initial receive keys until it
successfully processes a Handshake packet with the negotiated successfully processes a Handshake packet with the negotiated
skipping to change at page 7, line 40 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, or 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 original one. maps to the negotiated version rather than the original one.
6. Ossification Considerations 6. Ossification Considerations
QUIC version 2 provides protection against some forms of QUIC version 2 provides protection against some forms of
ossification. Devices that assume that all long headers will encode ossification. Devices that assume that all long headers will encode
version 1, or that the version 1 Initial key derivation formula will version 1, or that the version 1 Initial key derivation formula will
remain version-invariant, will not correctly process version 2 remain version-invariant, will not correctly process version 2
packets. packets.
However, many middleboxes, such as firewalls, focus on the first However, many middleboxes, such as firewalls, focus on the first
packet in a connection, which will often remain in the version 1 packet in a connection, which will often remain in the version 1
format due to the considerations above. format due to the considerations above.
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 either reasonably certain the connection using version 2 if they are reasonably certain the server
server supports it, or 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
attacks, but downgrades have no security implications, as the version attacks, but downgrades have no security implications, as the version
properties are identical. properties are identical.
Support for QUIC version 2 can help an observer to fingerprint both Support for QUIC version 2 can help an observer to fingerprint both
client and server devices. client and server devices.
9. IANA Considerations 9. IANA Considerations
This document requests that IANA add the following entry to the QUIC IANA has added the following entries to the "QUIC Versions" registry
version registry maintained at maintained at <https://www.iana.org/assignments/quic>.
<https://www.iana.org/assignments/quic/quic.xhtml#quic-versions>.
Value: 0x6b3343cf Value: 0x6b3343cf
Status: permanent Status: permanent
Specification: This Document Specification: RFC 9369
Change Controller: IETF Change Controller: IETF
Contact: QUIC WG Contact: QUIC WG
Value: 0x709a50c4 Value: 0x709a50c4
Status: provisional Status: provisional
Specification: This Document Specification: RFC 9369
Change Controller: IETF Change Controller: IETF
Contact: QUIC WG Contact: QUIC WG
Note: QUIC v2 draft codepoint Notes: QUIC v2 draft codepoint
10. References 10. References
10.1. Normative References 10.1. Normative References
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[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/rfc/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/rfc/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", Work in Progress, Internet-Draft, Negotiation for QUIC", RFC 9368, DOI 10.17487/RFC9368, May
draft-ietf-quic-version-negotiation-13, 6 November 2022, 2023, <https://www.rfc-editor.org/info/rfc9368>.
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
version-negotiation-13>.
[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/rfc/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/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, [HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>. June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[QUIC-INVARIANTS] [QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC", Thomson, M., "Version-Independent Properties of QUIC",
RFC 8999, DOI 10.17487/RFC8999, May 2021, RFC 8999, DOI 10.17487/RFC8999, May 2021,
<https://www.rfc-editor.org/rfc/rfc8999>. <https://www.rfc-editor.org/info/rfc8999>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/rfc/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[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/rfc/rfc9250>. <https://www.rfc-editor.org/info/rfc9250>.
Appendix A. Sample Packet Protection Appendix A. Sample Packet Protection
This section shows examples of packet protection so that This section shows examples of packet protection so that
implementations can be verified incrementally. Samples of Initial implementations can be verified incrementally. Samples of Initial
packets from both client and server plus a Retry packet are defined. packets from both the client and server plus a Retry packet are
These packets use an 8-byte client-chosen Destination Connection ID defined. These packets use an 8-byte client-chosen Destination
of 0x8394c8f03e515708. Some intermediate values are included. All Connection ID of 0x8394c8f03e515708. Some intermediate values are
values are shown in hexadecimal. included. All values are shown in hexadecimal.
A.1. Keys A.1. Keys
The labels generated during the execution of the HKDF-Expand-Label The labels generated during the execution of the HKDF-Expand-Label
function (that is, HkdfLabel.label) and part of the value given to function (that is, HkdfLabel.label) and part of the value given to
the HKDF-Expand function in order to produce its output are: the HKDF-Expand function in order to produce its output are:
client in: 00200f746c73313320636c69656e7420696e00 client in: 00200f746c73313320636c69656e7420696e00
server in: 00200f746c7331332073657276657220696e00 server in: 00200f746c7331332073657276657220696e00
skipping to change at page 12, line 20 skipping to change at line 483
0d0010000e0403050306030203080408 050806002d00020101001c0002400100 0d0010000e0403050306030203080408 050806002d00020101001c0002400100
3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000 3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
75300901100f088394c8f03e51570806 048000ffff 75300901100f088394c8f03e51570806 048000ffff
The unprotected header indicates a length of 1182 bytes: the 4-byte The unprotected header indicates a length of 1182 bytes: the 4-byte
packet number, 1162 bytes of frames, and the 16-byte authentication packet number, 1162 bytes of frames, and the 16-byte authentication
tag. The header includes the connection ID and a packet number of 2: tag. The header includes the connection ID and a packet number of 2:
d36b3343cf088394c8f03e5157080000449e00000002 d36b3343cf088394c8f03e5157080000449e00000002
Protecting the payload produces output that is sampled for header Protecting the payload produces an output that is sampled for header
protection. Because the header uses a 4-byte packet number encoding, protection. Because the header uses a 4-byte packet number encoding,
the first 16 bytes of the protected payload is sampled and then the first 16 bytes of the protected payload is sampled and then
applied to the header as follows: applied to the header as follows:
sample = ffe67b6abcdb4298b485dd04de806071 sample = ffe67b6abcdb4298b485dd04de806071
mask = AES-ECB(hp, sample)[0..4] mask = AES-ECB(hp, sample)[0..4]
= 94a0c95e80 = 94a0c95e80
header[0] ^= mask[0] & 0x0f header[0] ^= mask[0] & 0x0f
skipping to change at page 14, line 4 skipping to change at line 549
A.3. Server Initial A.3. Server Initial
The server sends the following payload in response, including an ACK The server sends the following payload in response, including an ACK
frame, a CRYPTO frame, and no PADDING frames: frame, a CRYPTO frame, and no PADDING frames:
02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739 02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94 88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00 0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
020304 020304
The header from the server includes a new connection ID and a 2-byte The header from the server includes a new connection ID and a 2-byte
packet number encoding for a packet number of 1: packet number encoding for a packet number of 1:
d16b3343cf0008f067a5502a4262b50040750001 d16b3343cf0008f067a5502a4262b50040750001
As a result, after protection, the header protection sample is taken As a result, after protection, the header protection sample is taken,
starting from the third protected byte: starting from the third protected byte:
sample = 6f05d8a4398c47089698baeea26b91eb sample = 6f05d8a4398c47089698baeea26b91eb
mask = 4dd92e91ea mask = 4dd92e91ea
header = dc6b3343cf0008f067a5502a4262b5004075d92f header = dc6b3343cf0008f067a5502a4262b5004075d92f
The final protected packet is then: The final protected packet is then:
dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698 dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698
baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17 baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17
skipping to change at page 14, line 37 skipping to change at line 583
Initial packet in Appendix A.2. The integrity check includes the Initial packet in Appendix A.2. The integrity check includes the
client-chosen connection ID value of 0x8394c8f03e515708, but that client-chosen connection ID value of 0x8394c8f03e515708, but that
value is not included in the final Retry packet: value is not included in the final Retry packet:
cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436 cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436
65dcc7b6 65dcc7b6
A.5. ChaCha20-Poly1305 Short Header Packet A.5. ChaCha20-Poly1305 Short Header Packet
This example shows some of the steps required to protect a packet This example shows some of the steps required to protect a packet
with a short header. This example uses AEAD_CHACHA20_POLY1305. with a short header. It uses AEAD_CHACHA20_POLY1305.
In this example, TLS produces an application write secret from which In this example, TLS produces an application write secret from which
a server uses HKDF-Expand-Label to produce four values: a key, an IV, a server uses HKDF-Expand-Label to produce four values: a key, an
a header protection key, and the secret that will be used after keys Initialization Vector (IV), a header protection key, and the secret
are updated (this last value is not used further in this example). that will be used after keys are updated (this last value is not used
further in this example).
secret secret
= 9ac312a7f877468ebe69422748ad00a1 = 9ac312a7f877468ebe69422748ad00a1
5443f18203a07d6060f688f30f21632b 5443f18203a07d6060f688f30f21632b
key = HKDF-Expand-Label(secret, "quicv2 key", "", 32) key = HKDF-Expand-Label(secret, "quicv2 key", "", 32)
= 3bfcddd72bcf02541d7fa0dd1f5f9eee = 3bfcddd72bcf02541d7fa0dd1f5f9eee
a817e09a6963a0e6c7df0f9a1bab90f2 a817e09a6963a0e6c7df0f9a1bab90f2
iv = HKDF-Expand-Label(secret, "quicv2 iv", "", 12) iv = HKDF-Expand-Label(secret, "quicv2 iv", "", 12)
skipping to change at page 16, line 5 skipping to change at line 636
sample = e7b6b932bc27d786f4bc2bb20f2162ba sample = e7b6b932bc27d786f4bc2bb20f2162ba
mask = 97580e32bf mask = 97580e32bf
header = 5558b1c6 header = 5558b1c6
The protected packet is the smallest possible packet size of 21 The protected packet is the smallest possible packet size of 21
bytes. bytes.
packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba
Appendix B. Acknowledgments Acknowledgments
The author would like to thank Christian Huitema, Lucas Pardue, Kyle The author would like to thank Christian Huitema, Lucas Pardue, Kyle
Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro
Tsujikawa, and Martin Thomson for their helpful suggestions. Tsujikawa, and Martin Thomson for their helpful suggestions.
Appendix C. Changelog
*RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document.
C.1. since draft-ietf-quic-v2-09
* Added note for provisional IANA registration
C.2. since draft-ietf-quic-v2-08
* Updated IANA considerations in accordance with new constants
C.3. since draft-ietf-quic-v2-07
* Generated new constants and test vectors
C.4. since draft-ietf-quic-v2-06
* Clients MUST NOT use TLS resumption tickets across versions
* Servers SHOULD support multiple versions
* Clients SHOULD check path support for QUIC independently by
version
* Minor editorial changes
C.5. since draft-ietf-quic-v2-05
* Servers MUST use the negotiated version in Initials with CRYPTO
frames.
* Clarified when clients "learn" the negotiated version as required
in the VN draft.
* Comments from SECDIR review.
C.6. since draft-ietf-quic-v2-04
* Clarified 0-RTT handling
* Editorial comments from Zahed Sarker.
C.7. since draft-ietf-quic-v2-03
* a v2 session ticket is an indication of v2 support
* a v1-only extension is theoretically possible
* editorial fixes
C.8. since draft-ietf-quic-v2-02
* Editorial comments from Lucas Pardue
C.9. since draft-ietf-quic-v2-01
* Ban use of NEW_TOKEN tokens across versions
* version-info transport parameter required for all v2 endpoints
* Explicitly list known ALPN compatibility
C.10. since draft-ietf-quic-v2-00
* Expanded requirements for compatible version negotiation
* Added test vectors
* Greased the packet type codepoints
* Random version number
* Clarified requirement to use QUIC-VN
* Banned use of resumption tokens across versions
C.11. since draft-duke-quic-v2-02
* Converted to adopted draft
* Deleted references to QUIC improvements
* Clarified status of QUIC extensions
C.12. since draft-duke-quic-v2-01
* Made the final version number TBD.
* Added ALPN considerations
C.13. since draft-duke-quic-v2-00
* Added provisional versions for interop
* Change the v1 Retry Tag secret
* Change labels to create full key separation
Author's Address Author's Address
Martin Duke Martin Duke
Google LLC Google LLC
Email: martin.h.duke@gmail.com Email: martin.h.duke@gmail.com
 End of changes. 51 change blocks. 
260 lines changed or deleted 119 lines changed or added

This html diff was produced by rfcdiff 1.48.