RFC 9369 - QUIC Version 2

• Statut: Proposed Standard
• Publié: May 2023
• Stream: IETF
• Errata: Pas d'errata

---

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.

Ce document spécifie la version 2 de QUIC, qui est identique à la version 1 de QUIC, à l'exception de quelques détails triviaux. Son objectif est de combattre divers vecteurs d'ossification et d'exercer le cadre de négociation de version. Il sert également de modèle pour les changements minimaux dans toute future version de 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 a version number other than 2 in the wire image, in order to minimize ossification risks.

Notez que "version 2" est un nom informel pour cette proposition qui indique qu'il s'agit de la deuxième version de QUIC à être publiée en tant que document Standards Track. Le protocole spécifié ici utilise un numéro de version autre que 2 dans l'image filaire, afin de minimiser les risques d'ossification.

Status of This Memo

This is an Internet Standards Track document.

Ceci est un document Internet Standards Track.

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.

Ce document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). De plus amples informations sur les normes Internet sont disponibles dans la section 2 de la RFC 7841.

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.

Des informations sur l'état actuel de ce document, les éventuels errata et la manière de fournir des commentaires à son sujet peuvent être obtenues à l'adresse https://www.rfc-editor.org/info/rfc9369.

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright (c) 2023 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

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.

Ce document est soumis au BCP 78 et aux dispositions juridiques de l'IETF Trust relatives aux documents IETF (https://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez examiner ces documents attentivement, car ils décrivent vos droits et restrictions concernant ce document. Les composants de code extraits de ce document doivent inclure le texte de la licence BSD révisée tel que décrit dans la section 4.e des dispositions juridiques du Trust et sont fournis sans garantie comme décrit dans la licence BSD révisée.

Table of Contents

• 1. Introduction
• 2. Conventions
• 3. Differences with QUIC Version 1
• 4. Version Negotiation Considerations
• 5. TLS Resumption and NEW_TOKEN Tokens
• 6. Ossification Considerations
• 7. Applicability
• 8. Security Considerations
• 9. IANA Considerations
• 10. References
• Appendix A. Sample Packet Protection
• Acknowledgments
• Author's Address

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 that are usually 0x00000001.

La version 1 de QUIC [QUIC] comporte de nombreux points d'extension, notamment le numéro de version qui occupe du deuxième au cinquième octet de chaque en-tête long (voir [QUIC-INVARIANTS]). Si les versions expérimentales sont rares et que la version 1 de QUIC constitue la grande majorité du trafic QUIC, il existe un risque que les intermédiaires se figent sur les octets de version qui sont généralement 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.

Dans la version 1 de QUIC, les paquets initiaux sont chiffrés avec le sel spécifique à la version, comme décrit dans la section 5.2 de [QUIC-TLS]. La protection des paquets initiaux de cette manière permet aux observateurs d'inspecter leur contenu, qui comprend les messages TLS Client Hello ou Server Hello. Encore une fois, il existe un risque que les intermédiaires se figent sur la dérivation de clé et les formats de paquets de la version 1.

Finally, [QUIC-VN] describes two mechanisms endpoints can use to negotiate which QUIC version to select. 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.

Enfin, [QUIC-VN] décrit deux mécanismes que les terminaux peuvent utiliser pour négocier la version QUIC à sélectionner. La méthode de négociation de version "incompatible" peut prendre en charge le passage de n'importe quelle version QUIC à n'importe quelle autre version avec une généralité totale, au prix d'un aller-retour supplémentaire au début de la connexion. La négociation de version "compatible" élimine la pénalité d'aller-retour mais impose certaines restrictions sur la mesure dans laquelle les deux versions peuvent différer sémantiquement.

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.

La version 2 de QUIC est destinée à atténuer les problèmes d'ossification et à exercer les mécanismes de négociation de version. Les changements fournissent un exemple de l'ensemble minimal de changements nécessaires pour spécifier une nouvelle version de QUIC. Cependant, notez que le choix du numéro de version sur le fil est choisi au hasard au lieu de "2", et que les deux bits qui identifient chaque type de paquet à en-tête long sont différents de la version 1 ; ces deux propriétés sont destinées à combattre l'ossification et ne sont pas strictement requises pour une nouvelle version de QUIC.

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

Tout point de terminaison prenant en charge deux versions doit implémenter la négociation de version pour se protéger contre les attaques par déclassement.

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.

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

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.

À l'exception de quelques différences, les points de terminaison QUIC version 2 DOIVENT implémenter la spécification QUIC version 1 telle que décrite dans [QUIC], [QUIC-TLS] et [QUIC-RECOVERY]. Le reste de cette section énumère les différences.

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

Le champ Version des en-têtes longs est 0x6b3343cf. Cela a été généré en prenant les quatre premiers octets du sha256sum du "QUICv2 version number".

3.2. Long Header Packet Types

All version 2 Long Header packet types are different. The Type field values are:

Tous les types de paquets à en-tête long de la version 2 sont différents. Les valeurs du champ Type sont :

