Skip to main content

QUIC Version 2
draft-ietf-quic-v2-10

Document Type Active Internet-Draft (quic WG)
Author Martin Duke
Last updated 2023-01-13 (Latest revision 2022-12-15)
Replaces draft-duke-quic-v2
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Associated WG milestone
QUIC Version 2 to IESG
Document shepherd Matt Joras
Shepherd write-up Show Last changed 2022-07-11
IESG IESG state RFC Ed Queue
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Zaheduzzaman Sarker
Send notices to matt.joras@gmail.com
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
IANA expert review state Expert Reviews OK
IANA expert review comments IANA Considerations section has been updated to request permanent registration, per the expert.
RFC Editor RFC Editor state RFC-EDITOR
Details
draft-ietf-quic-v2-10
QUIC                                                             M. Duke
Internet-Draft                                                Google LLC
Intended status: Standards Track                        15 December 2022
Expires: 18 June 2023

                             QUIC Version 2
                         draft-ietf-quic-v2-10

Abstract

   This document specifies QUIC version 2, which is identical to QUIC
   version 1 except for some trivial details.  Its purpose is to combat
   various ossification vectors 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 standards-track QUIC version.  The
   protocol specified here uses a version number other than 2 in the
   wire image, in order to minimize ossification risk.

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

   This Internet-Draft is submitted in full conformance with the
   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/.

Duke                      Expires 18 June 2023                  [Page 1]
Internet-Draft                   QUICv2                    December 2022

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 18 June 2023.

Copyright Notice

   Copyright (c) 2022 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Differences with QUIC Version 1 . . . . . . . . . . . . . . .   4
     3.1.  Version Field . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Long Header Packet Types  . . . . . . . . . . . . . . . .   4
     3.3.  Cryptography changes  . . . . . . . . . . . . . . . . . .   5
       3.3.1.  Initial Salt  . . . . . . . . . . . . . . . . . . . .   5
       3.3.2.  HKDF Labels . . . . . . . . . . . . . . . . . . . . .   5
       3.3.3.  Retry Integrity Tag . . . . . . . . . . . . . . . . .   5
   4.  Version Negotiation Considerations  . . . . . . . . . . . . .   6
     4.1.  Compatible Negotiation Requirements . . . . . . . . . . .   6
   5.  TLS Resumption and NEW_TOKEN Tokens . . . . . . . . . . . . .   7
   6.  Ossification Considerations . . . . . . . . . . . . . . . . .   8
   7.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Appendix A.  Sample Packet Protection . . . . . . . . . . . . . .  10
     A.1.  Keys  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     A.2.  Client Initial  . . . . . . . . . . . . . . . . . . . . .  11
     A.3.  Server Initial  . . . . . . . . . . . . . . . . . . . . .  13
     A.4.  Retry . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     A.5.  ChaCha20-Poly1305 Short Header Packet . . . . . . . . . .  14

Duke                      Expires 18 June 2023                  [Page 2]
Internet-Draft                   QUICv2                    December 2022

   Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . . . .  16
   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

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

   In QUIC version 1, Initial packets are encrypted with the version-
   specific salt as described in Section 5.2 of [QUIC-TLS].  Protecting
   Initial packets in this way allows observers to inspect their
   contents, which includes the TLS Client Hello 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] provides two mechanisms for endpoints to negotiate
   the QUIC version to use.  The "incompatible" version negotiation
   method can support switching from any QUIC version to any other
   version with full generality, at the cost of an additional round-trip
   at the start of the connection.  "Compatible" version negotiation
   eliminates the round-trip penalty but levies some restrictions on how
   much the two versions can differ semantically.

Duke                      Expires 18 June 2023                  [Page 3]
Internet-Draft                   QUICv2                    December 2022

   QUIC version 2 is meant to mitigate ossification concerns and
   exercise the version negotiation mechanisms.  The changes provide an
   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
   wire is randomly chosen instead of "2", and the two bits that
   identify each long header packet type are different from version 1;
   both of these properties are meant to combat ossification and are not
   strictly required of a new QUIC version.

   Any endpoint that supports two versions needs to implement version
   negotiation to protect against downgrade attacks.

