4. Recommandations : Suites de chiffrement

TLS 1.2 offrait une flexibilité considérable dans la sélection des suites de chiffrement. Malheureusement, la sécurité de certaines de ces suites de chiffrement s'est dégradée au fil du temps au point que certaines sont connues pour être non sécurisées (c'est une des raisons pour lesquelles TLS 1.3 a restreint cette flexibilité). Une configuration incorrecte d'un serveur conduit à une absence de sécurité ou à une sécurité réduite. Cette section comprend des recommandations sur la sélection et la négociation des suites de chiffrement.

4.1. Directives générales

Les algorithmes cryptographiques s'affaiblissent avec le temps à mesure que la cryptanalyse s'améliore : les algorithmes qui étaient autrefois considérés comme forts deviennent faibles. Par conséquent, les suites de chiffrement utilisant des algorithmes faibles doivent être progressivement supprimées et remplacées par des suites de chiffrement plus sécurisées. Cela permet de garantir que les propriétés de sécurité souhaitées sont toujours valables. SSL/TLS existe depuis plus de 20 ans et bon nombre des suites de chiffrement qui ont été recommandées dans diverses versions de SSL/TLS sont maintenant considérées comme faibles ou du moins pas aussi fortes que souhaité. Par conséquent, cette section modernise les recommandations concernant la sélection des suites de chiffrement.

• Les implémentations NE DOIVENT PAS négocier les suites de chiffrement avec un chiffrement NULL.

  Raison : Les suites de chiffrement NULL ne chiffrent pas le trafic et ne fournissent donc aucun service de confidentialité. Toute entité du réseau ayant accès à la connexion peut voir le texte clair du contenu échangé par le client et le serveur. Néanmoins, ce document ne décourage pas les logiciels d'implémenter des suites de chiffrement NULL, car elles peuvent être utiles pour les tests et le débogage.

• Les implémentations NE DOIVENT PAS négocier les suites de chiffrement RC4.

  Raison : Le chiffrement de flux RC4 présente diverses faiblesses cryptographiques, comme documenté dans [RFC7465]. Notez que DTLS interdit déjà spécifiquement l'utilisation de RC4.

