4.2. Suites de chiffrement recommandées
Compte tenu des considérations précédentes, l'implémentation et le déploiement des suites de chiffrement suivantes sont RECOMMANDÉS:
-
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
-
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
-
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Ces suites de chiffrement ne sont supportées que dans TLS 1.2 car ce sont des algorithmes de chiffrement authentifié (AEAD) [RFC5116].
Typiquement, afin de préférer ces suites, l'ordre des suites doit être explicitement configuré dans le logiciel serveur. (Voir [BETTERCRYPTO] pour des directives de déploiement utiles, mais notez que ses recommandations diffèrent du document actuel sur certains détails.) Il serait idéal que les implémentations de logiciels serveur préfèrent ces suites par défaut.
Certains dispositifs ont un support matériel pour AES-CCM mais pas pour AES-GCM, ils sont donc incapables de suivre les recommandations précédentes concernant les suites de chiffrement. Il existe même des dispositifs qui ne supportent pas du tout la cryptographie à clé publique, mais ils sont complètement hors du champ d'application.
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, à moins qu'ils n'aient une connaissance préalable que le serveur ne peut pas répondre à un message client_hello TLS 1.2.
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 d'offrir des suites de chiffrement plus robustes, par exemple utilisant AES-256; lorsqu'ils le font, le serveur DEVRAIT préférer la suite de chiffrement plus robuste à moins qu'il n'y ait des raisons impérieuses (par exemple, une performance sérieusement dégradée) de choisir autrement.
Ce document ne modifie pas la ou les suites de chiffrement TLS obligatoires à implémenter prescrites par TLS. Pour maximiser l'interopérabilité, RFC 5246 impose l'implémentation de la suite de chiffrement TLS_RSA_WITH_AES_128_CBC_SHA, qui est significativement plus faible que les suites de chiffrement recommandées ici. (Le mode GCM ne souffre pas de la même faiblesse, causée par l'ordre MAC-puis-Chiffrer dans TLS [Krawczyk2001], puisqu'il utilise un mode de fonctionnement AEAD.) Les implémenteurs devraient considérer le gain d'interopérabilité par rapport à la perte de sécurité lors du déploiement de la suite de chiffrement TLS_RSA_WITH_AES_128_CBC_SHA. D'autres protocoles applicatifs spécifient d'autres suites de chiffrement comme obligatoires à implémenter (MTI).
Notez que certains profils de TLS 1.2 utilisent différentes suites de chiffrement. Par exemple, [RFC6460] définit un profil qui utilise les suites de chiffrement TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 et TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
[RFC4492] 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" [RFC4492]. Pour l'interopérabilité, les clients et les serveurs DEVRAIENT supporter la courbe NIST P-256 (secp256r1) [RFC4492]. De plus, les clients DEVRAIENT envoyer une extension ec_point_formats avec un seul élément, "uncompressed".