2.  Conventions

   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.

3.  Differences with QUIC Version 1

   Except for a few differences, QUIC version 2 endpoints MUST implement
   the QUIC version 1 specification as described in [QUIC], [QUIC-TLS],
   and [QUIC-RECOVERY].  The remainder of this section lists the
   differences.

3.1.  Version Field

   The Version field of long headers is 0x6b3343cf.  This was generated
   by taking the first four bytes of the sha256sum of "QUICv2 version
   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

   All version 2 long header packet types are different.  The Type field
   values are:

   *  Initial: 0b01

   *  0-RTT: 0b10

Duke                      Expires 18 June 2023                  [Page 4]
Internet-Draft                   QUICv2                    December 2022

   *  Handshake: 0b11

   *  Retry: 0b00

3.3.  Cryptography changes

   The values below were chosen randomly.

3.3.1.  Initial Salt

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

   initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9

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

3.3.2.  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
   (Section 5.1), header protection keys (Section 5.4), Retry Integrity
   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
   hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the
   guidance for new versions in Section 9.6 of that document.

3.3.3.  Retry Integrity Tag

   The key and nonce used for the Retry Integrity Tag (Section 5.8 of
   [QUIC-TLS]) change to:

   secret =
     0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f
   key = 0x8fb4b01b56ac48e260fbcbcead7ccc92
   nonce = 0xd86969bc2d7c6d9990efb04a

   The secret is the sha256sum of "QUICv2 retry secret".  The key and
   nonce are derived from this secret with the labels "quicv2 key" and
   "quicv2 iv", respectively.

Duke                      Expires 18 June 2023                  [Page 5]
Internet-Draft                   QUICv2                    December 2022

4.  Version Negotiation Considerations

   QUIC version 2 is not intended to deprecate version 1.  Endpoints
   that support version 2 might continue support for version 1 to
   maximize compatibility with other endpoints.  In particular, HTTP
   clients often use Alt-Svc [RFC7838] to discover QUIC support.  As
   this mechanism does not currently distinguish between QUIC versions,
   HTTP servers SHOULD support multiple versions to reduce the
   probability of incompatibility and the cost associated with QUIC
   version negotiation 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 version used by HTTP/3, and therefore
   some clients will only support that version.

   Any QUIC endpoint that supports QUIC version 2 MUST send, process,
   and validate the version_information transport parameter specified in
   [QUIC-VN] to prevent version downgrade attacks.

   Note that version 2 meets the [QUIC-VN] definition of a compatible
   version with version 1, and version 1 is compatible with version 2.
   Therefore, servers can use compatible negotiation to switch a
   connection between the two versions.  Endpoints that support both
   versions SHOULD support compatible version negotiation to avoid a
   round trip.

4.1.  Compatible Negotiation Requirements

   Compatible version negotiation between versions 1 and 2 follow the
   same requirements in either direction.  This section uses the terms
   "original version" and "negotiated version" from [QUIC-VN].

   If the server sends a Retry packet, it MUST use the original version.
   The client ignores Retry packets using other versions.  The client
   MUST NOT use a different version in the subsequent Initial packet
   that contains the Retry token.  The server MAY encode the QUIC
   version in its Retry token to validate that 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 as QUIC version 1.  After switching to a negotiated version
   after a Retry, the server MUST include the relevant transport
   parameters to validate that the server sent the Retry and the
   connection IDs used in the exchange, as described in Section 7.3 of
   [QUIC].

