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.