Résumé

  • Le 3 septembre 2026, l’IESG a approuvé la révision 10 de ML-KEM Post-Quantum Key Agreement for TLS 1.3 pour publication comme RFC Informational. Aucun numéro de RFC n’était encore attribué dans le dossier examiné.
  • MLKEM512, MLKEM768 et MLKEM1024 obtiennent une grammaire TLS et des numéros, avec DTLS-OK=Y mais Recommended=N. Selon le RFC 9847, N ne signifie ni recommandé, ni défectueux, ni découragé : l’exploitant doit produire sa propre décision justifiée.

Le tableau IANA raconte ici une histoire plus précise que le mot « approuvé ». Trois lignes portent les valeurs 512, 513 et 514. Elles nomment MLKEM512, MLKEM768 et MLKEM1024. La compatibilité DTLS vaut Y. La recommandation, elle, vaut N.

Cette combinaison n’est pas une incohérence. L’IESG a autorisé le texte à avancer vers une publication Informational. Le texte définit un mécanisme interopérable. Le registre fournit des coordonnées communes. Aucun de ces actes ne constitue, par lui-même, un consensus de l’IETF sur l’aptitude générale au déploiement.

La mécanique est pourtant complète. ML-KEM sépare trois opérations. KeyGen crée une clé publique d’encapsulation et une clé secrète de décapsulation. Encaps utilise la clé publique pour produire un chiffré et un secret partagé. Decaps récupère le même secret à partir de la clé secrète et du chiffré.

La révision 10 place cet échange dans les extensions TLS 1.3 existantes. Le client annonce les groupes pris en charge et met sa clé publique ML-KEM dans key_share. Le serveur choisit un groupe et renvoie le chiffré dans son propre key_share. Le secret de 32 octets alimente ensuite le calendrier de clés TLS à la place du secret (EC)DHE.

Les tailles changent fortement selon le groupe. ML-KEM-512 transporte une clé publique de 800 octets et un chiffré de 768 octets. ML-KEM-768 passe à 1 184 et 1 088 octets. ML-KEM-1024 utilise 1 568 octets pour chacun. Ces nombres décrivent les entrées du protocole ; ils ne démontrent ni latence, ni fragmentation, ni capacité sur un réseau réel.

Le texte impose aussi des contrôles. Le serveur vérifie la clé d’encapsulation selon FIPS 203 et répond illegal_parameter en cas d’échec. Le client vérifie la longueur du chiffré pour le paramètre choisi. Un autre échec de décapsulation produit internal_error. La transcription TLS couvre les champs de partage de clé et engage ainsi la clé et le chiffré dans le handshake.

Un format exact ne garantit pas une réalisation exacte. La réutilisation de l’aléa d’encapsulation, et donc du chiffré, est interdite. Le destinataire qui possède la clé de décapsulation retrouve l’aléa d’encapsulation. Si un générateur défectueux relie cette sortie à d’autres sorties ou à son état interne, le pair peut apprendre davantage que prévu.

FIPS 203 spécifie l’algorithme. Le NIST SP 800-227 et le RFC 8937 encadrent l’usage des KEM et l’aléa. Aucun de ces documents ne prouve la qualité d’un binaire, d’un module, d’un mécanisme de reseed ou d’un processus après fork. Le nom d’un algorithme ne constitue pas une attestation d’implémentation.

Le registre vivant ajoute une dimension temporelle. Lors du contrôle du 5 septembre, les trois valeurs figuraient déjà dans la table IANA, mais leur référence pointait encore vers la révision 05 d’un ancien projet individuel. Le Datatracker montrait en parallèle la révision 10 approuvée et l’action IANA en cours. Ce décalage est un état daté de projection, pas un défaut permanent : il faut conserver la capture et vérifier plus tard.

Le RFC 9847 empêche surtout de mal lire la lettre N. Y signifie qu’un consensus de l’IETF recommande le mécanisme pour son but défini, avec ses limites d’applicabilité. D signifie découragé et exige une justification. N signifie que l’IETF ne formule pas de conclusion sur l’aptitude. Il peut refléter une absence de consensus, un domaine limité ou des contraintes d’usage. Il ne dit pas nécessairement que le mécanisme est faible.

Deux raccourcis deviennent donc interdits. Le premier transforme « approuvé pour publication » en « recommandé pour activer partout ». Le second transforme N en interdiction de sécurité. Le premier emprunte le prestige institutionnel pour imposer un choix local ; le second invente une condamnation que le registre n’a pas prononcée.

La présence de DTLS-OK=Y ne répare aucun de ces raccourcis. Cette colonne répond à la question de l’utilisation dans DTLS. Elle n’évalue pas le risque d’une flotte, la robustesse d’une bibliothèque ou la continuité d’une application. Une interface qui fusionnerait les deux colonnes en un seul feu vert fabriquerait une recommandation inexistante.

Le contraste avec les groupes hybrides du RFC 10024 est utile. X25519MLKEM768 apparaît actuellement avec Recommended=Y, tandis que plusieurs autres constructions hybrides restent à N. La révision 10 demande explicitement aux responsables d’évaluer leurs contraintes de sécurité, de performance et d’exploitation pour choisir entre ML-KEM autonome et hybride. Elle ne déclare pas un vainqueur universel.

Un dossier de décision exploitable doit donc suivre plusieurs reçus. Il conserve la version du texte et l’instantané IANA consultés, la version de la bibliothèque et du module cryptographique, la source d’aléa et les règles de reseed, la configuration des groupes sur chaque terminaison, l’offre du ClientHello, la sélection du ServerHello, les erreurs de paramètres, le handshake terminé et enfin une requête applicative aboutie.

Chaque reçu s’arrête à sa frontière. Une configuration prouve une intention, pas un trafic. Une offre prouve une possibilité côté client, pas un choix côté serveur. Une sélection ne prouve pas la fin du handshake. Le handshake n’établit ni l’identité métier, ni l’autorisation, ni la réponse de l’application. Un canari ne représente une flotte que si sa population et sa période d’observation sont connues.

La doctrine de Lu Heng sur le code en fonctionnement remet ainsi l’autorité au bon endroit. La spécification minimale commune coordonne les octets et les erreurs. L’acteur qui supporte les conséquences décide de l’activation, de l’exception et du retour arrière. Les couches de réalité empêchent une publication, une ligne IANA et un succès isolé de devenir une seule preuve imaginaire.

Les trois groupes sont désormais décrits assez précisément pour être implémentés et négociés. C’est une avancée réelle. Le N est tout aussi réel. Il rappelle qu’un mécanisme disponible n’est ni une consigne mondiale, ni une interdiction. Entre les deux se trouve une décision locale qui doit avoir un propriétaire et des preuves.

Sources