Aller au contenu principal

RFC 9001 - Utilisation de TLS pour sécuriser QUIC

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

Résumé (Abstract)​

Ce document décrit comment la sécurité de la couche de transport (TLS) est utilisée pour sécuriser QUIC [QUIC-TRANSPORT].

Table des matières (Contents)​

Annexes (Appendices)​

Ressources connexes​

1. Introduction​

Ce document décrit comment QUIC [QUIC-TRANSPORT] est sécurisé à l'aide de TLS [TLS13].

TLS 1.3 offre des améliorations de latence critiques pour l'établissement de connexion par rapport aux versions précédentes. En l'absence de perte de paquets, la plupart des nouvelles connexions peuvent être établies et sécurisées en un seul aller-retour ; sur les connexions ultérieures entre le même client et le même serveur, le client peut souvent envoyer immédiatement des données d'application, c'est-à-dire en utilisant une configuration à zéro aller-retour (0-RTT).

Ce document décrit comment TLS agit comme composant de sécurité de QUIC.

2. Conventions de notation (Notational Conventions)​

Les mots clés "MUST (DOIT)", "MUST NOT (NE DOIT PAS)", "REQUIRED (REQUIS)", "SHALL (DOIT)", "SHALL NOT (NE DOIT PAS)", "SHOULD (DEVRAIT)", "SHOULD NOT (NE DEVRAIT PAS)", "RECOMMENDED (RECOMMANDÉ)", "NOT RECOMMENDED (NON RECOMMANDÉ)", "MAY (PEUT)", et "OPTIONAL (OPTIONNEL)" dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

Ce document utilise la terminologie établie dans [QUIC-TRANSPORT].

Par souci de concision, l'abréviation TLS est utilisée pour faire référence à TLS 1.3, bien que des versions plus récentes de TLS puissent être utilisées ; voir la section 4.2.

2.1. Aperçu de TLS (TLS Overview)​

TLS fournit un moyen pour deux points d'extrémité (endpoints) d'établir un moyen de communication sur un support non fiable (comme Internet). TLS permet l'authentification des pairs et fournit une protection de confidentialité et d'intégrité pour les messages échangés entre les points d'extrémité.

En interne, TLS est un protocole en couches, avec une structure illustrée dans la Figure 1.

         +-------------+------------+--------------+---------+
Couche   |             |            |  Données     |         |
de       | Handshake   |   Alerte   | d'application|   ...   |
contenu  |             |            |              |         |
         +-------------+------------+--------------+---------+
Couche   |                                                   |
d'enreg- |                   Enregistrement                 |
istrement|                                                   |
         +---------------------------------------------------+

Figure 1: Couches de TLS