• Les implémentations NE DOIVENT PAS négocier de suites de chiffrement offrant moins de 112 bits de sécurité, y compris le chiffrement dit "de niveau export" (qui fournit 40 ou 56 bits de sécurité).

  Raison : Sur la base de [RFC3766], au moins 112 bits de sécurité sont nécessaires. La sécurité de 40 bits et 56 bits (que l'on trouve dans les dits "chiffrements d'exportation") est considérée comme non sécurisée aujourd'hui.

• Les implémentations NE DEVRAIENT PAS négocier de suites de chiffrement utilisant des algorithmes offrant moins de 128 bits de sécurité.

  Raison : Les suites de chiffrement qui offrent 112 bits ou plus mais moins de 128 bits de sécurité ne sont pas considérées comme faibles à l'heure actuelle ; cependant, on s'attend à ce que leur durée de vie utile soit suffisamment courte pour justifier la prise en charge de suites de chiffrement plus fortes à ce stade. On s'attend à ce que les chiffrements de 128 bits restent sécurisés pendant au moins plusieurs années et les chiffrements de 256 bits jusqu'à la prochaine percée technologique fondamentale. Notez que, en raison des attaques dites "meet-in-the-middle" [Multiple-Encryption], certaines anciennes suites de chiffrement (par exemple, Triple DES (3DES) de 168 bits) ont une longueur de clé effective inférieure à leur longueur de clé nominale (112 bits dans le cas de 3DES). De telles suites de chiffrement devraient être évaluées en fonction de leur longueur de clé effective.

• Les implémentations NE DEVRAIENT PAS négocier de suites de chiffrement basées sur le transport de clé RSA, alias "RSA statique".

  Raison : Ces suites de chiffrement, qui ont des valeurs attribuées commençant par la chaîne "TLS_RSA_WITH_*", présentent plusieurs inconvénients, notamment le fait qu'elles ne prennent pas en charge la confidentialité persistante.

• Les implémentations NE DEVRAIENT PAS négocier de suites de chiffrement basées sur un accord de clé Diffie-Hellman (DH) à champ fini non éphémère (statique). De même, les implémentations NE DEVRAIENT PAS négocier un accord de clé Elliptic Curve DH non éphémère.

  Raison : Les premières suites de chiffrement, qui ont des valeurs attribuées préfixées par "TLS_DH_", présentent plusieurs inconvénients, notamment le fait qu'elles ne prennent pas en charge la confidentialité persistante. Les dernières ("TLS_ECDH_") manquent également de confidentialité persistante et sont sujettes à des attaques de courbe invalide [Jager2015].

• Les implémentations DOIVENT prendre en charge et préférer négocier des suites de chiffrement offrant une confidentialité persistante. Cependant, les implémentations TLS 1.2 NE DEVRAIENT PAS négocier de suites de chiffrement basées sur un accord de clé Diffie-Hellman à champ fini éphémère (c'est-à-dire les suites "TLS_DHE_*"). Ceci est justifié par la fragilité connue de la construction (voir [RACCOON]) et la limitation autour de la négociation, y compris l'utilisation de [RFC7919], qui a connu une adoption très limitée.

  Raison : La confidentialité persistante (parfois appelée "confidentialité persistante parfaite") empêche la récupération d'informations qui ont été chiffrées avec d'anciennes clés de session, limitant ainsi la quantité de données pouvant être déchiffrées dans le passé lorsqu'une attaque réussit. Voir les sections 7.3 et 7.4 pour une discussion détaillée.

4.2. Suites de chiffrement pour TLS 1.2

Compte tenu des considérations précédentes, l'implémentation et le déploiement des suites de chiffrement suivantes sont RECOMMANDÉS :

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Comme il s'agit d'algorithmes de chiffrement authentifié avec données associées (AEAD) [RFC5116], ces suites de chiffrement sont prises en charge uniquement dans TLS 1.2 et non dans les versions antérieures du protocole.

En général, pour préférer ces suites, l'ordre des suites doit être explicitement configuré dans le logiciel serveur. Il serait idéal que les implémentations de logiciels serveurs préfèrent ces suites par défaut.

Certains appareils disposent d'un support matériel pour AES Counter Mode with CBC-MAC (AES-CCM) mais pas pour AES Galois/Counter Mode (AES-GCM), ils ne sont donc pas en mesure de suivre les recommandations précédentes concernant les suites de chiffrement. Il existe même des appareils qui ne prennent pas du tout en charge la cryptographie à clé publique, mais ceux-ci sont entièrement hors de portée.

Une suite de chiffrement qui fonctionne en mode CBC (cipher block chaining) (par exemple, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) NE DEVRAIT PAS être utilisée à moins que l'extension encrypt_then_mac [RFC7366] ne soit également négociée avec succès. Cette exigence s'applique aux implémentations client et serveur.

Lors de l'utilisation de signatures ECDSA pour l'authentification des pairs TLS, il est RECOMMANDÉ que les implémentations utilisent la courbe NIST P-256. De plus, pour éviter les nonces prévisibles ou répétés (qui pourraient révéler la clé de signature à long terme), il est RECOMMANDÉ que les implémentations implémentent "ECDSA déterministe" tel que spécifié dans [RFC6979] et conformément aux recommandations de [RFC8446].

Notez que les implémentations de "ECDSA déterministe" peuvent être vulnérables à certaines attaques par canal auxiliaire et par injection de fautes précisément en raison de leur déterminisme. Bien que la plupart des attaques par injection de fautes décrites dans la littérature supposent un accès physique à l'appareil (et sont donc plus pertinentes dans les déploiements de l'Internet des objets (IoT) avec une sécurité physique faible ou inexistante), certaines peuvent être menées à distance [Poddebniak2017], par exemple sous forme de variantes Rowhammer [Kim2014]. Dans les déploiements où les attaques par canal auxiliaire et par injection de fautes sont une préoccupation, des stratégies d'implémentation combinant à la fois aléatoire et déterminisme (par exemple, comme décrit dans [CFRG-DET-SIGS]) peuvent être utilisées pour éviter le risque d'extraction réussie de la clé de signature.

4.2.1. Détails d'implémentation

Les clients DEVRAIENT inclure TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 comme première proposition à tout serveur. Les serveurs DOIVENT préférer cette suite de chiffrement aux suites de chiffrement plus faibles chaque fois qu'elle est proposée, même si ce n'est pas la première proposition. Les clients sont bien sûr libres de proposer des suites de chiffrement plus fortes, par exemple en utilisant AES-256 ; lorsqu'ils le font, le serveur DEVRAIT préférer la suite de chiffrement plus forte à moins qu'il n'y ait des raisons impérieuses (par exemple, des performances sérieusement dégradées) de choisir autrement.

La version précédente des recommandations TLS [RFC7525] autorisait implicitement l'ancienne suite de chiffrement obligatoire à implémenter de la RFC 5246, TLS_RSA_WITH_AES_128_CBC_SHA. Au moment de la rédaction, cette suite de chiffrement n'offre pas d'interopérabilité supplémentaire, sauf avec des clients très anciens. Comme pour les autres suites de chiffrement qui n'offrent pas de confidentialité persistante, les implémentations NE DEVRAIENT PAS prendre en charge cette suite de chiffrement. D'autres protocoles d'application spécifient d'autres suites de chiffrement comme obligatoires à implémenter (MTI).

[RFC8422] permet aux clients et aux serveurs de négocier les paramètres ECDH (courbes). Les clients et les serveurs DEVRAIENT inclure l'extension "Supported Elliptic Curves Extension" [RFC8422]. Les clients et les serveurs DEVRAIENT prendre en charge les courbes NIST P-256 (secp256r1) [RFC8422] et X25519 (x25519) [RFC7748]. Notez que [RFC8422] déprécie tout sauf le format de point non compressé. Par conséquent, si le client envoie une extension ec_point_formats, la ECPointFormatList DOIT contenir un seul élément, "uncompressed".

4.3. Suites de chiffrement pour TLS 1.3

Ce document ne spécifie aucune suite de chiffrement pour TLS 1.3. Les lecteurs sont renvoyés à la section 9.1 de [RFC8446] pour les recommandations sur les suites de chiffrement.

4.4. Limites d'utilisation des clés

Tous les chiffrements ont une limite supérieure sur la quantité de trafic qui peut être protégée de manière sécurisée avec une clé donnée. Dans le cas des suites de chiffrement AEAD, deux limites distinctes sont maintenues pour chaque clé :

1. Limite de confidentialité (CL), c'est-à-dire le nombre d'enregistrements pouvant être chiffrés.

2. Limite d'intégrité (IL), c'est-à-dire le nombre d'enregistrements autorisés à échouer l'authentification.

Cette dernière s'applique à DTLS (et aussi à QUIC) mais pas à TLS lui-même, car les connexions TLS sont interrompues dès le premier échec de déchiffrement.

Lorsqu'un expéditeur approche de la CL, l'implémentation DEVRAIT initier un nouveau handshake (dans TLS 1.3, cela peut être réalisé en envoyant un message KeyUpdate sur la session établie) pour faire tourner la clé de session. Lorsqu'un récepteur a atteint l'IL, l'implémentation DEVRAIT fermer la connexion. Bien que ces recommandations soient une bonne pratique, les implémenteurs doivent être conscients qu'il n'est pas toujours facile de les accomplir dans les protocoles construits au-dessus de TLS/DTLS sans introduire de coordination entre les frontières des couches. Voir la section 6 de [RFC9001] pour un exemple de la coopération qui a été nécessaire dans QUIC entre les couches crypto et transport pour prendre en charge les mises à jour de clés. Notez qu'en général, les protocoles d'application pourraient ne pas être en mesure d'émuler cette méthode étant donné leur interaction plus contrainte avec TLS/DTLS. En raison de ces complexités, ces recommandations ne sont pas obligatoires.

Pour toutes les suites de chiffrement TLS 1.3, les lecteurs sont renvoyés à la section 5.5 de [RFC8446] pour les valeurs de CL et IL. Pour toutes les suites de chiffrement DTLS 1.3, les lecteurs sont renvoyés à la section 4.5.3 de [RFC9147].

Pour toutes les suites de chiffrement AES-GCM recommandées pour TLS 1.2 et DTLS 1.2 dans ce document, CL peut être dérivé en insérant les paramètres correspondants dans les inégalités de la section 6.1 de [AEAD-LIMITS] qui s'appliquent aux nonces aléatoires partiellement implicites, c'est-à-dire la construction de nonce utilisée dans TLS 1.2. Bien que les chiffres obtenus soient légèrement supérieurs à ceux de TLS 1.3, il est RECOMMANDÉ d'utiliser la même limite de 2^24,5 enregistrements pour les deux versions.

Pour toutes les suites de chiffrement AES-GCM recommandées pour DTLS 1.2, IL (obtenu à partir des mêmes inégalités référencées ci-dessus) est de 2^28.

4.5. Longueur de clé publique

Lors de l'utilisation des suites de chiffrement recommandées dans ce document, deux clés publiques sont normalement utilisées dans le handshake TLS : une pour l'accord de clé Diffie-Hellman et une pour l'authentification du serveur. Lorsqu'un certificat client est utilisé, une troisième clé publique est ajoutée.

Avec un échange de clés basé sur des groupes Diffie-Hellman à exponentielle modulaire (MODP) (suites de chiffrement "DHE"), des longueurs de clé DH d'au moins 2048 bits sont REQUISES.

Raison : Pour diverses raisons, en pratique, les clés DH sont généralement générées dans des longueurs qui sont des puissances de deux (par exemple, 2^10 = 1024 bits, 2^11 = 2048 bits, 2^12 = 4096 bits). Parce qu'une clé DH de 1228 bits ne serait à peu près équivalente qu'à une clé symétrique de 80 bits [RFC3766], il est préférable d'utiliser des clés plus longues que cela pour la famille de suites de chiffrement "DHE". Une clé DH de 1926 bits serait à peu près équivalente à une clé symétrique de 100 bits [RFC3766]. Une clé DH de 2048 bits (équivalente à une clé symétrique de 112 bits) est le minimum autorisé par la dernière révision de [NIST.SP.800-56A] au moment de la rédaction (voir en particulier l'annexe D de ce document).