Duke                      Expires 18 June 2023                  [Page 6]
Internet-Draft                   QUICv2                    December 2022

   The server cannot send CRYPTO frames until it has processed the
   client's transport parameters.  The server MUST send all CRYPTO
   frames using the negotiated version.

   The client learns the negotiated version by observing the first long
   header Version field that differs from the original version.  If the
   client receives a CRYPTO frame from the server in the original
   version, that indicates that the negotiated version is equal to the
   original version.

   Before the server is able to process transport parameters from the
   client, it might need to respond to Initial packets from the client.
   For these packets, the server uses the original version.

   Once the client has learned the negotiated version, it SHOULD send
   subsequent Initial packets using that version.  The server MUST NOT
   discard its original version Initial receive keys until it
   successfully processes a Handshake packet with the negotiated
   version.

   Both endpoints MUST send Handshake and 1-RTT packets using the
   negotiated version.  An endpoint MUST drop packets using any other
   version.  Endpoints have no need to generate the keying material that
   would allow them to decrypt or authenticate such packets.

   The client MUST NOT send 0-RTT packets using the negotiated version,
   even after processing a packet of that version from the server.
   Servers can accept 0-RTT and then process 0-RTT packets from the
   original version.

5.  TLS Resumption and NEW_TOKEN Tokens

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

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

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

Duke                      Expires 18 June 2023                  [Page 7]
Internet-Draft                   QUICv2                    December 2022

6.  Ossification Considerations

   QUIC version 2 provides protection against some forms of
   ossification.  Devices that assume that all long headers will encode
   version 1, or that the version 1 Initial key derivation formula will
   remain version-invariant, will not correctly process version 2
   packets.

   However, many middleboxes, such as firewalls, focus on the first
   packet in a connection, 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 either reasonably certain the
   server supports it, or are willing to suffer a round-trip penalty if
   they are incorrect.  In particular, a server that issues a session
   ticket for version 2 indicates an intent to maintain version 2
   support while the ticket remains valid, even if support cannot be
   guaranteed.

7.  Applicability

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

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

8.  Security Considerations

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

   The mandatory version negotiation mechanism guards against downgrade
   attacks, but downgrades have no security implications, as the version
   properties are identical.

   Support for QUIC version 2 can help an observer to fingerprint both
   client and server devices.

Duke                      Expires 18 June 2023                  [Page 8]
Internet-Draft                   QUICv2                    December 2022

9.  IANA Considerations

   This document requests that IANA add the following entry to the QUIC
   version registry maintained at
   <https://www.iana.org/assignments/quic/quic.xhtml#quic-versions>.

   Value:  0x6b3343cf
   Status:  permanent
   Specification:  This Document
   Change Controller:  IETF
   Contact:  QUIC WG

   Value:  0x709a50c4
   Status:  provisional
   Specification:  This Document
   Change Controller:  IETF
   Contact:  QUIC WG
   Note:  QUIC v2 draft codepoint

10.  References

10.1.  Normative References

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [QUIC-RECOVERY]
              Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
              and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
              May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.

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

   [QUIC-VN]  Schinazi, D. and E. Rescorla, "Compatible Version
              Negotiation for QUIC", Work in Progress, Internet-Draft,
              draft-ietf-quic-version-negotiation-13, 6 November 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
              version-negotiation-13>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Duke                      Expires 18 June 2023                  [Page 9]
Internet-Draft                   QUICv2                    December 2022

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

