| RFC 9369 | QUICv2 | May 2023 |
| Duke | Standards Track | [Page] |
This document specifies QUIC version 2, which is identical to QUIC version 1except for some trivial details. Its purpose is to combat various ossificationvectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.¶
Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses aversion number other than 2 in the wire image, in order to minimize ossificationrisks.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9369.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
QUIC version 1[QUIC] has numerous extension points, including the versionnumber that occupies the second through fifth bytes of every long header (see[QUIC-INVARIANTS]).If experimental versions arerare, and QUIC version 1 constitutes the vast majority of QUICtraffic, there is the potential for middleboxes to ossify on theversion bytes that are usually 0x00000001.¶
In QUIC version 1, Initial packets are encrypted with the version-specific salt,as described inSection 5.2 of [QUIC-TLS]. Protecting Initial packets in thisway allows observers to inspect their contents, which includes the TLS ClientHello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the version 1 key derivation and packet formats.¶
Finally,[QUIC-VN] describes two mechanisms endpoints can use to negotiate which QUIC version to select. The "incompatible" versionnegotiation method can support switching from any QUIC version to anyother version with full generality, at the cost of an additional round trip atthe start of the connection. "Compatible" version negotiation eliminates theround-trip penalty but levies some restrictions on how much the two versions candiffer semantically.¶
QUIC version 2 is meant to mitigate ossification concerns and exercise theversion negotiation mechanisms. The changes provide an example of the minimumset of changes necessary to specify a new QUIC version. However, note that thechoice of the version number on the wire is randomly chosen instead of "2", andthe two bits that identify each Long Header packet type are different fromversion 1; both of these properties are meant to combat ossification and are notstrictly required of a new QUIC version.¶
Any endpoint that supports two versions needs to implement version negotiationto protect against downgrade attacks.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Except for a few differences, QUIC version 2 endpointsMUST implement the QUICversion 1 specification as described in[QUIC],[QUIC-TLS], and[QUIC-RECOVERY]. The remainder of this section lists the differences.¶
The Version field of long headers is 0x6b3343cf. This was generated by takingthe first four bytes of the sha256sum of "QUICv2 version number".¶
All version 2 Long Header packet types are different. The Type field values are:¶
The salt used to derive Initial keys inSection 5.2 of [QUIC-TLS] changes to:¶
initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9¶
This is the first 20 bytes of the sha256sum of "QUICv2 salt".¶
The labels used in[QUIC-TLS] to derive packet protection keys (Section5.1), header protection keys(Section5.4), Retry IntegrityTag keys (Section5.8), and keyupdates (Section6.1) change from"quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to"quicv2 hp", and from "quic ku" to "quicv2 ku" to meet the guidance for newversions in Section9.6 of thatdocument.¶
The key and nonce used for the Retry Integrity Tag (Section 5.8 of [QUIC-TLS])change to:¶
secret = 0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9fkey = 0x8fb4b01b56ac48e260fbcbcead7ccc92nonce = 0xd86969bc2d7c6d9990efb04a¶
The secret is the sha256sum of "QUICv2 retry secret". The key and nonce arederived from this secret with the labels "quicv2 key" and "quicv2 iv",respectively.¶
QUIC version 2 is not intended to deprecate version 1. Endpoints that supportversion 2 might continue support for version 1 to maximize compatibility withother endpoints. In particular, HTTP clients often use Alt-Svc[RFC7838] todiscover QUIC support. As this mechanism does not currently distinguish betweenQUIC versions, HTTP serversSHOULD support multiple versions to reduce theprobability of incompatibility and the cost associated with QUIC versionnegotiation or TCP fallback. For example, an origin advertising support for "h3"in Alt-Svc should support QUIC version 1, as it was the original QUIC versionused by HTTP/3; therefore, some clients will only support that version.¶
Any QUIC endpoint that supports QUIC version 2MUST send, process, and validatethe version_information transport parameter specified in[QUIC-VN] to preventversion downgrade attacks.¶
Note that version 2 meets the definition in[QUIC-VN] of a compatible versionwith version 1, and version 1 is compatible with version 2. Therefore, serverscan use compatible negotiation to switch a connection between the two versions.Endpoints that support both versionsSHOULD support compatible versionnegotiation to avoid a round trip.¶
Compatible version negotiation between versions 1 and 2 follows the samerequirements in either direction. This section uses the terms "originalversion" and "negotiated version" from[QUIC-VN].¶
If the server sends a Retry packet, itMUST use the original version. Theclient ignores Retry packets using other versions. The clientMUST NOT use adifferent version in the subsequent Initial packet that contains the Retrytoken. The serverMAY encode the QUIC version in its Retry token to validatethat the client did not switch versions, and drop the packet if it switched,to enforce client compliance.¶
QUIC version 2 uses the same transport parameters to authenticate the Retry asQUIC version 1. After switching to a negotiated version after a Retry, theserverMUST include the relevant transport parameters to validate that theserver sent the Retry and the connection IDs used in the exchange, as describedinSection 7.3 of [QUIC].¶
The server cannot send CRYPTO frames until it has processed the client'stransport parameters. The serverMUST send all CRYPTO frames usingthe negotiated version.¶
The client learns the negotiated version by observing the first long headerVersion field that differs from the original version. If the client receives aCRYPTO frame from the server in the original version, it indicates that thenegotiated version is equal to the original version.¶
Before the server is able to process transport parameters from the client, itmight need to respond to Initial packets from the client. For these packets, theserver uses the original version.¶
Once the client has learned the negotiated version, itSHOULD send subsequentInitial packets using that version. The serverMUST NOT discard its originalversion Initial receive keys until it successfully processes a Handshakepacket with the negotiated version.¶
Both endpointsMUST send Handshake and 1-RTT packets using the negotiatedversion. An endpointMUST drop packets using any other version. Endpoints haveno need to generate the keying material that would allow them to decrypt orauthenticate such packets.¶
The clientMUST NOT send 0-RTT packets using the negotiated version, even afterprocessing a packet of that version from the server. Servers can accept 0-RTTand then process 0-RTT packets from the original version.¶
TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them. ClientsMUST NOT use a session ticket or token from a QUIC version 1 connection to initiate 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.¶
ServersMUST validate the originating version of any session ticket or token andnot accept one issued from a different version. A rejected ticket results infalling back to a full TLS handshake, without 0-RTT. A rejected token results inthe client address remaining unverified, which limits the amount of data theserver can send.¶
After compatible version negotiation, any resulting session ticketmaps to the negotiated version rather than the original one.¶
QUIC version 2 provides protection against some forms of ossification. Devicesthat assume that all long headers will encode version 1, or that the version 1Initial key derivation formula will remain version-invariant, will not correctlyprocess version 2 packets.¶
However, many middleboxes, such as firewalls, focus on the first packet in aconnection, which will often remain in the version 1 format due to the considerations above.¶
Clients interested in combating middlebox ossification can initiate a 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 they are incorrect. Inparticular, a server that issues a session ticket for version 2 indicates anintent to maintain version 2 support while the ticket remains valid, even ifsupport cannot be guaranteed.¶
QUIC version 2 provides no change from QUIC version 1 for the capabilities available to applications. Therefore, all Application-LayerProtocol Negotiation (ALPN)[RFC7301] codepoints specified to operate overQUIC version 1 can also operate over this version of QUIC. In particular, boththe "h3"[HTTP/3] and "doq"[RFC9250] ALPNs can operate overQUIC version 2.¶
Unless otherwise stated, all QUIC extensions defined to work with version 1 alsowork with version 2.¶
QUIC version 2 introduces no changes to the security or privacy properties ofQUIC version 1.¶
The mandatory version negotiation mechanism guards against downgrade attacks,but downgrades have no security implications, as the version properties areidentical.¶
Support for QUIC version 2 can help an observer to fingerprint both client andserver devices.¶
IANA has added the following entries to the "QUIC Versions"registry maintained at<https://www.iana.org/assignments/quic>.¶
This section shows examples of packet protection so that implementations can beverified incrementally. Samples of Initial packets from both the client and serverplus a Retry packet are defined. These packets use an 8-byte client-chosenDestination Connection ID of 0x8394c8f03e515708. Some intermediate values areincluded. All values are shown in hexadecimal.¶
The labels generated during the execution of the HKDF-Expand-Label function(that is, HkdfLabel.label) and part of the value given to the HKDF-Expandfunction in order to produce its output are:¶
client in: 00200f746c73313320636c69656e7420696e00¶
server in: 00200f746c7331332073657276657220696e00¶
quicv2 key: 001010746c73313320717569637632206b657900¶
quicv2 iv: 000c0f746c7331332071756963763220697600¶
quicv2 hp: 00100f746c7331332071756963763220687000¶
The initial secret is common:¶
initial_secret = HKDF-Extract(initial_salt, cid) = 2062e8b3cd8d52092614b8071d0aa1fb 7c2e3ac193f78b280e72d8f5751f6aba¶
The secrets for protecting client packets are:¶
client_initial_secret = HKDF-Expand-Label(initial_secret, "client in", "", 32) = 14ec9d6eb9fd7af83bf5a668bc17a7e2 83766aade7ecd0891f70f9ff7f4bf47bkey = HKDF-Expand-Label(client_initial_secret, "quicv2 key", "", 16) = 8b1a0bc121284290a29e0971b5cd045div = HKDF-Expand-Label(client_initial_secret, "quicv2 iv", "", 12) = 91f73e2351d8fa91660e909fhp = HKDF-Expand-Label(client_initial_secret, "quicv2 hp", "", 16) = 45b95e15235d6f45a6b19cbcb0294ba9¶
The secrets for protecting server packets are:¶
server_initial_secret = HKDF-Expand-Label(initial_secret, "server in", "", 32) = 0263db1782731bf4588e7e4d93b74639 07cb8cd8200b5da55a8bd488eafc37c1key = HKDF-Expand-Label(server_initial_secret, "quicv2 key", "", 16) = 82db637861d55e1d011f19ea71d5d2a7iv = HKDF-Expand-Label(server_initial_secret, "quicv2 iv", "", 12) = dd13c276499c0249d3310652hp = HKDF-Expand-Label(server_initial_secret, "quicv2 hp", "", 16) = edf6d05c83121201b436e16877593c3a¶
The client sends an Initial packet. The unprotected payload of this packetcontains the following CRYPTO frame, plus enough PADDING frames to make a1162-byte payload:¶
060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e86804fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578616d706c652e636f6dff01000100000a 00080006001d0017001800100007000504616c706e0005000501000000000033 00260024001d00209370b2c9caa47fbabaf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b0003020304000d0010000e0403050306030203080408 050806002d00020101001c00024001003900320408ffffffffffffffff050480 00ffff07048000ffff0801100104800075300901100f088394c8f03e51570806 048000ffff¶
The unprotected header indicates a length of 1182 bytes: the 4-byte packetnumber, 1162 bytes of frames, and the 16-byte authentication tag. The headerincludes the connection ID and a packet number of 2:¶
d36b3343cf088394c8f03e5157080000449e00000002¶
Protecting the payload produces an output that is sampled for header protection.Because the header uses a 4-byte packet number encoding, the first 16 bytes ofthe protected payload is sampled and then applied to the header as follows:¶
sample = ffe67b6abcdb4298b485dd04de806071mask = AES-ECB(hp, sample)[0..4] = 94a0c95e80header[0] ^= mask[0] & 0x0f = d7header[18..21] ^= mask[1..4] = a0c95e82header = d76b3343cf088394c8f03e5157080000449ea0c95e82¶
The resulting protected packet is:¶
d76b3343cf088394c8f03e5157080000 449ea0c95e82ffe67b6abcdb4298b485dd04de806071bf03dceebfa162e75d6c 96058bdbfb127cdfcbf903388e99ad049f9a3dd4425ae4d0992cfff18ecf0fdb 5a842d09747052f17ac2053d21f57c5d250f2c4f0e0202b70785b7946e992e58 a59ac52dea6774d4f03b55545243cf1a12834e3f249a78d395e0d18f4d766004 f1a2674802a747eaa901c3f10cda5500cb9122faa9f1df66c392079a1b40f0de 1c6054196a11cbea40afb6ef5253cd6818f6625efce3b6def6ba7e4b37a40f77 32e093daa7d52190935b8da58976ff3312ae50b187c1433c0f028edcc4c2838b 6a9bfc226ca4b4530e7a4ccee1bfa2a3d396ae5a3fb512384b2fdd851f784a65 e03f2c4fbe11a53c7777c023462239dd6f7521a3f6c7d5dd3ec9b3f233773d4b 46d23cc375eb198c63301c21801f6520bcfb7966fc49b393f0061d974a2706df 8c4a9449f11d7f3d2dcbb90c6b877045636e7c0c0fe4eb0f697545460c806910 d2c355f1d253bc9d2452aaa549e27a1fac7cf4ed77f322e8fa894b6a83810a34 b361901751a6f5eb65a0326e07de7c1216ccce2d0193f958bb3850a833f7ae43 2b65bc5a53975c155aa4bcb4f7b2c4e54df16efaf6ddea94e2c50b4cd1dfe060 17e0e9d02900cffe1935e0491d77ffb4fdf85290fdd893d577b1131a610ef6a5 c32b2ee0293617a37cbb08b847741c3b8017c25ca9052ca1079d8b78aebd4787 6d330a30f6a8c6d61dd1ab5589329de714d19d61370f8149748c72f132f0fc99 f34d766c6938597040d8f9e2bb522ff99c63a344d6a2ae8aa8e51b7b90a4a806 105fcbca31506c446151adfeceb51b91abfe43960977c87471cf9ad4074d30e1 0d6a7f03c63bd5d4317f68ff325ba3bd80bf4dc8b52a0ba031758022eb025cdd 770b44d6d6cf0670f4e990b22347a7db848265e3e5eb72dfe8299ad7481a4083 22cac55786e52f633b2fb6b614eaed18d703dd84045a274ae8bfa73379661388 d6991fe39b0d93debb41700b41f90a15c4d526250235ddcd6776fc77bc97e7a4 17ebcb31600d01e57f32162a8560cacc7e27a096d37a1a86952ec71bd89a3e9a 30a2a26162984d7740f81193e8238e61f6b5b984d4d3dfa033c1bb7e4f0037fe bf406d91c0dccf32acf423cfa1e7071010d3f270121b493ce85054ef58bada42 310138fe081adb04e2bd901f2f13458b3d6758158197107c14ebb193230cd115 7380aa79cae1374a7c1e5bbcb80ee23e06ebfde206bfb0fcbc0edc4ebec30966 1bdd908d532eb0c6adc38b7ca7331dce8dfce39ab71e7c32d318d136b6100671 a1ae6a6600e3899f31f0eed19e3417d134b90c9058f8632c798d4490da498730 7cba922d61c39805d072b589bd52fdf1e86215c2d54e6670e07383a27bbffb5a ddf47d66aa85a0c6f9f32e59d85a44dd5d3b22dc2be80919b490437ae4f36a0a e55edf1d0b5cb4e9a3ecabee93dfc6e38d209d0fa6536d27a5d6fbb17641cde2 7525d61093f1b28072d111b2b4ae5f89d5974ee12e5cf7d5da4d6a31123041f3 3e61407e76cffcdcfd7e19ba58cf4b536f4c4938ae79324dc402894b44faf8af bab35282ab659d13c93f70412e85cb199a37ddec600545473cfb5a05e08d0b20 9973b2172b4d21fb69745a262ccde96ba18b2faa745b6fe189cf772a9f84cbfc¶
The server sends the following payload in response, including an ACK frame, aCRYPTO frame, and no PADDING frames:¶
02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf73988cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c940d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00020304¶
The header from the server includes a new connection ID and a 2-byte packetnumber encoding for a packet number of 1:¶
d16b3343cf0008f067a5502a4262b50040750001¶
As a result, after protection, the header protection sample is taken, startingfrom the third protected byte:¶
sample = 6f05d8a4398c47089698baeea26b91ebmask = 4dd92e91eaheader = dc6b3343cf0008f067a5502a4262b5004075d92f¶
The final protected packet is then:¶
dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17f9af6e16886c61bfc703106fbaf3cb4c fa52382dd16a393e42757507698075b2c984c707f0a0812d8cd5a6881eaf21ce da98f4bd23f6fe1a3e2c43edd9ce7ca84bed8521e2e140¶
This shows a Retry packet that might be sent in response to the Initial packetinAppendix A.2. The integrity check includes the client-chosenconnection ID value of 0x8394c8f03e515708, but that value is notincluded in the final Retry packet:¶
cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d955543665dcc7b6¶
This example shows some of the steps required to protect a packet with a short header. It uses AEAD_CHACHA20_POLY1305.¶
In this example, TLS produces an application write secret from which a serveruses HKDF-Expand-Label to produce four values: a key, an Initialization Vector (IV), a headerprotection key, and the secret that will be used after keys are updated (thislast value is not used further in this example).¶
secret = 9ac312a7f877468ebe69422748ad00a1 5443f18203a07d6060f688f30f21632bkey = HKDF-Expand-Label(secret, "quicv2 key", "", 32) = 3bfcddd72bcf02541d7fa0dd1f5f9eee a817e09a6963a0e6c7df0f9a1bab90f2iv = HKDF-Expand-Label(secret, "quicv2 iv", "", 12) = a6b5bc6ab7dafce30ffff5ddhp = HKDF-Expand-Label(secret, "quicv2 hp", "", 32) = d659760d2ba434a226fd37b35c69e2da 8211d10c4f12538787d65645d5d1b8e2ku = HKDF-Expand-Label(secret, "quicv2 ku", "", 32) = c69374c49e3d2a9466fa689e49d476db 5d0dfbc87d32ceeaa6343fd0ae4c7d88¶
The following shows the steps involved in protecting a minimal packet with anempty Destination Connection ID. This packet contains a single PING frame (thatis, a payload of just 0x01) and has a packet number of 654360564. In thisexample, using a packet number of length 3 (that is, 49140 is encoded) avoidshaving to pad the payload of the packet; PADDING frames would be needed if thepacket number is encoded on fewer bytes.¶
pn = 654360564 (decimal)nonce = a6b5bc6ab7dafce328ff4a29unprotected header = 4200bff4payload plaintext = 01payload ciphertext = 0ae7b6b932bc27d786f4bc2bb20f2162ba¶
The resulting ciphertext is the minimum size possible. One byte is skipped toproduce the sample for header protection.¶
sample = e7b6b932bc27d786f4bc2bb20f2162bamask = 97580e32bfheader = 5558b1c6¶
The protected packet is the smallest possible packet size of 21 bytes.¶
packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba¶
The author would like to thankChristian Huitema,Lucas Pardue,Kyle Rose,Anthony Rossi,Zahed Sarker,David Schinazi,Tatsuhiro Tsujikawa, andMartin Thomson for their helpful suggestions.¶