Résumé

  • La RFC 10024 définit trois groupes hybrides pour TLS 1.3 : X25519MLKEM768, SecP256r1MLKEM768 et SecP384r1MLKEM1024. Chacun associe ML-KEM à un composant classique d’établissement de clé sur courbe elliptique.
  • L’accord de clé produit les secrets de session ; le certificat et la signature CertificateVerify authentifient le serveur. La migration du premier mécanisme ne migre pas automatiquement le second.
  • Bas Westerbaan signe la RFC avec Krzysztof Kwiatkowski, Panos Kampanakis et Douglas Stebila. Leur apport fournit un jalon vérifiable, non un label couvrant l’ensemble du service.

Un acheteur peut demander : « Ce service est-il résistant au quantique ? » L’ingénieur, lui, doit demander : « Quelle opération, sur quel chemin, face à quel adversaire, à quelle date ? » La différence entre les deux questions décide de la qualité d’une migration.

Publiée comme Proposed Standard de l’IETF en août 2026, la RFC 10024 stabilise trois groupes TLS 1.3. X25519MLKEM768 associe X25519 à ML-KEM-768 ; SecP256r1MLKEM768 et SecP384r1MLKEM1024 font de même avec les courbes NIST correspondantes. Les parts de clé et le secret partagé incorporent les deux composants selon l’ordre défini par la RFC.

L’enjeu est concret. Un adversaire passif peut conserver aujourd’hui des flux chiffrés et espérer casser plus tard l’établissement de clé classique grâce à un ordinateur quantique cryptographiquement pertinent. Le montage PQ/T réduit la dépendance à une seule famille mathématique pour la création du secret de session.

Cette protection ne voyage pas par contagion vers toutes les autres fonctions cryptographiques.

Le certificat accomplit un autre travail

TLS 1.3 réunit plusieurs opérations dans une même poignée de main. L’échange de clés alimente la dérivation des clés de trafic. Le certificat, sa chaîne de confiance et la signature CertificateVerify servent à authentifier l’extrémité. Les messages se répondent dans le même transcript, mais les garanties ne sont pas interchangeables.

La RFC 9794 est particulièrement utile pour éviter les raccourcis. Elle distingue l’établissement de clé hybride PQ/T, les KEM hybrides, le chiffrement à clé publique hybride et les signatures numériques hybrides. Une organisation peut être avancée dans l’un et en attente dans l’autre. Même la RFC 9935, consacrée aux identifiants ML-KEM dans X.509, ne transforme pas un identifiant en chaîne de confiance déployée ni un KEM en signature post-quantique.

Deux adversaires permettent de comprendre la frontière. Le collecteur passif veut déchiffrer demain un trafic enregistré aujourd’hui ; l’accord de clé hybride vise directement ce risque. L’attaquant actif du futur veut forger une signature classique pour usurper un serveur ; il faut alors migrer les signatures, les certificats, l’émission et la validation. Les deux scénarios appartiennent au même horizon quantique, pas au même contrôle.

Une migration par étapes, rendue visible

La page professionnelle de Cloudflare Research présente Bas Westerbaan comme Research Engineer chargé de favoriser l’adoption de la cryptographie post-quantique, de l’ingénierie et la normalisation jusqu’aux expérimentations à grande échelle et au déploiement. Son dossier IETF contient la RFC 10024 et d’autres travaux post-quantiques.

Il faut préserver l’auteur collectif. La RFC 10024 porte aussi les noms de Krzysztof Kwiatkowski, Panos Kampanakis et Douglas Stebila. Elle s’appuie sur la construction générale de la RFC 9954, le vocabulaire de la RFC 9794, le protocole TLS 1.3 et le standard ML-KEM de NIST. Le profil de Westerbaan aide à suivre le passage de la norme au terrain ; il ne lui attribue pas à lui seul tout le mécanisme.

Un billet de Cloudflare publié en septembre 2025 offre une preuve rare de séparation. L’entreprise y indiquait que plus d’un tiers du trafic humain reçu par son réseau utilisait TLS 1.3 avec un accord de clé post-quantique hybride. Quelques lignes plus loin, elle précisait que les signatures et certificats post-quantiques étaient encore en cours de normalisation pour TLS et la PKI d’Internet, et que WARP ne les utilisait pas encore.

Ce constat n’est ni une faiblesse ni une certification globale. Il décrit une étape de production importante et la limite voisine. Le chiffre concerne le réseau de Cloudflare à cette date, pas l’ensemble de l’Internet. Le billet ne prouve pas chaque configuration ultérieure. Il montre surtout pourquoi « chiffrement PQ » ne suffit pas à décrire l’authentification.

Ce que montre réellement une capture TLS

La liste supported_groups d’un client indique des capacités proposées. Elle ne prouve pas le groupe finalement retenu. La sélection par le serveur prouve une négociation au point observé, pas l’absence de bogue, de fuite auxiliaire ou d’aléa faible. Une poignée de main aboutie ajoute la preuve que les deux extrémités ont produit des clés utilisables ; elle n’audite pas pour autant toute l’architecture.

Il reste à relever la chaîne de certificats, l’algorithme de signature du transcript, le lieu de terminaison TLS, les proxys intermédiaires, la connexion à l’origine, les sessions reprises et le 0-RTT. Après déchiffrement, les données peuvent entrer dans des journaux, une base, une sauvegarde ou un autre tunnel protégé par des clés différentes. La propriété observée à la bordure ne répond pas à ces questions.

La RFC 10024 impose elle-même de la modestie. Sa section de sécurité explique la construction retenue et avertit qu’une hybridation similaire ne doit pas être présumée sûre dans d’autres protocoles. Il ne suffit pas de concaténer deux secrets pour fabriquer une recette universelle. Le combineur, la longueur, le transcript et le modèle d’attaque font partie du résultat.

La RFC 9851, qui gèle les nouvelles fonctionnalités de TLS 1.2, indique aussi où porter les innovations : TLS 1.3. Elle ne dit pas que passer à cette version aligne instantanément échange de clés, certificats, matériel cryptographique et stockage.

Produire une preuve au lieu d’un slogan

Le principe de primauté du code en fonctionnement de Heng Lu fournit un critère opérationnel. Une déclaration « post-quantique » n’est pas le résultat. Le résultat est un ensemble reproductible d’observations, assorties de leur périmètre.

Une fiche sérieuse devrait conserver le client, l’extrémité, l’heure, la version TLS, les groupes annoncés et négociés, les versions logicielles, la chaîne de certificats, la signature CertificateVerify, le terminateur, les règles de reprise, les sauts en aval et le point où les données apparaissent en clair. La méthode de mesure et ses angles morts sont aussi des données.

Cette granularité distribue correctement les responsabilités. L’IETF spécifie ; bibliothèques et navigateurs implémentent ; opérateurs configurent ; autorités de certification émettent ; équipes réseau gèrent les proxys ; applications stockent ; équipes d’incident révoquent et restaurent. Aucun acteur ne peut conclure pour tous les autres à partir d’un seul groupe négocié.

La RFC 10024 permet de fermer proprement une ligne importante du registre de risques. Elle oblige aussi à laisser ouvertes, et nommées, les lignes qui ne le sont pas encore.

Sources