Résumé

  • Le 10 septembre 2026, l’IESG a rejeté un recours, levé le blocage de publication et annoncé l’approbation de draft-ietf-tls-mldsa-05. Le texte décrit l’authentification TLS 1.3 avec les signatures ML-DSA de FIPS 204. Son statut visé est RFC informationnel ; lors de la vérification, il restait un Internet-Draft sans numéro de RFC.
  • Le registre IANA des SignatureScheme TLS affiche mldsa44, mldsa65 et mldsa87 aux valeurs 0x0904, 0x0905 et 0x0906. Chaque ligne porte N. Selon le RFC 9847, cette lettre signifie que l’IETF ne formule pas d’avis d’aptitude ou qu’il n’existe pas de consensus ; elle ne correspond pas à D, qui signale un mécanisme déconseillé.
  • Autoriser une publication, attribuer des identifiants interopérables et recommander un déploiement sont trois actes distincts. Le rejet du recours tranche le différend de procédure soumis à l’IESG, pas le choix universel entre ML-DSA pur et composite.
  • L’adoptant doit produire sa propre fiche de décision : périmètre TLS, profil retenu, populations de pairs et de certificats, preuves testées, seuils d’échec, retour arrière, responsable et date de réexamen.

Ce que l’IESG a effectivement décidé

L’historique Datatracker sépare désormais nettement les étapes. Le document avait été approuvé le 8 juillet, puis placé en attente pendant l’examen d’un recours. Le 10 septembre, l’IESG a rejeté ce recours, libéré le texte et renvoyé l’annonce d’approbation. La notification officielle le présente comme un produit du groupe de travail TLS destiné à devenir un RFC informationnel.

Le parcours conserve le désaccord au lieu de le masquer. Le résumé du rapporteur évoque environ 275 messages et un rapport d’environ quatre soutiens pour une opposition en faveur de la poursuite. Il décrit aussi plusieurs positions : ne pas publier ML-DSA pur, recommander les signatures composites, ou publier les deux voies en parallèle. La réponse de l’IESG au recours indique que les retours du Working Group Last Call ont été examinés, que le soutien était large et que les objections avaient été considérées et débattues. Deb Cooley, directrice de la zone Sécurité, n’a pas participé à cette décision.

Cette conclusion autorise la publication malgré une opposition persistante. Elle ne transforme pas le consensus approximatif en validation de chaque architecture de déploiement. Le mécanisme de recours vérifie ici une décision de processus : les objections ont-elles été entendues et la conclusion du groupe était-elle défendable ? La sécurité d’une flotte, le comportement de ses clients et la capacité de revenir en arrière restent hors de cette réponse.

Il subsiste enfin une étape de production éditoriale. La fiche courante porte l’état Approved-announcement sent, mais qualifie toujours la révision 05 d’Internet-Draft actif. La revue IANA est Version Changed - Review Needed et l’action IANA In Progress. Tant qu’un numéro n’a pas été attribué, parler d’un RFC déjà publié ferait disparaître une frontière encore observable.

Trois valeurs résolvent un problème précis

Le texte approuvé n’est pas un programme général de migration post-quantique. Il relie FIPS 204, qui normalise ML-DSA, au mécanisme de négociation des signatures de TLS 1.3. Il associe ML-DSA-44 à mldsa44 et 0x0904, ML-DSA-65 à mldsa65 et 0x0905, puis ML-DSA-87 à mldsa87 et 0x0906.

Le RFC 9881 fournit les AlgorithmIdentifier X.509 correspondants. Le nouveau texte donne aux pairs TLS les valeurs qui signalent ces algorithmes. Pour CertificateVerify, la signature et la vérification suivent FIPS 204 avec un paramètre ctx vide ; le certificat d’entité finale doit employer l’identifiant correspondant. Les variantes préhachées HashML-DSA ne sont pas celles définies ici.

Ce raccord est essentiel à l’interopérabilité. Deux équipes peuvent implémenter le même nom, le même octet de registre et le même format de certificat sans accord privé. Il ne prouve cependant ni l’existence d’une chaîne de certification disponible, ni l’acceptation par les clients, ni la sûreté d’une implémentation matérielle, ni le coût d’un retour arrière dans une flotte hétérogène.

Le registre IANA en ligne montre déjà les trois lignes avec N. Sa référence pointe encore vers une version antérieure du draft, alors que Datatracker indique un traitement IANA en cours. Le constat exact est donc double : les valeurs sont bien attribuées et visibles ; la chaîne de publication et de mise à jour des références n’est pas encore achevée.

La lettre N n’est ni un refus ni un feu vert

Le RFC 9847 définit le sens institutionnel de la colonne. Y atteste un consensus de l’IETF pour recommander l’élément comme adapté à l’usage défini, sans supprimer ses limites d’applicabilité. D indique qu’il est déconseillé et exige une justification. N signifie qu’aucun avis d’aptitude n’est formulé, qu’aucun consensus n’existe, ou que l’emploi peut être limité à certains cas.