Comme indiqué dans [RFC3766], la correction pour l'émergence de la machine TWIRL (The Weizmann Institute Relation Locator) [TWIRL] impliquerait que les clés DH de 1024 bits donnent environ 61 bits de force équivalente et qu'une clé DH de 2048 bits donnerait environ 92 bits de force équivalente. L'attaque Logjam [Logjam] démontre en outre que les paramètres Diffie-Hellman de 1024 bits doivent être évités.

En ce qui concerne les clés ECDH, les implémenteurs sont renvoyés au registre IANA "TLS Supported Groups" (anciennement connu sous le nom de "EC Named Curve Registry") au sein du registre "Transport Layer Security (TLS) Parameters" [IANA_TLS] et en particulier aux groupes "recommended". Les courbes de moins de 224 bits NE DOIVENT PAS être utilisées. Cette recommandation est conforme à la dernière révision de [NIST.SP.800-56A].

Lors de l'utilisation de RSA, les serveurs DOIVENT s'authentifier à l'aide de certificats avec un module d'au moins 2048 bits pour la clé publique. De plus, l'utilisation de l'algorithme de hachage SHA-256 est RECOMMANDÉE et SHA-1 ou MD5 NE DOIVENT PAS être utilisés [RFC9155] (pour plus de détails, voir aussi [CAB-Baseline], dont la version actuelle au moment de la rédaction est 1.8.4). Les clients DOIVENT indiquer aux serveurs qu'ils demandent SHA-256 en utilisant l'extension "Signature Algorithms" définie dans TLS 1.2. Pour TLS 1.3, la même exigence est déjà spécifiée par [RFC8446].

4.6. HMAC tronqué

Les implémentations NE DOIVENT PAS utiliser l'extension Truncated HMAC, définie dans la section 7 de [RFC6066].

Raison : L'extension ne s'applique pas aux suites de chiffrement AEAD recommandées ci-dessus. Cependant, elle s'applique à la plupart des autres suites de chiffrement TLS. Son utilisation s'est avérée non sécurisée dans [PatersonRS11].