idnits 2.17.1 draft-ietf-quic-v2-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (1 June 2022) is 694 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 497 == Outdated reference: A later version (-14) exists of draft-ietf-quic-version-negotiation-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Duke 3 Internet-Draft Google LLC 4 Intended status: Standards Track 1 June 2022 5 Expires: 3 December 2022 7 QUIC Version 2 8 draft-ietf-quic-v2-04 10 Abstract 12 This document specifies QUIC version 2, which is identical to QUIC 13 version 1 except for some trivial details. Its purpose is to combat 14 various ossification vectors and exercise the version negotiation 15 framework. It also serves as a template for the minimum changes in 16 any future version of QUIC. 18 Note that "version 2" is an informal name for this proposal that 19 indicates it is the second standards-track QUIC version. The 20 protocol specified here uses a version number other than 2 in the 21 wire image. 23 About This Document 25 This note is to be removed before publishing as an RFC. 27 The latest revision of this draft can be found at https://quicwg.org/ 28 quic-v2/draft-ietf-quic-v2.html. Status information for this 29 document may be found at https://datatracker.ietf.org/doc/draft-ietf- 30 quic-v2/. 32 Discussion of this document takes place on the QUIC Working Group 33 mailing list (mailto:quic@ietf.org), which is archived at 34 https://mailarchive.ietf.org/arch/browse/quic/. 36 Source for this draft and an issue tracker can be found at 37 https://github.com/quicwg/quic-v2. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 3 December 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Differences with QUIC Version 1 . . . . . . . . . . . . . . . 4 75 3.1. Version Field . . . . . . . . . . . . . . . . . . . . . . 4 76 3.2. Long Header Packet Types . . . . . . . . . . . . . . . . 4 77 3.3. Cryptography changes . . . . . . . . . . . . . . . . . . 4 78 3.3.1. Initial Salt . . . . . . . . . . . . . . . . . . . . 4 79 3.3.2. HKDF Labels . . . . . . . . . . . . . . . . . . . . . 4 80 3.3.3. Retry Integrity Tag . . . . . . . . . . . . . . . . . 5 81 4. Version Negotiation Considerations . . . . . . . . . . . . . 5 82 4.1. Compatible Negotiation Requirements . . . . . . . . . . . 5 83 5. TLS Resumption and NEW_TOKEN Tokens . . . . . . . . . . . . . 6 84 6. Ossification Considerations . . . . . . . . . . . . . . . . . 7 85 7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 90 10.2. Informative References . . . . . . . . . . . . . . . . . 8 91 Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 9 92 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 9 93 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 10 94 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 12 95 A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 13 98 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15 99 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 15 100 C.1. since draft-ietf-quic-v2-03 . . . . . . . . . . . . . . . 15 101 C.2. since draft-ietf-quic-v2-02 . . . . . . . . . . . . . . . 15 102 C.3. since draft-ietf-quic-v2-01 . . . . . . . . . . . . . . . 15 103 C.4. since draft-ietf-quic-v2-00 . . . . . . . . . . . . . . . 15 104 C.5. since draft-duke-quic-v2-02 . . . . . . . . . . . . . . . 15 105 C.6. since draft-duke-quic-v2-01 . . . . . . . . . . . . . . . 16 106 C.7. since draft-duke-quic-v2-00 . . . . . . . . . . . . . . . 16 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 109 1. Introduction 111 QUIC [QUIC] has numerous extension points, including the version 112 number that occupies the second through fifth bytes of every long 113 header (see [QUIC-INVARIANTS]). If experimental versions are rare, 114 and QUIC version 1 constitutes the vast majority of QUIC traffic, 115 there is the potential for middleboxes to ossify on the version bytes 116 always being 0x00000001. 118 In QUIC version 1, Initial packets are encrypted with the version- 119 specific salt as described in Section 5.2 of [QUIC-TLS]. Protecting 120 Initial packets in this way allows observers to inspect their 121 contents, which includes the TLS Client Hello or Server Hello 122 messages. Again, there is the potential for middleboxes to ossify on 123 the version 1 key derivation and packet formats. 125 Finally [QUIC-VN] provides two mechanisms for endpoints to negotiate 126 the QUIC version to use. The "incompatible" version negotiation 127 method can support switching from any QUIC version to any other 128 version with full generality, at the cost of an additional round-trip 129 at the start of the connection. "Compatible" version negotiation 130 eliminates the round-trip penalty but levies some restrictions on how 131 much the two versions can differ semantically. 133 QUIC version 2 is meant to mitigate ossification concerns and 134 exercise the version negotiation mechanisms. The only change is a 135 tweak to key derivation inputs to enforce full key separation. Any 136 endpoint that supports two versions needs to implement version 137 negotiation to protect against downgrade attacks. 139 2. Conventions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in 144 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 3. Differences with QUIC Version 1 149 QUIC version 2 endpoints MUST implement the QUIC version 1 150 specification as described in [QUIC], [QUIC-TLS], and 151 [QUIC-LOSSRECOVERY]. However, the following differences apply in 152 version 2. 154 3.1. Version Field 156 The Version field of long headers is 0x709a50c4. 158 *RFC Editor's Note:* Please remove the sentence below prior to 159 publication of a final version of this document. 161 This version number will not change in subsequent versions of this 162 draft, unless there is a behavior change that breaks compatibility. 164 3.2. Long Header Packet Types 166 All version 2 long header packet types are different. The Type field 167 values are: 169 * Initial: 0b01 171 * 0-RTT: 0b10 173 * Handshake: 0b11 175 * Retry: 0b00 177 3.3. Cryptography changes 179 3.3.1. Initial Salt 181 The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS] 182 changes to: 184 initial_salt = 0xa707c203a59b47184a1d62ca570406ea7ae3e5d3 186 3.3.2. HKDF Labels 188 The labels used in [QUIC-TLS] to derive packet protection keys 189 (Section 5.1), header protection keys (Section 5.4), Retry Integrity 190 Tag keys (Section 5.8), and key updates (Section 6.1) change from 191 "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic 192 hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the 193 guidance for new versions in Section 9.6 of that document. 195 3.3.3. Retry Integrity Tag 197 The key and nonce used for the Retry Integrity Tag (Section 5.8 of 198 [QUIC-TLS]) change to: 200 secret = 201 0x3425c20cf88779df2ff71e8abfa78249891e763bbed2f13c048343d348c060e2 202 key = 0xba858dc7b43de5dbf87617ff4ab253db 203 nonce = 0x141b99c239b03e785d6a2e9f 205 4. Version Negotiation Considerations 207 QUIC version 2 is not intended to deprecate version 1. Endpoints 208 that support version 2 might continue support for version 1 to 209 maximize compatibility with other endpoints. In particular, HTTP 210 clients often use Alt-Svc [RFC7838] to discover QUIC support. As 211 this mechanism does not currently distinguish between QUIC versions, 212 HTTP servers that support multiple versions reduce the probability of 213 incompatibility and the cost associated with QUIC version negotiation 214 or TCP fallback. For example, an origin advertising support for "h3" 215 in Alt-Svc SHOULD support QUIC version 1 as it was the original QUIC 216 version used by HTTP/3 and therefore some clients will only support 217 that version. 219 Any QUIC endpoint that supports QUIC version 2 MUST send, process, 220 and validate the version_information transport parameter specified in 221 [QUIC-VN] to prevent version downgrade attacks. 223 Note that version 2 meets that document's definition of a compatible 224 version with version 1, and version 1 is compatible with version 2. 225 Therefore, servers can use compatible negotiation to switch a 226 connection between the two versions. Endpoints that support both 227 versions SHOULD support compatible version negotiation to avoid a 228 round trip. 230 4.1. Compatible Negotiation Requirements 232 Compatible version negotiation between versions 1 and 2 follow the 233 same requirements in either direction. This section uses the terms 234 "original version" and "negotiated version" from [QUIC-VN]. 236 If the server sends a Retry packet, it MUST use the original version. 237 The client ignores Retry packets using other versions. The client 238 MUST NOT use a different version in the subsequent Initial that 239 contains the Retry token. The server MAY encode the QUIC version in 240 its Retry token to validate that the client did not switch versions, 241 and drop the packet if it switched. 243 QUIC version 2 uses the same transport parameters to authenticate the 244 Retry as QUIC version 1. After switching to a negotiated version 245 after a Retry, the server MUST include the relevant transport 246 parameters to validate that the server sent the Retry and the 247 connection IDs used in the exchange, as described in Section 7.3 of 248 [QUIC]. 250 The server SHOULD start sending its Initial packets using the 251 negotiated version as soon as it decides to change. Before the 252 server is able to process transport parameters from the client, it 253 might need to respond to Initial packets from the client. For these 254 packets the server uses the original version. 256 Once the client has processed a packet using the negotiated version, 257 it SHOULD send subsequent Initial packets using that version. The 258 server MUST NOT discard its original version Initial receive keys 259 until it successfully processes a packet with the negotiated version. 261 Both endpoints MUST send Handshake or 1-RTT packets using the 262 negotiated version. An endpoint MUST drop packets using any other 263 version. Endpoints have no need to generate the keying material that 264 would allow them to decrypt or authenticate these packets. 266 The client MUST NOT send 0-RTT packets using the negotiated version, 267 even after processing a packet of that version from the server. 268 Servers can apply original version 0-RTT packets to a connection 269 without additional considerations. 271 5. TLS Resumption and NEW_TOKEN Tokens 273 TLS session tickets and NEW_TOKEN tokens are specific to the QUIC 274 version of the connection that provided them. Clients SHOULD NOT use 275 a session ticket or token from a QUIC version 1 connection to 276 initiate a QUIC version 2 connection, or vice versa. 278 Servers MUST validate the originating version of any session ticket 279 or token and not accept one issued from a different version. A 280 rejected ticket results in falling back to a full TLS handshake, 281 without 0-RTT. A rejected token results in the client address 282 remaining unverified, which limits the amount of data the server can 283 send. 285 After compatible version negotiation, any resulting session ticket 286 maps to the negotiated version rather than original one. 288 6. Ossification Considerations 290 QUIC version 2 provides protection against some forms of 291 ossification. Devices that assume that all long headers will encode 292 version 1, or that the version 1 Initial key derivation formula will 293 remain version-invariant, will not correctly process version 2 294 packets. 296 However, many middleboxes such as firewalls focus on the first packet 297 in a connection, which will often remain in the version 1 format due 298 to the considerations above. 300 Clients interested in combating firewall ossification can initiate a 301 connection using version 2 if they are either reasonably certain the 302 server supports it, or are willing to suffer a round-trip penalty if 303 they are incorrect. In particular, a server that issues a session 304 ticket for version 2 indicates an intent to maintain version 2 305 support while the ticket remains valid, even if support cannot be 306 guaranteed. 308 7. Applicability 310 This version of QUIC provides no change from QUIC version 1 relating 311 to the capabilities available to applications. Therefore, all 312 Application Layer Protocol Negotiation (ALPN) ([RFC7301]) codepoints 313 specified to operate over QUIC version 1 can also operate over this 314 version of QUIC. In particular, both the "h3" [I-D.ietf-quic-http] 315 and "doq" [RFC9250] ALPNs can operate over QUIC version 2. 317 Unless otherwise stated, all QUIC extensions defined to work with 318 version 1 also work with version 2. 320 8. Security Considerations 322 QUIC version 2 introduces no changes to the security or privacy 323 properties of QUIC version 1. 325 The mandatory version negotiation mechanism guards against downgrade 326 attacks, but downgrades have no security implications, as the version 327 properties are identical. 329 9. IANA Considerations 331 This document requests that IANA add the following entry to the QUIC 332 version registry: 334 Value: 0x709a50c4 335 Status: provisional 337 Specification: This Document 339 Change Controller: IETF 341 Contact: QUIC WG 343 10. References 345 10.1. Normative References 347 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 348 Multiplexed and Secure Transport", RFC 9000, 349 DOI 10.17487/RFC9000, May 2021, 350 . 352 [QUIC-LOSSRECOVERY] 353 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 354 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 355 May 2021, . 357 [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 358 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 359 . 361 [QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version 362 Negotiation for QUIC", Work in Progress, Internet-Draft, 363 draft-ietf-quic-version-negotiation-07, 5 April 2022, 364 . 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, 369 DOI 10.17487/RFC2119, March 1997, 370 . 372 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 373 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 374 May 2017, . 376 10.2. Informative References 378 [I-D.ietf-quic-http] 379 Bishop, M., "Hypertext Transfer Protocol Version 3 380 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 381 quic-http-34, 2 February 2021, 382 . 385 [QUIC-INVARIANTS] 386 Thomson, M., "Version-Independent Properties of QUIC", 387 RFC 8999, DOI 10.17487/RFC8999, May 2021, 388 . 390 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 391 "Transport Layer Security (TLS) Application-Layer Protocol 392 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 393 July 2014, . 395 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 396 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 397 April 2016, . 399 [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over 400 Dedicated QUIC Connections", RFC 9250, 401 DOI 10.17487/RFC9250, May 2022, 402 . 404 Appendix A. Sample Packet Protection 406 This section shows examples of packet protection so that 407 implementations can be verified incrementally. Samples of Initial 408 packets from both client and server plus a Retry packet are defined. 409 These packets use an 8-byte client-chosen Destination Connection ID 410 of 0x8394c8f03e515708. Some intermediate values are included. All 411 values are shown in hexadecimal. 413 A.1. Keys 415 The labels generated during the execution of the HKDF-Expand-Label 416 function (that is, HkdfLabel.label) and part of the value given to 417 the HKDF-Expand function in order to produce its output are: 419 client in: 00200f746c73313320636c69656e7420696e00 421 server in: 00200f746c7331332073657276657220696e00 423 quicv2 key: 001010746c73313320717569637632206b657900 425 quicv2 iv: 000c0f746c7331332071756963763220697600 426 quicv2 hp: 00100f746c7331332071756963763220687000 428 The initial secret is common: 430 initial_secret = HKDF-Extract(initial_salt, cid) 431 = ddfcb7b82a430b7845210ad64b406977 432 ed51b269a14bc69aa9ea9b366fa3b06b 434 The secrets for protecting client packets are: 436 client_initial_secret 437 = HKDF-Expand-Label(initial_secret, "client in", "", 32) 438 = 9fe72e1452e91f551b770005054034e4 439 7575d4a0fb4c27b7c6cb303a338423ae 441 key = HKDF-Expand-Label(client_initial_secret, "quicv2 key", "", 16) 442 = 95df2be2e8d549c82e996fc9339f4563 444 iv = HKDF-Expand-Label(client_initial_secret, "quicv2 iv", "", 12) 445 = ea5e3c95f933db14b7020ad8 447 hp = HKDF-Expand-Label(client_initial_secret, "quicv2 hp", "", 16) 448 = 091efb735702447d07908f6501845794 450 The secrets for protecting server packets are: 452 server_initial_secret 453 = HKDF-Expand-Label(initial_secret, "server in", "", 32) 454 = 3c9bf6a9c1c8c71819876967bd8b979e 455 fd98ec665edf27f22c06e9845ba0ae2f 457 key = HKDF-Expand-Label(server_initial_secret, "quicv2 key", "", 16) 458 = 15d5b4d9a2b8916aa39b1bfe574d2aad 460 iv = HKDF-Expand-Label(server_initial_secret, "quicv2 iv", "", 12) 461 = a85e7ac31cd275cbb095c626 463 hp = HKDF-Expand-Label(server_initial_secret, "quicv2 hp", "", 16) 464 = b13861cfadbb9d11ff942dd80c8fc33b 466 A.2. Client Initial 468 The client sends an Initial packet. The unprotected payload of this 469 packet contains the following CRYPTO frame, plus enough PADDING 470 frames to make a 1162-byte payload: 472 060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868 473 04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578 474 616d706c652e636f6dff01000100000a 00080006001d00170018001000070005 475 04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba 476 baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400 477 0d0010000e0403050306030203080408 050806002d00020101001c0002400100 478 3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000 479 75300901100f088394c8f03e51570806 048000ffff 481 The unprotected header indicates a length of 1182 bytes: the 4-byte 482 packet number, 1162 bytes of frames, and the 16-byte authentication 483 tag. The header includes the connection ID and a packet number of 2: 485 d3709a50c4088394c8f03e5157080000449e00000002 487 Protecting the payload produces output that is sampled for header 488 protection. Because the header uses a 4-byte packet number encoding, 489 the first 16 bytes of the protected payload is sampled and then 490 applied to the header as follows: 492 sample = 23b8e610589c83c92d0e97eb7a6e5003 494 mask = AES-ECB(hp, sample)[0..4] 495 = 8e4391d84a 497 header[0] ^= mask[0] & 0x0f 498 = dd 499 header[18..21] ^= mask[1..4] 500 = 4391d848 501 header = dd709a50c4088394c8f03e5157080000449e4391d848 503 The resulting protected packet is: 505 dd709a50c4088394c8f03e5157080000 449e4391d84823b8e610589c83c92d0e 506 97eb7a6e5003f57764c5c7f0095ba54b 90818f1bfeecc1c97c54fc731edbd2a2 507 44e3b1e639a9bc75ed545b98649343b2 53615ec6b3e4df0fd2e7fe9d691a09e6 508 a144b436d8a2c088a404262340dfd995 ec3865694e3026ecd8c6d2561a5a3667 509 2a1005018168c0f081c10e2bf14d550c 977e28bb9a759c57d0f7ffb1cdfb40bd 510 774dec589657542047dffefa56fc8089 a4d1ef379c81ba3df71a05ddc7928340 511 775910feb3ce4cbcfd8d253edd05f161 458f9dc44bea017c3117cca7065a315d 512 eda9464e672ec80c3f79ac993437b441 ef74227ecc4dc9d597f66ab0ab8d214b 513 55840c70349d7616cbe38e5e1d052d07 f1fedb3dd3c4d8ce295724945e67ed2e 514 efcd9fb52472387f318e3d9d233be7df c79d6bf6080dcbbb41feb180d7858849 515 7c3e439d38c334748d2b56fd19ab364d 057a9bd5a699ae145d7fdbc8f5777518 516 1b0a97c3bdedc91a555d6c9b8634e106 d8c9ca45a9d5450a7679edc545da9102 517 5bc93a7cf9a023a066ffadb9717ffaf3 414c3b646b5738b3cc4116502d18d79d 518 8227436306d9b2b3afc6c785ce3c817f eb703a42b9c83b59f0dcef1245d0b3e4 519 0299821ec19549ce489714fe2611e72c d882f4f70dce7d3671296fc045af5c9f 520 630d7b49a3eb821bbca60f1984dce664 91713bfe06001a56f51bb3abe92f7960 521 547c4d0a70f4a962b3f05dc25a34bbe8 30a7ea4736d3b0161723500d82beda9b 522 e3327af2aa413821ff678b2a876ec4b0 0bb605ffcc3917ffdc279f187daa2fce 523 8cde121980bba8ec8f44ca562b0f1319 14c901cfbd847408b778e6738c7bb5b1 524 b3f97d01b0a24dcca40e3bed29411b1b a8f60843c4a241021b23132b9500509b 525 9a3516d4a9dd41d3bacbcd426b451393 521828afedcf20fa46ac24f44a8e2973 526 30b16705d5d5f798eff9e9134a065979 87a1db4617caa2d93837730829d4d89e 527 16413be4d8a8a38a7e6226623b64a820 178ec3a66954e10710e043ae73dd3fb2 528 715a0525a46343fb7590e5eac7ee55fc 810e0d8b4b8f7be82cd5a214575a1b99 529 629d47a9b281b61348c8627cab38e2a6 4db6626e97bb8f77bdcb0fee476aedd7 530 ba8f5441acaab00f4432edab3791047d 9091b2a753f035648431f6d12f7d6a68 531 1e64c861f4ac911a0f7d6ec0491a78c9 f192f96b3a5e7560a3f056bc1ca85983 532 67ad6acb6f2e034c7f37beeb9ed470c4 304af0107f0eb919be36a86f68f37fa6 533 1dae7aff14decd67ec3157a11488a14f ed0142828348f5f608b0fe03e1f3c0af 534 3acca0ce36852ed42e220ae9abf8f890 6f00f1b86bff8504c8f16c784fd52d25 535 e013ff4fda903e9e1eb453c1464b1196 6db9b28e8f26a3fc419e6a60a48d4c72 536 14ee9c6c6a12b68a32cac8f61580c64f 29cb6922408783c6d12e725b014fe485 537 cd17e484c5952bf99bc94941d4b1919d 04317b8aa1bd3754ecbaa10ec227de85 538 40695bf2fb8ee56f6dc526ef366625b9 1aa4970b6ffa5c8284b9b5ab852b905f 539 9d83f5669c0535bc377bcc05ad5e48e2 81ec0e1917ca3c6a471f8da0894bc82a 540 c2a8965405d6eef3b5e293a88fda203f 09bdc72757b107ab14880eaa3ef7045b 541 580f4821ce6dd325b5a90655d8c5b55f 76fb846279a9b518c5e9b9a21165c509 542 3ed49baaacadf1f21873266c767f6769 544 A.3. Server Initial 546 The server sends the following payload in response, including an ACK 547 frame, a CRYPTO frame, and no PADDING frames: 549 02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739 550 88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94 551 0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00 552 020304 553 The header from the server includes a new connection ID and a 2-byte 554 packet number encoding for a packet number of 1: 556 d1709a50c40008f067a5502a4262b50040750001 558 As a result, after protection, the header protection sample is taken 559 starting from the third protected byte: 561 sample = ebb7972fdce59d50e7e49ff2a7e8de76 562 mask = 41103f438e 563 header = d0709a50c40008f067a5502a4262b5004075103e 565 The final protected packet is then: 567 d0709a50c40008f067a5502a4262b500 4075103e63b4ebb7972fdce59d50e7e4 568 9ff2a7e8de76b0cd8c10100a1f13d549 dd6fe801588fb14d279bef8d7c53ef62 569 66a9a7a1a5f2fa026c236a5bf8df5aa0 f9d74773aeccfffe910b0f76814b5e33 570 f7b7f8ec278d23fd8c7a9e66856b8bbe 72558135bca27c54d63fcc902253461c 571 fc089d4e6b9b19 573 A.4. Retry 575 This shows a Retry packet that might be sent in response to the 576 Initial packet in Appendix A.2. The integrity check includes the 577 client-chosen connection ID value of 0x8394c8f03e515708, but that 578 value is not included in the final Retry packet: 580 cf709a50c40008f067a5502a4262b574 6f6b656e1dc71130cd1ed39d6efcee5c 581 85806501 583 A.5. ChaCha20-Poly1305 Short Header Packet 585 This example shows some of the steps required to protect a packet 586 with a short header. This example uses AEAD_CHACHA20_POLY1305. 588 In this example, TLS produces an application write secret from which 589 a server uses HKDF-Expand-Label to produce four values: a key, an IV, 590 a header protection key, and the secret that will be used after keys 591 are updated (this last value is not used further in this example). 593 secret 594 = 9ac312a7f877468ebe69422748ad00a1 595 5443f18203a07d6060f688f30f21632b 597 key = HKDF-Expand-Label(secret, "quicv2 key", "", 32) 598 = 3bfcddd72bcf02541d7fa0dd1f5f9eee 599 a817e09a6963a0e6c7df0f9a1bab90f2 601 iv = HKDF-Expand-Label(secret, "quicv2 iv", "", 12) 602 = a6b5bc6ab7dafce30ffff5dd 604 hp = HKDF-Expand-Label(secret, "quicv2 hp", "", 32) 605 = d659760d2ba434a226fd37b35c69e2da 606 8211d10c4f12538787d65645d5d1b8e2 608 ku = HKDF-Expand-Label(secret, "quicv2 ku", "", 32) 609 = c69374c49e3d2a9466fa689e49d476db 610 5d0dfbc87d32ceeaa6343fd0ae4c7d88 612 The following shows the steps involved in protecting a minimal packet 613 with an empty Destination Connection ID. This packet contains a 614 single PING frame (that is, a payload of just 0x01) and has a packet 615 number of 654360564. In this example, using a packet number of 616 length 3 (that is, 49140 is encoded) avoids having to pad the payload 617 of the packet; PADDING frames would be needed if the packet number is 618 encoded on fewer bytes. 620 pn = 654360564 (decimal) 621 nonce = a6b5bc6ab7dafce328ff4a29 622 unprotected header = 4200bff4 623 payload plaintext = 01 624 payload ciphertext = 0ae7b6b932bc27d786f4bc2bb20f2162ba 626 The resulting ciphertext is the minimum size possible. One byte is 627 skipped to produce the sample for header protection. 629 sample = e7b6b932bc27d786f4bc2bb20f2162ba 630 mask = 97580e32bf 631 header = 5558b1c6 633 The protected packet is the smallest possible packet size of 21 634 bytes. 636 packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba 638 Appendix B. Acknowledgments 640 The author would like to thank Lucas Pardue, David Schinazi, and 641 Martin Thomson for their helpful suggestions. 643 Appendix C. Changelog 645 *RFC Editor's Note:* Please remove this section prior to 646 publication of a final version of this document. 648 C.1. since draft-ietf-quic-v2-03 650 * a v2 session ticket is an indication of v2 support 652 * a v1-only extension is theoretically possible 654 * editorial fixes 656 C.2. since draft-ietf-quic-v2-02 658 * Editorial comments from Lucas Pardue 660 C.3. since draft-ietf-quic-v2-01 662 * Ban use of NEW_TOKEN tokens across versions 664 * version-info transport parameter required for all v2 endpoints 666 * Explicitly list known ALPN compatibility 668 C.4. since draft-ietf-quic-v2-00 670 * Expanded requirements for compatible version negotiation 672 * Added test vectors 674 * Greased the packet type codepoints 676 * Random version number 678 * Clarified requirement to use QUIC-VN 680 * Banned use of resumption tokens across versions 682 C.5. since draft-duke-quic-v2-02 684 * Converted to adopted draft 685 * Deleted references to QUIC improvements 687 * Clarified status of QUIC extensions 689 C.6. since draft-duke-quic-v2-01 691 * Made the final version number TBD. 693 * Added ALPN considerations 695 C.7. since draft-duke-quic-v2-00 697 * Added provisional versions for interop 699 * Change the v1 Retry Tag secret 701 * Change labels to create full key separation 703 Author's Address 705 Martin Duke 706 Google LLC 707 Email: martin.h.duke@gmail.com