• Initial: 0b01
• 0-RTT: 0b10
• Handshake: 0b11
• Retry: 0b00

3.3. Cryptography Changes

3.3.1. Initial Salt

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

Le sel utilisé pour dériver les clés initiales dans la section 5.2 de [QUIC-TLS] change pour :

initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9

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

Il s'agit des 20 premiers octets du sha256sum de "QUICv2 salt".

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

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.

Les étiquettes utilisées dans [QUIC-TLS] pour dériver les clés de protection des paquets (section 5.1), les clés de protection des en-têtes (section 5.4), les clés de balise d'intégrité de réessai (section 5.8) et les mises à jour de clés (section 6.1) passent de "quic key" à "quicv2 key", de "quic iv" à "quicv2 iv", de "quic hp" à "quicv2 hp" et de "quic ku" à "quicv2 ku" pour répondre aux directives pour les nouvelles versions de la section 9.6 de ce 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:

La clé et le nonce utilisés pour la balise d'intégrité de réessai (section 5.8 de [QUIC-TLS]) changent pour :

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.

Le secret est le sha256sum de "QUICv2 retry secret". La clé et le nonce sont dérivés de ce secret avec les étiquettes "quicv2 key" et "quicv2 iv", respectivement.

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; therefore, some clients will only support that version.

La version 2 de QUIC n'est pas destinée à rendre obsolète la version 1. Les points de terminaison prenant en charge la version 2 peuvent continuer à prendre en charge la version 1 pour maximiser la compatibilité avec d'autres points de terminaison. En particulier, les clients HTTP utilisent souvent Alt-Svc [RFC7838] pour découvrir la prise en charge de QUIC. Comme ce mécanisme ne distingue pas actuellement les versions QUIC, les serveurs HTTP DEVRAIENT prendre en charge plusieurs versions pour réduire la probabilité d'incompatibilité et le coût associé à la négociation de version QUIC ou au repli TCP. Par exemple, une origine annonçant la prise en charge de "h3" dans Alt-Svc devrait prendre en charge la version 1 de QUIC, car c'était la version QUIC originale utilisée par HTTP/3 ; par conséquent, certains clients ne prendront en charge que cette 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.

Tout point de terminaison QUIC prenant en charge la version 2 de QUIC DOIT envoyer, traiter et valider le paramètre de transport version_information spécifié dans [QUIC-VN] pour empêcher les attaques par déclassement de version.

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

Notez que la version 2 répond à la définition dans [QUIC-VN] d'une version compatible avec la version 1, et la version 1 est compatible avec la version 2. Par conséquent, les serveurs peuvent utiliser la négociation compatible pour basculer une connexion entre les deux versions. Les points de terminaison prenant en charge les deux versions DEVRAIENT prendre en charge la négociation de version compatible pour éviter un aller-retour.

4.1. Compatible Negotiation Requirements

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