Le RFC ajoute expressément que N ne signifie pas nécessairement « défectueux ». Cette précision empêche deux raccourcis opposés. Une valeur attribuée n’est pas une autorisation universelle de mise en production. Mais une valeur N n’interdit pas non plus l’expérimentation contrôlée. Le registre rend un objet commun possible et conserve l’état de la recommandation ; il ne remplace pas la politique de risque de chaque réseau.

Confondre les niveaux donnerait à IANA un pouvoir que le registre ne revendique pas. Un identifiant deviendrait implicitement une certification de sécurité. À l’inverse, traduire N par « non approuvé » ferait passer une absence de jugement pour une condamnation. La forme à trois états protège la capacité d’apprendre sans fabriquer un consensus absent.

Le choix pur ou composite reste à instruire

Le document approuvé décrit ML-DSA pur. Un Internet-Draft individuel actif propose séparément d’associer ML-DSA à une signature traditionnelle dans TLS 1.3. Datatracker précise que ce texte individuel n’est pas endossé par un flux de l’IETF. Il constitue une option technique documentée, pas une préférence institutionnelle établie.

Le bon profil dépend de la menace et du système. Une solution pure évite d’exiger la validation d’une deuxième signature, mais concentre l’assurance dans ML-DSA et son code. Une construction composite peut maintenir une composante classique si le nouvel algorithme ou son implémentation échoue ; elle ajoute aussi taille, calcul, complexité de certificat et risques d’incompatibilité. Aucun de ces arbitrages ne se résout par le seul état « RFC informationnel ».

La liste d’implémentations jointe à l’annonce doit subir la même lecture. Voir ML-DSA dans OpenSSL, BoringSSL, rustls-post-quantum, s2n-tls, wolfSSL, Bouncy Castle ou GnuTLS prouve que des chemins de code existent. Cela ne prouve ni activation par défaut, ni trafic réel, ni chaîne de certificats commune, ni niveau de performance, ni procédure de retrait testée.

Une fiche locale rend le déploiement imputable

La décision utile commence par un objet plus petit que « passer au post-quantique ». Il faut nommer la surface TLS : authentification de serveur, authentification de client, service privé limité ou essai public. Le profil et le paramètre ML-DSA doivent être explicites, ainsi que le caractère pur ou composite de la solution.

La fiche doit ensuite décrire la population : autorités émettrices, profils de certificat, terminaux, clients, bibliothèques et frontières matérielles. Elle doit fixer le comportement de négociation lorsqu’un pair n’annonce pas la valeur, distinguer le repli attendu d’une dégradation silencieuse et expliquer le sort d’une chaîne partiellement compatible.

Les preuves ont besoin d’une date. Un essai entre deux versions du même composant n’est pas une validation croisée. Il faut mesurer la taille des échanges, le processeur et la latence sous charge réaliste, vérifier l’émission et la chaîne complète, examiner la production des clés, la signature, la vérification et les risques de fuite dans l’environnement réellement utilisé.

Enfin, la fiche nomme celui qui peut étendre ou arrêter l’essai, les signaux déclenchant le retour arrière, la manière de retirer clés et certificats distribués, l’expiration des preuves et la prochaine revue. Elle ne réécrit pas la décision de l’IETF : elle localise la décision future chez l’acteur qui en porte le risque.

Limites de preuve

Aucune source citée n’établit une activation par défaut ou un usage général en production. Elles ne démontrent pas la supériorité universelle du profil pur ou composite. Le rejet du recours est une appréciation de processus, pas une preuve cryptographique. La normalisation NIST n’est pas une évaluation de déploiement TLS. La présence dans le registre ne signifie pas que le travail IANA et RFC Editor est terminé.

Le constat défendable tient en une phrase : l’IETF a autorisé la publication d’une manière interopérable d’utiliser trois paramètres ML-DSA dans TLS 1.3, tout en conservant un état de recommandation N. La prochaine décision appartient à l’adoptant et exige ses propres preuves.

Sources

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. IESG — Annonce d’approbation de Use of ML-DSA in TLS 1.3
  5. IETF Datatracker — draft-ietf-tls-mldsa-05
  6. IETF Datatracker — Historique du document
  7. IESG — Réponse au recours, pièce 320
  8. IANA — Paramètres de Transport Layer Security
  9. RFC 9847 — Mise à jour des registres IANA pour TLS et DTLS
  10. NIST — FIPS 204, norme ML-DSA
  11. RFC 9881 — Identifiants d’algorithme pour ML-DSA
  12. RFC 9846 — Le protocole TLS 1.3
  13. IETF Datatracker — Use of Composite ML-DSA in TLS 1.3