10.2.  Informative References

   [HTTP/3]   Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

   [QUIC-INVARIANTS]
              Thomson, M., "Version-Independent Properties of QUIC",
              RFC 8999, DOI 10.17487/RFC8999, May 2021,
              <https://www.rfc-editor.org/rfc/rfc8999>.

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.

   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <https://www.rfc-editor.org/rfc/rfc7838>.

   [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
              Dedicated QUIC Connections", RFC 9250,
              DOI 10.17487/RFC9250, May 2022,
              <https://www.rfc-editor.org/rfc/rfc9250>.

Appendix A.  Sample Packet Protection

   This section shows examples of packet protection so that
   implementations can be verified incrementally.  Samples of Initial
   packets from both client and server plus a Retry packet are defined.
   These packets use an 8-byte client-chosen Destination Connection ID
   of 0x8394c8f03e515708.  Some intermediate values are included.  All
   values are shown in hexadecimal.

A.1.  Keys

   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-Expand function in order to produce its output are:

   client in: 00200f746c73313320636c69656e7420696e00

   server in: 00200f746c7331332073657276657220696e00

   quicv2 key: 001010746c73313320717569637632206b657900

Duke                      Expires 18 June 2023                 [Page 10]
Internet-Draft                   QUICv2                    December 2022

   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
         83766aade7ecd0891f70f9ff7f4bf47b

   key = HKDF-Expand-Label(client_initial_secret, "quicv2 key", "", 16)
       = 8b1a0bc121284290a29e0971b5cd045d

   iv  = HKDF-Expand-Label(client_initial_secret, "quicv2 iv", "", 12)
       = 91f73e2351d8fa91660e909f

   hp  = 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
         07cb8cd8200b5da55a8bd488eafc37c1

   key = HKDF-Expand-Label(server_initial_secret, "quicv2 key", "", 16)
       = 82db637861d55e1d011f19ea71d5d2a7

   iv  = HKDF-Expand-Label(server_initial_secret, "quicv2 iv", "", 12)
       = dd13c276499c0249d3310652

   hp  = HKDF-Expand-Label(server_initial_secret, "quicv2 hp", "", 16)
       = edf6d05c83121201b436e16877593c3a

A.2.  Client Initial

   The client sends an Initial packet.  The unprotected payload of this
   packet contains the following CRYPTO frame, plus enough PADDING
   frames to make a 1162-byte payload:

Duke                      Expires 18 June 2023                 [Page 11]
Internet-Draft                   QUICv2                    December 2022

   060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
   04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
   616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
   04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
   baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
   0d0010000e0403050306030203080408 050806002d00020101001c0002400100
   3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
   75300901100f088394c8f03e51570806 048000ffff

   The unprotected header indicates a length of 1182 bytes: the 4-byte
   packet number, 1162 bytes of frames, and the 16-byte authentication
   tag.  The header includes the connection ID and a packet number of 2:

   d36b3343cf088394c8f03e5157080000449e00000002

   Protecting the payload produces output that is sampled for header
   protection.  Because the header uses a 4-byte packet number encoding,
   the first 16 bytes of the protected payload is sampled and then
   applied to the header as follows:

   sample = ffe67b6abcdb4298b485dd04de806071

   mask = AES-ECB(hp, sample)[0..4]
        = 94a0c95e80

   header[0] ^= mask[0] & 0x0f
        = d7
   header[18..21] ^= mask[1..4]
        = a0c95e82
   header = d76b3343cf088394c8f03e5157080000449ea0c95e82

   The resulting protected packet is:

Duke                      Expires 18 June 2023                 [Page 12]
Internet-Draft                   QUICv2                    December 2022

   d76b3343cf088394c8f03e5157080000 449ea0c95e82ffe67b6abcdb4298b485
   dd04de806071bf03dceebfa162e75d6c 96058bdbfb127cdfcbf903388e99ad04
   9f9a3dd4425ae4d0992cfff18ecf0fdb 5a842d09747052f17ac2053d21f57c5d
   250f2c4f0e0202b70785b7946e992e58 a59ac52dea6774d4f03b55545243cf1a
   12834e3f249a78d395e0d18f4d766004 f1a2674802a747eaa901c3f10cda5500
   cb9122faa9f1df66c392079a1b40f0de 1c6054196a11cbea40afb6ef5253cd68
   18f6625efce3b6def6ba7e4b37a40f77 32e093daa7d52190935b8da58976ff33
   12ae50b187c1433c0f028edcc4c2838b 6a9bfc226ca4b4530e7a4ccee1bfa2a3
   d396ae5a3fb512384b2fdd851f784a65 e03f2c4fbe11a53c7777c023462239dd
   6f7521a3f6c7d5dd3ec9b3f233773d4b 46d23cc375eb198c63301c21801f6520
   bcfb7966fc49b393f0061d974a2706df 8c4a9449f11d7f3d2dcbb90c6b877045
   636e7c0c0fe4eb0f697545460c806910 d2c355f1d253bc9d2452aaa549e27a1f
   ac7cf4ed77f322e8fa894b6a83810a34 b361901751a6f5eb65a0326e07de7c12
   16ccce2d0193f958bb3850a833f7ae43 2b65bc5a53975c155aa4bcb4f7b2c4e5
   4df16efaf6ddea94e2c50b4cd1dfe060 17e0e9d02900cffe1935e0491d77ffb4
   fdf85290fdd893d577b1131a610ef6a5 c32b2ee0293617a37cbb08b847741c3b
   8017c25ca9052ca1079d8b78aebd4787 6d330a30f6a8c6d61dd1ab5589329de7
   14d19d61370f8149748c72f132f0fc99 f34d766c6938597040d8f9e2bb522ff9
   9c63a344d6a2ae8aa8e51b7b90a4a806 105fcbca31506c446151adfeceb51b91
   abfe43960977c87471cf9ad4074d30e1 0d6a7f03c63bd5d4317f68ff325ba3bd
   80bf4dc8b52a0ba031758022eb025cdd 770b44d6d6cf0670f4e990b22347a7db
   848265e3e5eb72dfe8299ad7481a4083 22cac55786e52f633b2fb6b614eaed18
   d703dd84045a274ae8bfa73379661388 d6991fe39b0d93debb41700b41f90a15
   c4d526250235ddcd6776fc77bc97e7a4 17ebcb31600d01e57f32162a8560cacc
   7e27a096d37a1a86952ec71bd89a3e9a 30a2a26162984d7740f81193e8238e61
   f6b5b984d4d3dfa033c1bb7e4f0037fe bf406d91c0dccf32acf423cfa1e70710
   10d3f270121b493ce85054ef58bada42 310138fe081adb04e2bd901f2f13458b
   3d6758158197107c14ebb193230cd115 7380aa79cae1374a7c1e5bbcb80ee23e
   06ebfde206bfb0fcbc0edc4ebec30966 1bdd908d532eb0c6adc38b7ca7331dce
   8dfce39ab71e7c32d318d136b6100671 a1ae6a6600e3899f31f0eed19e3417d1
   34b90c9058f8632c798d4490da498730 7cba922d61c39805d072b589bd52fdf1
   e86215c2d54e6670e07383a27bbffb5a ddf47d66aa85a0c6f9f32e59d85a44dd
   5d3b22dc2be80919b490437ae4f36a0a e55edf1d0b5cb4e9a3ecabee93dfc6e3
   8d209d0fa6536d27a5d6fbb17641cde2 7525d61093f1b28072d111b2b4ae5f89
   d5974ee12e5cf7d5da4d6a31123041f3 3e61407e76cffcdcfd7e19ba58cf4b53
   6f4c4938ae79324dc402894b44faf8af bab35282ab659d13c93f70412e85cb19
   9a37ddec600545473cfb5a05e08d0b20 9973b2172b4d21fb69745a262ccde96b
   a18b2faa745b6fe189cf772a9f84cbfc

A.3.  Server Initial

   The server sends the following payload in response, including an ACK
   frame, a CRYPTO frame, and no PADDING frames:

   02000000000600405a020000560303ee fce7f7b37ba1d1632e96677825ddf739
   88cfc79825df566dc5430b9a045a1200 130100002e00330024001d00209d3c94
   0d89690b84d08a60993c144eca684d10 81287c834d5311bcf32bb9da1a002b00
   020304

Duke                      Expires 18 June 2023                 [Page 13]
Internet-Draft                   QUICv2                    December 2022

   The header from the server includes a new connection ID and a 2-byte
   packet number encoding for a packet number of 1:

   d16b3343cf0008f067a5502a4262b50040750001

   As a result, after protection, the header protection sample is taken
   starting from the third protected byte:

   sample = 6f05d8a4398c47089698baeea26b91eb
   mask   = 4dd92e91ea
   header = dc6b3343cf0008f067a5502a4262b5004075d92f

   The final protected packet is then:

   dc6b3343cf0008f067a5502a4262b500 4075d92faaf16f05d8a4398c47089698
   baeea26b91eb761d9b89237bbf872630 17915358230035f7fd3945d88965cf17
   f9af6e16886c61bfc703106fbaf3cb4c fa52382dd16a393e42757507698075b2
   c984c707f0a0812d8cd5a6881eaf21ce da98f4bd23f6fe1a3e2c43edd9ce7ca8
   4bed8521e2e140

A.4.  Retry

   This shows a Retry packet that might be sent in response to the
   Initial packet in Appendix A.2.  The integrity check includes the
   client-chosen connection ID value of 0x8394c8f03e515708, but that
   value is not included in the final Retry packet:

   cf6b3343cf0008f067a5502a4262b574 6f6b656ec8646ce8bfe33952d9555436
   65dcc7b6

A.5.  ChaCha20-Poly1305 Short Header Packet

   This example shows some of the steps required to protect a packet
   with a short header.  This example uses AEAD_CHACHA20_POLY1305.

   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 header protection key, and the secret that will be used after keys
   are updated (this last value is not used further in this example).

Duke                      Expires 18 June 2023                 [Page 14]
Internet-Draft                   QUICv2                    December 2022

   secret
       = 9ac312a7f877468ebe69422748ad00a1
         5443f18203a07d6060f688f30f21632b

   key = HKDF-Expand-Label(secret, "quicv2 key", "", 32)
       = 3bfcddd72bcf02541d7fa0dd1f5f9eee
         a817e09a6963a0e6c7df0f9a1bab90f2

   iv  = HKDF-Expand-Label(secret, "quicv2 iv", "", 12)
       = a6b5bc6ab7dafce30ffff5dd

   hp  = HKDF-Expand-Label(secret, "quicv2 hp", "", 32)
       = d659760d2ba434a226fd37b35c69e2da
         8211d10c4f12538787d65645d5d1b8e2

   ku  = HKDF-Expand-Label(secret, "quicv2 ku", "", 32)
       = c69374c49e3d2a9466fa689e49d476db
         5d0dfbc87d32ceeaa6343fd0ae4c7d88

   The following shows the steps involved in protecting a minimal packet
   with an empty Destination Connection ID.  This packet contains a
   single PING frame (that is, a payload of just 0x01) and has a packet
   number of 654360564.  In this example, using a packet number of
   length 3 (that is, 49140 is encoded) avoids having to pad the payload
   of the packet; PADDING frames would be needed if the packet number is
   encoded on fewer bytes.

   pn                 = 654360564 (decimal)
   nonce              = a6b5bc6ab7dafce328ff4a29
   unprotected header = 4200bff4
   payload plaintext  = 01
   payload ciphertext = 0ae7b6b932bc27d786f4bc2bb20f2162ba

   The resulting ciphertext is the minimum size possible.  One byte is
   skipped to produce the sample for header protection.

   sample = e7b6b932bc27d786f4bc2bb20f2162ba
   mask   = 97580e32bf
   header = 5558b1c6

   The protected packet is the smallest possible packet size of 21
   bytes.

   packet = 5558b1c60ae7b6b932bc27d786f4bc2bb20f2162ba

Duke                      Expires 18 June 2023                 [Page 15]
Internet-Draft                   QUICv2                    December 2022

Appendix B.  Acknowledgments

   The author would like to thank Christian Huitema, Lucas Pardue, Kyle
   Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro
   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

Duke                      Expires 18 June 2023                 [Page 16]
Internet-Draft                   QUICv2                    December 2022

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

Duke                      Expires 18 June 2023                 [Page 17]
Internet-Draft                   QUICv2                    December 2022

   *  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

   Martin Duke
   Google LLC
   Email: martin.h.duke@gmail.com

Duke                      Expires 18 June 2023                 [Page 18]