Chaque message de la couche de contenu (par exemple, handshake, alerte et données d'application) est transporté par la couche d'enregistrement sous forme d'une série d'enregistrements TLS typés. Les enregistrements sont protégés cryptographiquement individuellement puis transmis sur un transport fiable (généralement TCP) qui assure l'ordonnancement et la garantie de livraison.

Le handshake d'échange de clés authentifié TLS se produit entre deux points d'extrémité : un client et un serveur. Le client initie l'échange et le serveur répond. Si l'échange de clés se termine avec succès, le client et le serveur conviennent tous deux d'un secret. TLS prend en charge à la fois les clés pré-partagées (PSK) et l'échange de clés Diffie-Hellman basé sur les corps finis ou les courbes elliptiques ((EC)DHE). Les PSK sont la base des données précoces (0-RTT) ; ces dernières fournissent une confidentialité persistante (FS) lorsque les clés (EC)DHE sont détruites. Ces deux modes peuvent également être combinés pour fournir une confidentialité persistante tout en utilisant une PSK pour l'authentification.

Après avoir terminé le handshake TLS, le client aura appris et authentifié l'identité du serveur et le serveur peut éventuellement avoir appris et authentifié l'identité du client. TLS prend en charge l'authentification du serveur et du client basée sur les certificats X.509 [RFC5280]. Lorsqu'un échange de clés PSK est utilisé (comme dans la reprise de session), la connaissance de la PSK est utilisée pour authentifier le pair.

L'échange de clés TLS résiste à la falsification par un attaquant et le secret partagé qu'il produit ne peut être contrôlé par aucun pair participant.

TLS fournit deux modes de handshake de base qui intéressent QUIC :

  • Un handshake complet 1-RTT, dans lequel le client peut envoyer des données d'application après un aller-retour et le serveur répond immédiatement après avoir reçu le premier message de handshake du client.

  • Un handshake 0-RTT, dans lequel le client utilise des informations qu'il a précédemment apprises sur le serveur pour envoyer immédiatement des données d'application. Ces données d'application peuvent être rejouées par un attaquant, donc 0-RTT ne convient pas pour transporter des instructions qui pourraient déclencher des actions dont la relecture pourrait avoir des conséquences indésirables.

La Figure 2 montre un handshake TLS simplifié avec des données d'application 0-RTT.

Client                                             Serveur

ClientHello
(données d'application 0-RTT)  -------->
                                                     ServerHello
                                            {EncryptedExtensions}
                                                       {Finished}
                                    <--------   [données d'application]
{Finished}                -------->

[données d'application]   <------->   [données d'application]

() Indique les messages protégés par les clés de données précoces (0-RTT)
{} Indique les messages protégés par les clés de handshake
[] Indique les messages protégés par les clés de données d'application (1-RTT)

Figure 2: Handshake TLS avec 0-RTT

La Figure 2 omet le message EndOfEarlyData, qui n'est pas utilisé dans QUIC ; voir la section 8.3. De même, QUIC n'utilise pas non plus les messages ChangeCipherSpec ou KeyUpdate. ChangeCipherSpec est redondant dans TLS 1.3 ; voir la section 8.4. QUIC dispose de son propre mécanisme de mise à jour de clé ; voir la section 6.

Les données sont protégées à l'aide de plusieurs niveaux de chiffrement :

  • Clés initiales (Initial keys)
  • Clés de données précoces (0-RTT) (Early data (0-RTT) keys)
  • Clés de handshake (Handshake keys)
  • Clés de données d'application (1-RTT) (Application data (1-RTT) keys)

Les données d'application ne peuvent apparaître qu'aux niveaux de données précoces et de données d'application. Les messages de handshake et d'alerte peuvent apparaître à n'importe quel niveau.

Un handshake 0-RTT peut être utilisé si le client et le serveur ont précédemment communiqué. Dans un handshake 1-RTT, le client ne peut pas envoyer de données d'application protégées tant qu'il n'a pas reçu tous les messages de handshake envoyés par le serveur.

3. Aperçu du protocole (Protocol Overview)​

QUIC [QUIC-TRANSPORT] est responsable de la protection de la confidentialité et de l'intégrité des paquets. Pour ce faire, il utilise des clés dérivées du handshake TLS [TLS13], mais contrairement à TLS sur TCP, les messages de handshake et d'alerte TLS sont directement transportés par la couche de transport QUIC, qui reprend le rôle de la couche d'enregistrement TLS, comme illustré dans la Figure 3.

+--------------+--------------+ +-------------+
|     TLS      |     TLS      | |    QUIC     |
|  Handshake   |    Alerte    | | Application |
|              |              | |  (h3, etc.) |
+--------------+--------------+-+-------------+
|                                             |
|            Couche de transport QUIC         |
|   (flux, fiabilité, contrôle de congestion) |
|                                             |
+---------------------------------------------+
|                                             |
|        Protection des paquets QUIC          |
|                                             |
+---------------------------------------------+

Figure 3: Couches de QUIC

QUIC s'appuie également sur TLS pour l'authentification et la négociation de paramètres critiques pour la sécurité et les performances.

Ces deux protocoles ne sont pas strictement en couches, mais coopèrent : QUIC utilise le handshake TLS ; TLS utilise la fiabilité, la livraison ordonnée et la couche d'enregistrement fournies par QUIC.

À un niveau élevé, il existe deux interactions principales entre les composants TLS et QUIC :

  • Le composant TLS envoie et reçoit des messages via le composant QUIC, QUIC fournissant une abstraction de flux fiable à TLS.

  • Le composant TLS fournit une série de mises à jour au composant QUIC, y compris (a) de nouvelles clés de protection de paquets à installer et (b) des changements d'état tels que la fin du handshake, le certificat du serveur, etc.

La Figure 4 montre ces interactions plus en détail, avec la protection des paquets QUIC particulièrement mise en évidence.

+------------+                               +------------+
|            |<--- Messages de handshake --->|            |
|            |<- Vérifier les paramètres ---->|            |
|            |<--------- Clés 0-RTT ---------|            |
|    QUIC    |<------- Clés handshake -------|    TLS     |
|            |<--------- Clés 1-RTT ---------|            |
|            |<---- Handshake terminé -------|            |
+------------+                               +------------+
 |         ^
 | Protéger| Paquets
 v         | protégés
+------------+
|   QUIC     |
|  Protection|
|  de paquet |
+------------+

Figure 4: Interactions QUIC et TLS

Contrairement à TLS sur TCP, les applications QUIC qui souhaitent envoyer des données ne les envoient pas à l'aide d'enregistrements de données d'application TLS. Au lieu de cela, ils les envoient sous forme de trames STREAM QUIC ou d'autres types de trames, qui sont ensuite transportées dans des paquets QUIC.

4. Transport des messages TLS (Carrying TLS Messages)​

QUIC transporte les données de handshake TLS dans des trames CRYPTO. Chaque trame CRYPTO se compose d'un bloc contigu de données de handshake identifié par un décalage et une longueur. Ces trames sont empaquetées dans des paquets QUIC et chiffrées en utilisant le niveau de chiffrement actuel. Comme avec TLS sur TCP, une fois que les données de handshake TLS sont livrées à QUIC, il est de la responsabilité de QUIC de les livrer de manière fiable. Chaque bloc de données produit par TLS est associé à l'ensemble des clés que TLS utilise actuellement. Si QUIC doit retransmettre ces données, il DOIT (MUST) utiliser les mêmes clés même si TLS a déjà mis à jour vers des clés plus récentes.

4.1. Interface vers TLS (Interface to TLS)​

Comme illustré dans la Figure 4, l'interface de QUIC vers TLS comprend quatre fonctions principales :

  • Envoi et réception de messages de handshake
  • Traitement de l'état de transport et d'application stocké à partir de sessions de reprise et détermination de la validité de la génération ou de l'acceptation de données 0-RTT
  • Re-keying (y compris l'envoi et la réception)
  • Mise à jour de l'état du handshake

Des fonctions supplémentaires peuvent être nécessaires pour configurer TLS. En particulier, QUIC et TLS doivent s'accorder sur qui est responsable de la validation des informations d'identification des pairs (par exemple, la validation des certificats [RFC5280]).

4.1.1. Handshake terminé (Handshake Complete)​

Dans ce document, le handshake TLS est considéré comme terminé lorsque la pile TLS signale la fin du handshake. Cela se produit lorsque la pile TLS a à la fois envoyé un message Finished et vérifié le message Finished du pair.

4.1.2. Handshake confirmé (Handshake Confirmed)​

Dans ce document, le handshake TLS est considéré comme confirmé côté serveur lorsque le handshake est terminé. Le serveur DOIT (MUST) envoyer une trame HANDSHAKE_DONE immédiatement après la fin du handshake. Côté client, le handshake est considéré comme confirmé lorsqu'une trame HANDSHAKE_DONE est reçue.

De plus, le client PEUT (MAY) considérer le handshake comme confirmé lorsqu'il reçoit un accusé de réception de paquets 1-RTT.

4.1.3. Envoi et réception des messages de handshake​

Pour piloter le handshake, TLS dépend de la capacité d'envoyer et de recevoir des messages de handshake. Il existe deux fonctions de base sur cette interface : une fonction pour que QUIC demande des messages de handshake et une autre fonction pour que QUIC fournisse les octets qui constituent un message de handshake.

Avant de commencer le handshake, QUIC fournit à TLS les paramètres de transport qu'il souhaite transporter (voir la section 8.2).

Le client QUIC initie TLS en demandant les octets de handshake TLS à TLS. Le client obtient les octets de handshake avant d'envoyer son premier paquet. Le serveur QUIC initie le processus en fournissant à TLS les octets de handshake du client.

4.1.4. Changements de niveau de chiffrement (Encryption Level Changes)​

Lorsque les clés pour un niveau de chiffrement donné sont disponibles pour TLS, TLS indique à QUIC que les clés de lecture et d'écriture pour ce niveau de chiffrement sont disponibles.

4.1.5. Résumé de l'interface TLS (TLS Interface Summary)​

La Figure 5 résume les échanges entre QUIC et TLS pour le client et le serveur. Les flèches pleines indiquent les paquets transportant des données de handshake ; les flèches en pointillés indiquent où les données d'application peuvent être envoyées.

[Diagramme simplifié - voir l'original pour les détails complets]

4.2. Version TLS (TLS Version)​

Ce document décrit comment TLS 1.3 [TLS13] est utilisé avec QUIC.

En pratique, le handshake TLS négociera la version TLS à utiliser. Si les deux points d'extrémité prennent en charge cette version, cela pourrait entraîner la négociation d'une version TLS plus récente que 1.3. Ceci est acceptable tant que les fonctionnalités de TLS 1.3 utilisées par QUIC sont prises en charge par la version plus récente.

Un client NE DOIT PAS (MUST NOT) offrir une version TLS antérieure à 1.3. Si une version TLS antérieure à 1.3 est négociée, le point d'extrémité DOIT (MUST) terminer la connexion.

4.3. Taille de ClientHello (ClientHello Size)​

Le premier paquet Initial d'un client contient le début ou la totalité de son premier message de handshake chiffré, qui pour TLS est le ClientHello. Un serveur peut avoir besoin d'analyser l'intégralité du ClientHello pour décider d'accepter ou non une nouvelle connexion QUIC entrante.

4.4. Authentification des pairs (Peer Authentication)​

Les exigences d'authentification dépendent du protocole d'application utilisé. TLS fournit l'authentification du serveur et permet au serveur de demander l'authentification du client.

Un client DOIT (MUST) authentifier l'identité du serveur. Cela implique généralement de vérifier que l'identité du serveur est incluse dans un certificat et que le certificat a été émis par une entité de confiance.

Un serveur PEUT (MAY) demander l'authentification du client pendant le handshake. Un serveur NE DOIT PAS (MUST NOT) utiliser l'authentification client post-handshake.

4.5. Reprise de session (Session Resumption)​

QUIC peut utiliser la fonctionnalité de reprise de session de TLS 1.3. Cela se fait en transportant des messages NewSessionTicket dans des trames CRYPTO après la fin du handshake.

4.6. 0-RTT​

La fonctionnalité 0-RTT de QUIC permet à un client d'envoyer des données d'application avant la fin du handshake. Cela est rendu possible en réutilisant les paramètres négociés à partir d'une connexion précédente.

4.6.1. Activation de 0-RTT (Enabling 0-RTT)​

L'extension TLS early_data dans le message NewSessionTicket est définie pour transmettre la quantité de données TLS 0-RTT que le serveur acceptera (dans le paramètre max_early_data_size). QUIC n'utilise pas les données précoces TLS. QUIC utilise des paquets de données 0-RTT pour transporter les données précoces. Par conséquent, le paramètre max_early_data_size est réutilisé pour contenir une valeur sentinelle 0xffffffff pour indiquer que le serveur est disposé à accepter des données QUIC 0-RTT.

4.6.2. Acceptation et rejet de 0-RTT​

Un serveur accepte 0-RTT en envoyant une extension early_data dans EncryptedExtensions. Le serveur traite et accuse ensuite réception des paquets de données 0-RTT qu'il a reçus.

Un serveur rejette 0-RTT en envoyant EncryptedExtensions sans extension early_data. Lors du rejet de 0-RTT, un serveur NE DOIT PAS (MUST NOT) traiter les paquets de données 0-RTT, même s'il pourrait le faire.

4.6.3. Validation de la configuration 0-RTT​

Lorsqu'un serveur reçoit un ClientHello avec une extension early_data, il doit décider d'accepter ou de rejeter les données 0-RTT du client. Une partie de la décision est prise par la pile TLS.

4.7. HelloRetryRequest​

Le message HelloRetryRequest peut être utilisé pour demander au client de fournir de nouvelles informations ou pour valider certaines caractéristiques du client. Du point de vue de QUIC, HelloRetryRequest n'est pas différent d'un autre message de handshake chiffré transporté dans des paquets Initial.

4.8. Erreurs TLS (TLS Errors)​

Si TLS rencontre une erreur, il génère l'alerte appropriée définie dans la section 6 de [TLS13].

Les alertes TLS sont converties en erreurs de connexion QUIC. La valeur AlertDescription plus 0x0100 est ajoutée pour produire un code d'erreur QUIC dans la plage CRYPTO_ERROR.

4.9. Suppression des clés inutilisées (Discarding Unused Keys)​

Après que QUIC ait terminé sa transition vers un nouveau niveau de chiffrement, les clés de protection de paquet du niveau de chiffrement précédent peuvent être supprimées.

4.9.1. Suppression des clés initiales (Discarding Initial Keys)​

Les paquets protégés par les secrets initiaux ne sont pas authentifiés, ce qui signifie qu'un attaquant pourrait falsifier des paquets pour perturber une connexion. Pour limiter ces attaques, les clés de protection de paquet Initial sont supprimées de manière plus agressive que les autres clés.

4.9.2. Suppression des clés de handshake (Discarding Handshake Keys)​

Un point d'extrémité DOIT (MUST) supprimer ses clés de handshake lorsque le handshake TLS est confirmé (section 4.1.2).

4.9.3. Suppression des clés 0-RTT (Discarding 0-RTT Keys)​

Les paquets 0-RTT et 1-RTT partagent le même espace de numérotation de paquets, et un client n'envoie pas de paquets 0-RTT après avoir envoyé des paquets 1-RTT (section 5.6).

Par conséquent, un client DEVRAIT (SHOULD) supprimer les clés 0-RTT dès qu'il installe les clés 1-RTT, car elles ne seront plus utiles par la suite.

5. Protection des paquets (Packet Protection)​

Comme avec TLS sur TCP, QUIC protège les paquets en utilisant des clés dérivées du handshake TLS, en utilisant l'algorithme AEAD [AEAD] négocié par TLS.

Les paquets QUIC ont une protection différente selon leur type :

  • Les paquets de négociation de version (Version Negotiation) n'ont pas de protection cryptographique.

  • Les paquets de nouvelle tentative (Retry) utilisent AEAD_AES_128_GCM pour fournir une protection contre les modifications accidentelles et limiter les entités capables de générer un Retry valide (voir Section 5.8).

  • Les paquets Initial utilisent AEAD_AES_128_GCM avec des clés dérivées du champ Destination Connection ID du premier paquet Initial envoyé par le client (voir Section 5.2).

  • Tous les autres paquets ont une forte protection cryptographique de confidentialité et d'intégrité en utilisant les clés et l'algorithme négociés par TLS.

Cette section décrit comment la protection des paquets est appliquée aux paquets Handshake, 0-RTT et 1-RTT. Le même processus de protection des paquets est appliqué aux paquets Initial. Cependant, comme il est trivial de déterminer les clés utilisées pour les paquets Initial, ces paquets ne sont pas considérés comme ayant une protection de confidentialité ou d'intégrité. Les paquets Retry utilisent une clé fixe, donc ils manquent également de confidentialité et de protection d'intégrité.

5.1. Clés de protection des paquets (Packet Protection Keys)​

QUIC dérive les clés de protection des paquets de la même manière que TLS dérive les clés de protection des enregistrements.

Chaque niveau de chiffrement a une valeur secrète séparée pour protéger les paquets envoyés dans chaque direction. Ces secrets de trafic (traffic secrets) sont dérivés par TLS (voir Section 7.1 de [TLS13]) et sont utilisés par QUIC pour tous les niveaux de chiffrement sauf le niveau de chiffrement Initial. Les secrets pour le niveau de chiffrement Initial sont calculés en fonction du Destination Connection ID initial du client, comme décrit dans la Section 5.2.

Les clés utilisées pour la protection des paquets sont calculées à partir des secrets TLS en utilisant le KDF fourni par TLS. Dans TLS 1.3, la fonction HKDF-Expand-Label décrite dans la Section 7.1 de [TLS13] est utilisée, en utilisant la fonction de hachage de la suite de chiffrement négociée. Toutes les utilisations de HKDF-Expand-Label dans QUIC utilisent un Context (contexte) de longueur nulle.

Notez que les étiquettes (Labels) décrites comme des chaînes sont encodées en octets en utilisant ASCII [ASCII] sans guillemets ni octets NUL finaux.

Le secret du niveau de chiffrement actuel et l'étiquette "quic key" sont utilisés comme entrée du KDF pour générer la clé AEAD. L'étiquette "quic iv" est utilisée pour dériver le vecteur d'initialisation (IV) (voir Section 5.3). La clé de protection d'en-tête utilise l'étiquette "quic hp" (voir Section 5.4). L'utilisation de ces étiquettes fournit une séparation des clés entre QUIC et TLS (voir Section 9.6).

Comme "quic key" et "quic hp" sont tous deux utilisés pour produire des clés, la longueur (Length) fournie à HKDF-Expand-Label avec ces étiquettes est déterminée par la taille de clé pour l'algorithme AEAD ou de protection d'en-tête. La longueur fournie pour "quic iv" est la longueur minimale du nonce AEAD, ou 8 octets si c'est plus grand (voir [AEAD]).

Le KDF utilisé pour les secrets Initial est toujours la fonction HKDF-Expand-Label de TLS 1.3 (voir Section 5.2).

5.2. Secrets initiaux (Initial Secrets)​

Les paquets Initial appliquent le processus de protection des paquets, mais utilisent un secret dérivé du champ Destination Connection ID du premier paquet Initial envoyé par le client.

Ce secret est déterminé en utilisant HKDF-Extract (voir Section 2.2 de [HKDF]). Le sel (salt) est 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a et le matériel de clé d'entrée (IKM) est le champ Destination Connection ID. Cela produit une clé pseudo-aléatoire intermédiaire (PRK) qui est utilisée pour dériver deux secrets séparés pour l'envoi et la réception.

Le secret utilisé par le client pour construire les paquets Initial utilise le PRK et l'étiquette "client in" comme entrée de la fonction HKDF-Expand-Label de TLS [TLS13] pour produire un secret de 32 octets. Les paquets construits par le serveur utilisent le même processus avec l'étiquette "server in". La fonction de hachage pour HKDF dans la dérivation des secrets et clés initiaux est SHA-256 [SHA].

Le pseudo-code pour ce processus est :

initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
initial_secret = HKDF-Extract(initial_salt,
                              client_dst_connection_id)

client_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "client in", "",
                                          Hash.length)
server_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "server in", "",
                                          Hash.length)

L'ID de connexion utilisé avec HKDF-Expand-Label est le Destination Connection ID dans le paquet Initial envoyé par le client. Ce sera une valeur choisie aléatoirement à moins que le client ne crée un paquet Initial après avoir reçu un paquet Retry, auquel cas le Destination Connection ID est sélectionné par le serveur.

Les versions futures de QUIC devraient (SHOULD) générer une nouvelle valeur de sel, garantissant ainsi que les clés sont différentes pour chaque version de QUIC. Cela empêche un middlebox qui reconnaît seulement une version de QUIC de voir ou de modifier le contenu des paquets des versions futures.

Les paquets Initial doivent (MUST) utiliser la fonction HKDF-Expand-Label définie dans TLS 1.3 même si les versions TLS fournies n'incluent pas TLS 1.3.

La transmission d'un paquet Retry par le serveur et l'utilisation d'une valeur Connection ID sélectionnée par le serveur entraînent une modification des secrets utilisés pour construire les paquets Initial ultérieurs. Le Destination Connection ID utilisé par le client en réponse au paquet Initial du serveur ne modifie pas les secrets.

| Note : Le champ Destination Connection ID peut avoir une longueur allant jusqu'à 20 octets, ou peut être | de longueur nulle si le serveur envoie un paquet Retry avec un champ Source Connection ID de longueur nulle. | Après un Retry, les clés Initial ne garantissent pas au client que le serveur a reçu les paquets, donc | le client doit se fier à l'échange qui inclut un paquet Retry pour valider l'adresse du serveur | (voir Section 8.1 de [QUIC-TRANSPORT]).

L'Annexe A contient des exemples de paquets Initial.

5.3. Utilisation d'AEAD (AEAD Usage)​

La fonction de chiffrement authentifié avec données associées (AEAD) (voir [AEAD]) utilisée pour la protection des paquets QUIC est l'AEAD négocié pour être utilisé avec la connexion TLS. Par exemple, si TLS utilise la suite de chiffrement TLS_AES_128_GCM_SHA256, la fonction AEAD_AES_128_GCM est utilisée.

QUIC peut utiliser n'importe quelle suite de chiffrement définie dans [TLS13] à l'exception de TLS_AES_128_CCM_8_SHA256. Une suite de chiffrement ne doit pas (MUST NOT) être négociée à moins qu'un schéma de protection d'en-tête n'ait été défini pour la suite de chiffrement. Ce document définit des schémas de protection d'en-tête pour toutes les suites de chiffrement définies dans [TLS13] sauf TLS_AES_128_CCM_8_SHA256. Ces suites de chiffrement ont un tag d'authentification (authentication tag) de 16 octets et produisent une sortie de 16 octets plus grande que l'entrée.

Un endpoint ne doit pas (MUST NOT) rejeter un ClientHello qui offre une suite de chiffrement qu'il ne supporte pas, sinon il ne serait pas possible de déployer de nouvelles suites de chiffrement. Cela s'applique également à TLS_AES_128_CCM_8_SHA256.

Lors de la construction d'un paquet, la fonction AEAD est appliquée avant d'appliquer la protection d'en-tête (voir Section 5.4). L'en-tête de paquet non protégé fait partie des données associées (A). Lors du traitement d'un paquet, un endpoint supprime d'abord la protection d'en-tête.

La clé et l'IV du paquet sont calculés comme décrit dans la Section 5.1. Le nonce (N) est formé en combinant l'IV de protection du paquet avec le numéro de paquet. Les 62 bits du numéro de paquet QUIC reconstruit dans l'ordre des octets réseau sont remplis à gauche avec des zéros jusqu'à la taille de l'IV. Le OU exclusif (XOR) du numéro de paquet rempli et de l'IV forme le nonce AEAD.

Les données associées A de l'AEAD sont le contenu de l'en-tête du paquet QUIC, commençant par le premier octet de l'en-tête court ou long, jusqu'à et y compris le numéro de paquet non protégé.

Le texte en clair P de l'AEAD est la charge utile du paquet QUIC, comme décrit dans [QUIC-TRANSPORT].

Le texte chiffré C de l'AEAD est transmis à la place de P.

Certaines fonctions AEAD ont une limite sur le nombre de paquets qui peuvent être chiffrés avec la même clé et IV (voir Section 6.6). Cela peut être inférieur à la limite du numéro de paquet. Un endpoint doit (MUST) initier une mise à jour de clé (Section 6) avant de dépasser toute limite imposée par la configuration AEAD en cours d'utilisation.

5.4. Protection de l'en-tête (Header Protection)​

Certaines parties de l'en-tête du paquet QUIC, en particulier le champ Packet Number (numéro de paquet), sont protégées en utilisant une clé dérivée séparément des clés de protection du paquet et de l'IV. La clé dérivée en utilisant l'étiquette "quic hp" est utilisée pour fournir une protection de confidentialité pour les champs qui ne sont pas exposés aux éléments sur le chemin (path).

Cette protection est appliquée aux bits les moins significatifs du premier octet et au champ Packet Number. Pour les paquets à en-tête long, les 4 bits les moins significatifs du premier octet sont protégés. Pour les paquets à en-tête court, les 5 bits les moins significatifs du premier octet sont protégés. Pour les deux formats d'en-tête, cela couvre les bits Reserved (réservés) et le champ Packet Number Length (longueur du numéro de paquet). Le bit Key Phase (phase de clé) est également protégé dans les paquets à en-tête court.

La même clé de protection d'en-tête est utilisée pour l'ensemble de la connexion et sa valeur ne change pas après les mises à jour de clé (voir Section 6). Cela permet d'utiliser la protection d'en-tête pour protéger la phase de clé.

Ce processus ne s'applique pas aux paquets Retry ou Version Negotiation, qui ne contiennent pas de charge utile protégée ou n'incluent pas de champs protégés par ce processus.

Remarque : Pour limiter la longueur du document et assurer l'exhaustivité, il est recommandé de consulter le texte original RFC 9001 pour les détails techniques complets sur les sections restantes (5.4.1-5.8), qui incluent :

  • 5.4.1. Application de la protection d'en-tête
  • 5.4.2. Échantillon de protection d'en-tête
  • 5.4.3. Protection d'en-tête basée sur AES
  • 5.4.4. Protection d'en-tête basée sur ChaCha20
  • 5.5. Réception de paquets protégés
  • 5.6. Utilisation des clés 0-RTT
  • 5.7. Réception de paquets protégés hors séquence
  • 5.8. Intégrité des paquets de nouvelle tentative

Pour la documentation technique complète, veuillez vous référer à :
https://www.rfc-editor.org/rfc/rfc9001.html#section-5

6. Mise à jour des clés (Key Update)​

Une fois que le handshake 1-RTT est terminé, les points d'extrémité peuvent mettre à jour les clés utilisées pour protéger les paquets 1-RTT. Cela permet de protéger contre les compromissions de clés. Un point d'extrémité initie une mise à jour de clé en mettant à jour les clés qu'il utilise pour l'envoi de paquets.

La mise à jour de clé dans QUIC est distincte du mécanisme KeyUpdate de TLS. La mise à jour de clé QUIC utilise les fonctions de dérivation de clés de la bibliothèque TLS.

6.1. Initier une mise à jour de clé (Initiating a Key Update)​

Les points d'extrémité maintiennent des clés séparées de lecture et d'écriture. Un point d'extrémité initie une mise à jour de clé en mettant à jour ses clés d'écriture de paquet et en commençant à les utiliser pour protéger les paquets qu'il envoie. Le point d'extrémité crée une nouvelle clé secrète en utilisant la fonction KDF fournie par TLS.

Le point d'extrémité met ensuite à jour ses clés de protection de paquet et utilise les clés mises à jour pour protéger les nouveaux paquets.

6.2. Répondre à une mise à jour de clé (Responding to a Key Update)​

Lorsqu'un point d'extrémité reçoit un paquet avec un nouveau numéro de génération de clé plus grand que n'importe quelle clé qu'il a reçue précédemment, il sait que le pair a mis à jour ses clés. Le point d'extrémité DOIT (MUST) mettre à jour ses clés de réception avant de traiter avec succès le paquet.

Si un point d'extrémité détecte un second paquet avec un numéro de génération de clé plus grand que celui qu'il a utilisé, il indique que le pair a répondu à la mise à jour de clé. Dans ce cas, le point d'extrémité DOIT (MUST) mettre à jour ses clés d'envoi de paquet si ce n'est pas déjà fait.

6.3. Timing de génération des clés de réception​

Les implémentations peuvent choisir de conserver des clés de réception plus anciennes pendant un certain temps pour permettre de recevoir des paquets qui ont été retardés dans le réseau. Cependant, dès qu'un point d'extrémité reçoit un paquet 1-RTT qui nécessite la génération de clés suivante, il DEVRAIT (SHOULD) mettre à jour ses clés de réception.

6.4. Envoi avec des clés mises à jour (Sending with Updated Keys)​

Un point d'extrémité n'envoie jamais de paquets protégés avec des clés plus anciennes. Seuls des paquets protégés avec la génération de clés la plus récente sont envoyés. Les clés d'envoi plus anciennes DOIVENT (MUST) être supprimées lorsque des clés plus récentes sont disponibles.

6.5. Réception avec différentes clés (Receiving with Different Keys)​

Pour les paquets protégés avec des clés obsolètes qui arrivent après qu'un point d'extrémité ait mis à jour, le point d'extrémité peut soit supprimer ces paquets sans traitement, soit tenter de les traiter. Si l'implémentation choisit de conserver les clés plus anciennes, elle peut traiter les paquets qui arrivent tard.

6.6. Limites d'utilisation d'AEAD (Limits on AEAD Usage)​

Chaque suite AEAD a une limite sur la quantité de données qu'elle peut chiffrer de manière sécurisée. Cela prend en compte à la fois le nombre de paquets protégés avec une clé donnée et la taille de ces paquets.

L'analyse dans [AEBounds] et [ROBUST] montre que la limite de confidentialité pour tous les AEAD actuellement acceptés dans QUIC est considérablement plus grande que les limites de protection contre la falsification.

Les points d'extrémité DOIVENT (MUST) compter le nombre d'octets de texte chiffré qui ont été chiffrés pour chaque clé de chiffrement et initier une mise à jour de clé avant de chiffrer plus que la limite de confidentialité pour l'AEAD utilisé.

Les limites spécifiques pour chaque AEAD sont listées dans la section 6.6.

Pour AEAD_AES_128_GCM et AEAD_AES_256_GCM :

  • Limite de confidentialité : 2^23 paquets
  • Limite d'intégrité : 2^52 tentatives d'authentification

Pour AEAD_CHACHA20_POLY1305 :

  • Limite de confidentialité : 2^23 paquets
  • Limite d'intégrité : 2^36 tentatives d'authentification

Pour AEAD_AES_128_CCM :

  • Limite de confidentialité : 2^21.5 paquets
  • Limite d'intégrité : 2^23.5 tentatives d'authentification

6.7. Code d'erreur de mise à jour de clé (Key Update Error Code)​

Le code d'erreur KEY_UPDATE_ERROR (0x0E) est utilisé pour signaler des erreurs liées à la mise à jour de clé.

7. Sécurité des messages initiaux (Security of Initial Messages)​

Les paquets Initial ne bénéficient pas d'authentification basée sur un secret. L'authentification pour ces paquets provient entièrement du handshake qui suit. Un adversaire pourrait :

  • Injecter, modifier ou supprimer des paquets Initial
  • Rejouer des paquets Initial
  • Provoquer l'envoi de grands volumes de trafic d'attaque par réflexion

Les exigences énoncées dans cette section limitent l'impact de ces attaques.

7.1. Attaques par amplification (Amplification Attacks)​

Les attaques par amplification sont une préoccupation pour tous les protocoles, mais QUIC ajoute des contraintes supplémentaires. Un serveur DOIT (MUST) utiliser les mécanismes anti-amplification décrits dans la section 8.1 de [QUIC-TRANSPORT].

7.2. Authentification de la négociation de version (Version Negotiation Authentication)​

Le paquet Version Negotiation n'a aucune protection cryptographique. Les endpoints DOIVENT (MUST) vérifier l'intégrité du résultat de la négociation de version en vérifiant que :

  1. Le ClientHello contient une version prise en charge par le client
  2. La version sélectionnée par le serveur est également prise en charge par le client

Cette vérification empêche un attaquant de forcer une dégradation de version en modifiant les paquets Version Negotiation.

7.3. Intégrité de la négociation de version étendue​

Comme décrit dans la section précédente, le mécanisme de base garantit que si une connexion QUIC est établie avec succès, elle utilise une version acceptable pour les deux pairs. Cependant, un attaquant pourrait toujours influencer la sélection de version en supprimant sélectivement des paquets Initial.

Pour détecter de telles attaques, la version réellement utilisée est authentifiée en incluant sa valeur dans les messages de handshake TLS. Le client inclut une extension dans le ClientHello qui contient toutes les versions que le client tente d'utiliser (voir section 8.1).

7.4. Déni de service avec paquets Initial modifiés​

Un attaquant peut modifier des paquets Initial pour provoquer une utilisation inefficace des ressources. Par exemple, un attaquant pourrait modifier des paquets Initial pour augmenter la taille des messages de handshake, provoquant le gaspillage de ressources serveur.

Les serveurs NE DOIVENT PAS (MUST NOT) conserver l'état de connexion (allouer des ressources) jusqu'à ce que les informations du client aient été authentifiées avec succès.

8. Ajustements spécifiques à QUIC du handshake TLS (QUIC-Specific Adjustments to the TLS Handshake)​

Lorsqu'il est utilisé avec QUIC, certains aspects du handshake TLS sont différents.

QUIC exige également que le handshake cryptographique fournisse une négociation authentifiée des paramètres qui sont critiques pour la sécurité et les performances. En plus de la négociation des paramètres cryptographiques, le handshake TLS transporte et valide également les valeurs des paramètres de transport QUIC.

8.1. Négociation de protocole (Protocol Negotiation)​

QUIC exige que le handshake cryptographique fournisse une négociation de protocole authentifiée. TLS utilise Application-Layer Protocol Negotiation (ALPN) [ALPN] pour sélectionner un protocole d'application. À moins qu'un autre mécanisme ne soit utilisé pour convenir d'un protocole d'application, les endpoints doivent (MUST) utiliser ALPN à cette fin.

Lors de l'utilisation d'ALPN, les endpoints doivent (MUST) fermer immédiatement la connexion (voir Section 10.2 de [QUIC-TRANSPORT]) avec une alerte TLS no_application_protocol (code d'erreur QUIC 0x0178 ; voir Section 4.8) si aucun protocole d'application n'est négocié. [ALPN] spécifie que seuls les serveurs utilisent cette alerte, mais les clients QUIC doivent (MUST) utiliser l'erreur 0x0178 pour terminer une connexion lorsque la négociation ALPN échoue.

Un protocole d'application peut (MAY) restreindre les versions de QUIC qui peuvent être utilisées. Les serveurs doivent (MUST) sélectionner un protocole d'application compatible avec la version QUIC sélectionnée par le client. Le serveur doit (MUST) traiter l'incapacité à sélectionner un protocole d'application compatible comme une erreur de connexion de type 0x0178 (no_application_protocol). De même, un client doit (MUST) traiter la sélection d'un protocole d'application incompatible par le serveur comme une erreur de connexion de type 0x0178.

8.2. Extension des paramètres de transport QUIC (QUIC Transport Parameters Extension)​

Les paramètres de transport QUIC sont transportés dans une extension TLS. Différentes versions de QUIC peuvent définir différentes méthodes pour négocier la configuration du transport.

L'inclusion des paramètres de transport dans le handshake TLS fournit une protection d'intégrité pour ces valeurs.

enum {
   quic_transport_parameters(0x39), (65535)
} ExtensionType;

Le champ extension_data de l'extension quic_transport_parameters contient une valeur définie par la version de QUIC en cours d'utilisation.

L'extension quic_transport_parameters est transportée dans les messages ClientHello et EncryptedExtensions pendant le handshake. Les endpoints doivent (MUST) envoyer l'extension quic_transport_parameters. Un endpoint qui reçoit un ClientHello ou EncryptedExtensions sans l'extension quic_transport_parameters doit (MUST) fermer la connexion avec une erreur de type 0x016d (équivalent à une alerte TLS fatale missing_extension ; voir Section 4.8).

Les paramètres de transport deviennent disponibles avant la fin du handshake. Un serveur peut utiliser ces valeurs avant la fin du handshake. Cependant, les valeurs des paramètres de transport ne sont pas authentifiées avant la fin du handshake, donc toute utilisation de ces paramètres ne peut pas se fier à leur authenticité. La falsification des paramètres de transport entraînera l'échec du handshake.

Les endpoints ne doivent pas (MUST NOT) envoyer cette extension dans une connexion TLS qui n'utilise pas QUIC (comme l'utilisation de TLS sur TCP définie dans [TLS13]). Une implémentation qui supporte cette extension doit (MUST) envoyer une alerte fatale unsupported_extension si elle reçoit cette extension lorsque le transport n'est pas QUIC.

La négociation de l'extension quic_transport_parameters supprime EndOfEarlyData (voir Section 8.3).

8.3. Suppression du message EndOfEarlyData (Removing the EndOfEarlyData Message)​

Le message TLS EndOfEarlyData n'est pas utilisé avec QUIC. QUIC ne dépend pas de ce message pour marquer la fin des données 0-RTT ou pour signaler la transition vers les clés Handshake.

Les clients ne doivent pas (MUST NOT) envoyer le message EndOfEarlyData. Un serveur doit (MUST) traiter la réception d'une trame CRYPTO dans un paquet de données 0-RTT comme une erreur de connexion de type PROTOCOL_VIOLATION.

En conséquence, EndOfEarlyData n'apparaît pas dans la transcription du handshake TLS.

8.4. Interdiction du mode de compatibilité middlebox TLS (Prohibiting TLS Middlebox Compatibility Mode)​

L'Annexe D.4 de [TLS13] décrit une modification du handshake TLS 1.3 comme solution de contournement pour des bugs dans certains middleboxes. Le mode de compatibilité middlebox TLS 1.3 implique de définir le champ legacy_session_id dans ClientHello et ServerHello sur une valeur de 32 octets et d'envoyer un enregistrement change_cipher_spec. Ni le champ ni l'enregistrement ne portent de contenu sémantique et sont ignorés.

Ce mode n'est pas utile dans QUIC car il s'applique uniquement aux middleboxes qui interfèrent avec TLS sur TCP. QUIC ne fournit même pas de moyen de transporter des enregistrements change_cipher_spec. Les clients ne doivent pas (MUST NOT) demander l'utilisation du mode de compatibilité TLS 1.3. Un serveur devrait (SHOULD) traiter la réception d'un TLS ClientHello avec un champ legacy_session_id non vide comme une erreur de connexion de type PROTOCOL_VIOLATION.

9. Considérations de sécurité (Security Considerations)​

Toutes les considérations de sécurité qui s'appliquent à TLS s'appliquent également à l'utilisation de TLS dans QUIC. La lecture de l'intégralité de [TLS13] et de ses annexes est le meilleur moyen de comprendre les propriétés de sécurité de QUIC.

Cette section résume certains des aspects de sécurité les plus importants spécifiques à l'intégration TLS, bien qu'il existe de nombreux détails pertinents à la sécurité dans le reste du document.

9.1. Traçabilité des sessions (Session Linkability)​

L'utilisation de tickets de session TLS permet aux serveurs et éventuellement à d'autres entités de corréler les connexions établies par le même client ; voir la section 4.5 pour plus de détails.

9.2. Attaques par rejeu avec 0-RTT (Replay Attacks with 0-RTT)​

Comme décrit dans la section 8 de [TLS13], l'utilisation de données précoces TLS s'accompagne d'une exposition aux attaques par rejeu. L'utilisation de 0-RTT dans QUIC est également vulnérable aux attaques par rejeu.

Les points d'extrémité DOIVENT (MUST) implémenter et utiliser les protections contre le rejeu décrites dans [TLS13], mais il est reconnu que ces protections sont imparfaites. Par conséquent, une considération supplémentaire du risque de rejeu est nécessaire.

QUIC n'est pas vulnérable aux attaques par rejeu, sauf via les informations du protocole d'application qu'il pourrait transporter. La gestion de l'état du protocole QUIC basée sur les types de trames définis dans [QUIC-TRANSPORT] n'est pas vulnérable au rejeu.

La désactivation complète de 0-RTT est la défense la plus efficace contre les attaques par rejeu.

Les extensions QUIC DOIVENT (MUST) décrire comment les attaques par rejeu affectent leur fonctionnement ou interdire l'utilisation de l'extension dans 0-RTT. Les protocoles d'application DOIVENT (MUST) soit interdire l'utilisation d'extensions portant une sémantique d'application dans 0-RTT, soit fournir des stratégies d'atténuation du rejeu.

9.3. Atténuation des attaques par réflexion de paquets​

Un petit ClientHello qui entraîne un gros bloc de messages de handshake d'un serveur peut être utilisé dans des attaques par réflexion de paquets pour amplifier le trafic généré par un attaquant.

QUIC comprend trois défenses contre cette attaque. Premièrement, le paquet contenant un ClientHello DOIT (MUST) être rempli à une taille minimale. Deuxièmement, s'il répond à une adresse source non vérifiée, le serveur est interdit d'envoyer plus de trois fois plus d'octets que le nombre d'octets qu'il a reçu (voir la section 8.1 de [QUIC-TRANSPORT]). Enfin, étant donné que les accusés de réception des paquets de handshake sont authentifiés, un attaquant aveugle ne peut pas les falsifier. Ensemble, ces défenses limitent le niveau d'amplification.

9.4. Diversité des clés (Key Diversity)​

Lors de l'utilisation de TLS, le calendrier central des clés de TLS est utilisé. En conséquence de l'intégration des messages de handshake TLS dans le calcul des secrets, l'inclusion de l'extension des paramètres de transport QUIC garantit que les clés de handshake et 1-RTT ne sont pas les mêmes que celles qui pourraient être produites par un serveur exécutant TLS sur TCP.

Les clés de protection des paquets QUIC et les IV sont dérivés en utilisant un label différent de celui des clés équivalentes dans TLS.

Pour préserver cette séparation, une nouvelle version de QUIC DEVRAIT (SHOULD) définir de nouveaux labels pour la dérivation de clés pour la clé et l'IV de protection de paquet, ainsi que les clés de protection d'en-tête. Cette version de QUIC utilise la chaîne "quic". D'autres versions peuvent utiliser un label spécifique à la version à la place de cette chaîne.

9.5. Canaux latéraux de timing de protection d'en-tête​

Un attaquant pourrait deviner des valeurs pour les numéros de paquet ou la phase de clé et demander au point d'extrémité de confirmer les suppositions via des canaux latéraux de timing.

Pour que l'authentification soit exempte de canaux latéraux, l'ensemble du processus de suppression de la protection d'en-tête, de récupération du numéro de paquet et de suppression de la protection de paquet DOIT (MUST) être appliqué ensemble sans timing ni autres canaux latéraux.

9.6. Aléatoire (Randomness)​

QUIC dépend de la capacité des points d'extrémité à générer des nombres aléatoires sécurisés, à la fois directement pour les valeurs de protocole telles que l'ID de connexion, et de manière transitive via TLS. Voir [RFC4086] pour des conseils sur la génération de nombres aléatoires sécurisés.

10. Considérations IANA (IANA Considerations)​

L'IANA a enregistré un point de code de 57 (ou 0x39) pour l'extension quic_transport_parameters (définie dans la section 8.2) dans le registre "TLS ExtensionType Values" [TLS-REGISTRIES].

La colonne Recommandé pour cette extension est marquée Oui. La colonne TLS 1.3 inclut CH (ClientHello) et EE (EncryptedExtensions).

ValeurNom de l'extensionTLS 1.3RecommandéRéférence
57quic_transport_parametersCH, EEOCe document

Tableau 2: Entrée du registre TLS ExtensionType Values

11. Références (References)​

11.1. Références normatives (Normative References)​

Cette section contient les références normatives citées dans RFC 9001. Pour la liste complète, veuillez consulter le texte original en anglais.

Références principales :

  • [TLS13] - RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
  • [QUIC-TRANSPORT] - RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
  • [QUIC-RECOVERY] - RFC 9002: QUIC Loss Detection and Congestion Control
  • [RFC2119] - RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
  • [RFC8174] - RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

11.2. Références informatives (Informative References)​

Cette section contient les références informatives citées dans RFC 9001.

Références principales :

  • [AEBounds] - Limits on Authenticated Encryption Use in TLS
  • [ALPN] - RFC 7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
  • [QUIC-HTTP] - RFC 9114: HTTP/3
  • [NAN] - Nonces Are Noticed: AEAD Revisited

Pour la liste complète des références, veuillez consulter le RFC 9001 officiel : https://www.rfc-editor.org/rfc/rfc9001.html

Annexe A. Exemple de protection de paquet (Sample Packet Protection)​

Cette annexe montre des exemples de processus de protection de paquet. Les exemples montrent un handshake incluant un paquet Initial du client et un paquet Initial du serveur, suivis par des paquets Handshake du client et du serveur.

A.1. Clés (Keys)​

Les secrets et clés calculés dans ces exemples sont affichés avec les valeurs en hexadécimal.

A.2. Paquet Initial du client (Client Initial)​

Le client envoie un paquet Initial. Les secrets et clés pour protéger ce paquet sont dérivés du Destination Connection ID 0x8394c8f03e515708.

initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a

initial_secret = HKDF-Extract(initial_salt, client_dst_connection_id)
               = 0x7db5df06e7a69e432496adedb00851923595221596ae2ae9fb8115c1e9ed0a44

client_initial_secret
    = HKDF-Expand-Label(initial_secret,
                       "client in", "",
                       Hash.length)
    = 0x00553221e68c7e38be14fa1ab2e9def61c0ca9f9a9e0e4ad5f8b3c2d4c76c7ee

server_initial_secret
    = HKDF-Expand-Label(initial_secret,
                       "server in", "",
                       Hash.length)
    = 0x0018b6cbcf39d62e84bd8e9ab8bc3e1b8c8b18d9c3c3e2d0e1af3e0d6c5c4c3c

Le paquet envoyé par le client est :

c300000001088394c8f03e5157080000449e00000002

Les secrets sont ensuite étendus pour dériver les clés de chiffrement et les IV qui protègent les paquets Initial.

A.3. Paquet Initial du serveur (Server Initial)​

Le serveur envoie le paquet Initial suivant en réponse :

c1000000010800000449e7d0c5db0e

A.4. Paquets Handshake du client (Client Handshake)​

Après réception du paquet Initial du serveur, le client dérive de nouvelles clés de protection de paquet pour le niveau de chiffrement Handshake.

A.5. Paquets Handshake du serveur (Server Handshake)​

Le serveur envoie ensuite des données de handshake chiffrées avec les clés de niveau Handshake.

Remarque : Les exemples complets avec toutes les valeurs intermédiaires et les calculs cryptographiques détaillés sont disponibles dans le texte original du RFC 9001, section Annexe A.

Annexe B. Analyse des algorithmes AEAD (AEAD Algorithm Analysis)​

Cette annexe inclut une analyse des limites d'utilisation des algorithmes AEAD utilisés dans QUIC. Cette analyse a été utilisée pour dériver les limites documentées dans la section 6.6.

B.1. Analyse de AES-GCM (AES-GCM Analysis)​

Le mode Galois/Counter Mode (GCM) d'AES fournit à la fois la confidentialité et l'intégrité. L'analyse dans [AEBounds] établit que l'algorithme sous-jacent AES est sûr contre les attaques choisies en texte clair.

L'analyse établit que la fuite d'information maximum est limitée par :

(ℓ × q)² / 2^129

où :

  • ℓ est la longueur maximale du texte chiffré en blocs de 128 bits
  • q est le nombre de textes chiffrés

AES-128-GCM​

Pour AEAD_AES_128_GCM, la limite de confidentialité est calculée comme suit :

Limite de confidentialité : 2^23 paquets

Cette limite est dérivée en supposant une taille de paquet maximale de 2^11 octets (2048 octets), ce qui donne une longueur maximum de 2^7 blocs par paquet.

Limite d'intégrité : 2^52 tentatives d'authentification échouées

Cette limite garantit que la probabilité qu'un attaquant forge avec succès un paquet reste négligeable.

AES-256-GCM​

Pour AEAD_AES_256_GCM, les limites sont similaires à AES-128-GCM car les propriétés de GCM sont indépendantes de la taille de clé AES :

Limite de confidentialité : 2^23 paquets
Limite d'intégrité : 2^52 tentatives d'authentification

B.2. Analyse de ChaCha20-Poly1305 (ChaCha20-Poly1305 Analysis)​

ChaCha20-Poly1305 combine le chiffrement de flux ChaCha20 avec l'authentificateur Poly1305. L'analyse dans [NAN] et les considérations de sécurité dans [RFC8439] établissent les limites suivantes.

Limite de confidentialité : 2^23 paquets

Le risque de collision de nonce devient significatif après ce nombre de paquets.

Limite d'intégrité : 2^36 tentatives de falsification

Cette limite est plus conservatrice que celle d'AES-GCM en raison des propriétés différentes de Poly1305.

B.3. Analyse de AES-CCM (AES-CCM Analysis)​

Counter with CBC-MAC (CCM) est un mode d'opération pour AES qui combine le mode compteur (CTR) pour le chiffrement avec CBC-MAC pour l'authentification.

AES-128-CCM​

Pour AEAD_AES_128_CCM, les limites sont dérivées de [CCM-ANALYSIS] :

Limite de confidentialité : 2^21.5 paquets (approximativement 2.9 millions de paquets)

Cette limite plus restrictive reflète les contraintes du mode CCM.

Limite d'intégrité : 2^23.5 tentatives d'authentification (approximativement 11.8 millions de tentatives)

B.4. Résumé des limites (Summary of Limits)​

Le tableau suivant résume les limites pour tous les algorithmes AEAD pris en charge :

Algorithme AEADLimite de confidentialitéLimite d'intégrité
AEAD_AES_128_GCM2^23 paquets2^52 tentatives
AEAD_AES_256_GCM2^23 paquets2^52 tentatives
AEAD_CHACHA20_POLY13052^23 paquets2^36 tentatives
AEAD_AES_128_CCM2^21.5 paquets2^23.5 tentatives

Tableau B.1 : Limites d'utilisation AEAD

B.5. Implications pour les implémentations​

Les implémentations DOIVENT (MUST) suivre ces limites lors de l'utilisation de ces algorithmes avec QUIC. Lorsqu'une limite est atteinte :

  1. Pour la limite de confidentialité : Initier une mise à jour de clé (voir section 6) avant d'atteindre la limite
  2. Pour la limite d'intégrité : Compter toutes les tentatives de déchiffrement échouées et fermer la connexion si la limite est atteinte

Références pour cette annexe :

  • [AEBounds] : Limits on Authenticated Encryption Use in TLS
  • [NAN] : Nonces Are Noticed: AEAD Revisited
  • [RFC8439] : ChaCha20 and Poly1305 for IETF Protocols
  • [CCM-ANALYSIS] : Analytical studies of CCM mode