Résumé

  • La révision du 27 octobre d’un projet individuel sur TLS 1.3 sépare la négociation du KDF XOF de celle de la suite cryptographique. Elle ajoute DTLS et les authentificateurs exportés, exclus de la version de juillet.
  • Un authentificateur exécuté hors de la bibliothèque TLS doit recevoir l’identifiant du KDF choisi, ou l’indication du calendrier classique, ainsi que le type de connexion. L’API qui ne livre que des octets exportés ne transmet pas cette décision.

Un service renouvelle sa bibliothèque TLS. La poignée de main réussit. Puis une application distincte demande une preuve d’identité après la connexion. Si cette application ne voit que les octets fournis par TLS-Exporter, elle ignore le calcul qui leur a donné un sens. C’est le point précis que la révision 01 du projet XOF vient inscrire dans la spécification.

Le projet ajoute schedule_profile : la suite TLS 1.3 garde son choix de chiffrement, tandis qu’une extension peut choisir SHAKE256 ou TurboSHAKE256 pour le calendrier entier des clés et l’empreinte de la conversation. Sans extension, le calcul habituel de TLS 1.3 utilise le hachage de la suite. Avec un KDF XOF, ce hachage reste dans le nom de la suite mais ne gouverne plus le calendrier. Un inventaire qui ne lit que ce nom regarde l’étiquette et manque le moteur.

La nouveauté de cette version se lit en comparant les deux textes. La révision 00 laissait DTLS 1.3 et les authentificateurs exportés hors de son champ. La révision 01 propose de mettre à jour quatre RFC et détaille ces deux usages. RFC 9261 permet à l’un ou l’autre pair de s’authentifier après la poignée de main. Son calcul d’origine suit le hachage de la suite cryptographique. Le nouveau paragraphe 14.2 lui substitue, pour une connexion XOF, le TranscriptHash de 64 octets, les sorties de l’exportateur et le MAC du KDF sélectionné.

Cette règle traverse une frontière de logiciel. Si le composant chargé de l’authentificateur vit hors de la bibliothèque TLS, il doit recevoir l’identifiant du KDF, ou l’annonce qu’aucun nouveau KDF n’a été négocié. Il doit aussi savoir s’il travaille en TLS ou en DTLS : ce dernier emploie une autre étiquette de calendrier. L’interface TLS-Exporter(label, context, length) n’indique ni l’un ni l’autre. Le projet avertit qu’une mise à jour limitée à la bibliothèque peut laisser l’application produire des preuves incompatibles.

La séparation vaut aussi pour les secrets repris. RFC 9258 fournit le registre d’identifiants KDF utilisé pour l’importation des PSK ; le projet lie les PSK et les tickets de session au KDF effectif. Quant aux signatures des certificats, elles suivent encore leur propre négociation. Changer le calendrier des clés ne retire donc pas automatiquement SHA-2 de toute l’authentification. Le Datatracker classe ce texte parmi les projets individuels au stade I-D Exists. Il manque un essai d’interopérabilité public où un authentificateur externe vérifie la preuve après sélection d’un KDF XOF ; un tel essai fixerait le résultat pratique.