Résumé

  • La RFC 3268 n’a pas refondu la négociation de TLS : elle a ajouté douze identifiants AES au menu existant, soit six familles d’échange et d’authentification pour deux tailles de clé.
  • AES-256 ne prouvait à lui seul ni l’identité du pair ni la confidentialité persistante ; ces propriétés dépendaient du choix de poignée de main et de sa mise en œuvre.

Une nouvelle primitive dans un ancien menu

La normalisation d’AES ne suffisait pas à en faire une option interopérable dans TLS. Client et serveur devaient pouvoir désigner le même ensemble de paramètres. TLS 1.0 disposait déjà de ce mécanisme : le client énumérait des suites dans ClientHello, puis le serveur en choisissait une qu’il prenait en charge. La RFC 2246 décrivait chaque suite comme une combinaison comprenant échange de clés, chiffrement des données et algorithme d’authentification des messages.

Publiée en juin 2002, la RFC 3268 a réutilisé cette enveloppe. AES en mode CBC avec HMAC-SHA-1 arrivait sous six variantes de poignée de main : RSA, DH statique avec certificats DSS ou RSA, DHE éphémère signé par DSS ou RSA, et DH anonyme. Chaque variante existait avec une clé AES de 128 ou 256 bits. Six fois deux : douze nouveaux identifiants.

Le choix du chiffrement n’effaçait pas les différences du protocole. RSA, DH authentifié et DH anonyme ne devenaient pas équivalents grâce à AES. DHE pouvait apporter une confidentialité persistante, à condition d’utiliser une clé éphémère fraîche, de la détruire correctement et de disposer d’un générateur aléatoire robuste. DH anonyme n’authentifiait pas le pair et restait exposé à l’interception, sauf si une autre méthode liait les parties au même message Finished de TLS. La longueur de clé AES ne répondait à aucune de ces questions.

AES permet des clés de 128, 192 ou 256 bits ; la RFC n’a retenu que 128 et 256 pour éviter une prolifération de suites. Les douze utilisaient le bloc AES de 128 bits : une clé plus longue n’agrandissait pas le bloc. CBC et SHA-1 dans HMAC faisaient également partie du paquet. Le nom « AES » ne décrivait donc qu’un élément de la combinaison.

La compatibilité a élargi le registre

La RFC signalait que les suites DHE alors disponibles reposaient surtout sur triple-DES, avec des variantes d’exportation aux clés jugées insuffisantes. AES pouvait ainsi être ajouté sans remplacer le ClientHello ni la négociation de TLS 1.0. Cette continuité avait un coût : chaque combinaison obtenait son propre nom, son code, ses règles de préférence et ses obligations d’implémentation.

La présence d’une suite au registre ne prouve ni son adoption, ni sa préférence, ni sa négociation effective. Les architectures ultérieures rendent la séparation plus visible : TLS 1.2 associait encore souvent plusieurs choix dans un identifiant ; TLS 1.3 réserve la suite au couple AEAD/hachage et négocie groupes d’échange et algorithmes de signature séparément. La RFC 3268 raconte donc aussi où TLS plaçait ses décisions.

Son intérêt historique tient à cette surface de contrôle. Taille de clé, chiffrement, authentification, échange de clés et construction du record ne sont pas des garanties interchangeables. Une suite est un paquet négocié ; isoler un mot de son nom revient à prendre une pièce pour le jugement de toute la connexion.

Sources