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.