La négociation de version compatible entre les versions 1 et 2 suit les mêmes exigences dans les deux sens. Cette section utilise les termes "version originale" et "version négociée" de [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.

Si le serveur envoie un paquet Retry, il DOIT utiliser la version originale. Le client ignore les paquets Retry utilisant d'autres versions. Le client NE DOIT PAS utiliser une version différente dans le paquet Initial suivant qui contient le jeton Retry. Le serveur PEUT encoder la version QUIC dans son jeton Retry pour valider que le client n'a pas changé de version, et rejeter le paquet s'il a changé, pour imposer la conformité du client.

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

La version 2 de QUIC utilise les mêmes paramètres de transport pour authentifier le Retry que la version 1 de QUIC. Après être passé à une version négociée après un Retry, le serveur DOIT inclure les paramètres de transport pertinents pour valider que le serveur a envoyé le Retry et les identifiants de connexion utilisés dans l'échange, comme décrit dans la section 7.3 de [QUIC].

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.

Le serveur ne peut pas envoyer de trames CRYPTO tant qu'il n'a pas traité les paramètres de transport du client. Le serveur DOIT envoyer toutes les trames CRYPTO en utilisant la version négociée.

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, it indicates that the negotiated version is equal to the original version.

Le client apprend la version négociée en observant le premier champ Version de l'en-tête long qui diffère de la version originale. Si le client reçoit une trame CRYPTO du serveur dans la version originale, cela indique que la version négociée est égale à la version originale.

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.

Avant que le serveur ne soit en mesure de traiter les paramètres de transport du client, il peut avoir besoin de répondre aux paquets initiaux du client. Pour ces paquets, le serveur utilise la version originale.

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.

Une fois que le client a appris la version négociée, il DEVRAIT envoyer les paquets initiaux suivants en utilisant cette version. Le serveur NE DOIT PAS rejeter ses clés de réception initiales de la version originale tant qu'il n'a pas traité avec succès un paquet Handshake avec la version négociée.

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.

Les deux points de terminaison DOIVENT envoyer des paquets Handshake et 1-RTT en utilisant la version négociée. Un point de terminaison DOIT rejeter les paquets utilisant toute autre version. Les points de terminaison n'ont pas besoin de générer le matériel de clé qui leur permettrait de déchiffrer ou d'authentifier de tels paquets.

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.

Le client NE DOIT PAS envoyer de paquets 0-RTT utilisant la version négociée, même après avoir traité un paquet de cette version provenant du serveur. Les serveurs peuvent accepter le 0-RTT puis traiter les paquets 0-RTT de la version originale.

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

Les tickets de session TLS et les jetons NEW_TOKEN sont spécifiques à la version QUIC de la connexion qui les a fournis. Les clients NE DOIVENT PAS utiliser un ticket de session ou un jeton d'une connexion QUIC version 1 pour initier une connexion QUIC version 2, et vice versa. Lorsqu'une connexion inclut une négociation de version compatible, tous les jetons de serveur émis sont considérés comme provenant de la version négociée, et non de la version originale.

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.

Les serveurs DOIVENT valider la version d'origine de tout ticket de session ou jeton et ne pas accepter celui émis à partir d'une version différente. Un ticket rejeté entraîne un repli vers une prise de contact TLS complète, sans 0-RTT. Un jeton rejeté entraîne le maintien de l'adresse du client non vérifiée, ce qui limite la quantité de données que le serveur peut envoyer.

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

Après une négociation de version compatible, tout ticket de session résultant correspond à la version négociée plutôt qu'à la version originale.

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.

La version 2 de QUIC offre une protection contre certaines formes d'ossification. Les appareils qui supposent que tous les en-têtes longs encoderont la version 1, ou que la formule de dérivation de clé initiale de la version 1 restera invariante par rapport à la version, ne traiteront pas correctement les paquets de la version 2.

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.

Cependant, de nombreux intermédiaires, tels que les pare-feu, se concentrent sur le premier paquet d'une connexion, qui restera souvent au format version 1 en raison des considérations ci-dessus.

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

Les clients intéressés par la lutte contre l'ossification des intermédiaires peuvent initier une connexion en utilisant la version 2 s'ils sont raisonnablement certains que le serveur la prend en charge et s'ils sont prêts à subir une pénalité d'aller-retour s'ils se trompent. En particulier, un serveur qui émet un ticket de session pour la version 2 indique une intention de maintenir la prise en charge de la version 2 tant que le ticket reste valide, même si la prise en charge ne peut être garantie.

7. Applicability

QUIC version 2 provides no change from QUIC version 1 for 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.

La version 2 de QUIC ne modifie pas les capacités disponibles pour les applications par rapport à la version 1 de QUIC. Par conséquent, tous les points de code ALPN (Application-Layer Protocol Negotiation) [RFC7301] spécifiés pour fonctionner sur la version 1 de QUIC peuvent également fonctionner sur cette version de QUIC. En particulier, les ALPN "h3" [HTTP/3] et "doq" [RFC9250] peuvent fonctionner sur la version 2 de QUIC.

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

Sauf indication contraire, toutes les extensions QUIC définies pour fonctionner avec la version 1 fonctionnent également avec la version 2.

8. Security Considerations

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

La version 2 de QUIC n'introduit aucun changement dans les propriétés de sécurité ou de confidentialité de la version 1 de QUIC.

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

Le mécanisme de négociation de version obligatoire protège contre les attaques par déclassement, mais les déclassements n'ont aucune implication de sécurité, car les propriétés de version sont identiques.

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

La prise en charge de la version 2 de QUIC peut aider un observateur à prendre l'empreinte numérique des appareils clients et serveurs.

9. IANA Considerations

IANA has added the following entries to the "QUIC Versions" registry maintained at https://www.iana.org/assignments/quic.

L'IANA a ajouté les entrées suivantes au registre "QUIC Versions" géré à l'adresse https://www.iana.org/assignments/quic.

Value: 0x6b3343cf Status: permanent Specification: RFC 9369 Change Controller: IETF Contact: QUIC WG

Value: 0x709a50c4 Status: provisional Specification: RFC 9369 Change Controller: IETF Contact: QUIC WG Notes: 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/info/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/info/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/info/rfc9001.

[QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version Negotiation for QUIC", RFC 9368, DOI 10.17487/RFC9368, May 2023, https://www.rfc-editor.org/info/rfc9368.

[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/info/rfc2119.

[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/info/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/info/rfc9114.

[QUIC-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, https://www.rfc-editor.org/info/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/info/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/info/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/info/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 the 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.

Cette section montre des exemples de protection des paquets afin que les implémentations puissent être vérifiées de manière incrémentielle. Des exemples de paquets initiaux du client et du serveur ainsi qu'un paquet Retry sont définis. Ces paquets utilisent un ID de connexion de destination choisi par le client de 8 octets de 0x8394c8f03e515708. Certaines valeurs intermédiaires sont incluses. Toutes les valeurs sont indiquées en hexadécimal.

(See RFC text for details on A.1 - A.5, code blocks are untranslated)

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.

L'auteur tient à remercier Christian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa et Martin Thomson pour leurs suggestions utiles.

Author's Address

Martin Duke Google LLC Email: [email protected]