Résumé

  • RFC 10024 définit trois groupes TLS 1.3 qui concatènent un secret ECDHE et un secret ML-KEM dans un ordre fixe avant de les remettre à la dérivation de clés.
  • La garantie recherchée — préserver le secret si au moins un composant reste sûr — ne prouve pas que les deux composants disposent de sources de hasard, de processus ou de modules indépendants.
  • L’ordre des composants a une conséquence FIPS précise, tandis que le groupe négocié, la signature du certificat et le lieu réel de terminaison restent trois faits distincts à contrôler.

Le certificat portait sur le premier secret, pas sur toute la chaîne

Un comité de conformité reçoit un rapport rassurant. Le service négocie SecP256r1MLKEM768. Le fournisseur indique qu’un module certifié traite l’échange elliptique. Le tableau de bord ajoute une coche « hybride » et la conclusion devient : le transport est à la fois conforme et post-quantique.

La formulation paraît raisonnable jusqu’à ce que l’on dessine la frontière du module. Le secret ECDHE est bien produit dans le périmètre certifié. ML-KEM est exécuté dans une bibliothèque voisine. Les deux opérations demandent toutefois leurs valeurs aléatoires au même générateur du processus, partagent la même mémoire et sont déployées par le même artefact. Un retour d’urgence réinstalle les deux versions d’un seul geste.

Le rapport n’était pas faux ; il accordait simplement au certificat une autorité qu’il n’avait pas. Il démontrait une condition portant sur le premier composant. Il ne démontrait ni la santé de l’aléa, ni l’indépendance des pannes, ni même l’usage du groupe sur chaque terminaison.

RFC 10024, publié sur la voie normative de l’IETF en août 2026, oblige à faire cette distinction. Il définit trois mécanismes hybrides « Post-Quantum Traditional » pour TLS 1.3. Chacun associe un échange elliptique éphémère à ML-KEM. Le secret combiné vise à rester protégé lorsqu’au moins un des mécanismes composants demeure sûr.

Ce « au moins un » porte sur la construction cryptographique sous ses hypothèses. Il ne transforme pas deux noms d’algorithmes en deux chaînes d’exploitation autonomes.

Un groupe opaque impose l’ordre, les tailles et les refus

Le cadre de RFC 9954 ne négocie pas deux extensions indépendantes. Chaque combinaison est enregistrée comme un unique NamedGroup. Les valeurs publiques ou les textes chiffrés des composants sont concaténés dans un ordre fixé ; les secrets de longueur fixe le sont aussi, puis le résultat prend dans TLS 1.3 la place du secret (EC)DHE ordinaire.

X25519MLKEM768, valeur IANA 4588, place ML-KEM avant X25519. L’offre du client contient 1 184 octets de clé d’encapsulation ML-KEM-768 puis 32 octets X25519, soit 1 216 octets. La réponse contient 1 088 octets de texte chiffré puis 32 octets X25519, soit 1 120. Le secret réunit deux valeurs de 32 octets dans le même ordre.

SecP256r1MLKEM768, valeur 4587, commence par P-256 : 65 octets de point non compressé puis 1 184 octets ML-KEM côté client ; 65 plus 1 088 côté serveur. Le secret comporte 32 octets ECDHE puis 32 octets ML-KEM.

SecP384r1MLKEM1024, valeur 4589, associe un point P-384 de 97 octets à une valeur ML-KEM-1024 de 1 568 octets. Les parts client et serveur font chacune 1 665 octets ; le secret final contient 48 octets ECDHE et 32 octets ML-KEM.

Ces dimensions ne sont pas un classement de performance. Elles montrent pourquoi le groupe est une construction déterminée, et non une étiquette à apposer sur n’importe quelle concaténation. Les longueurs fixes rendent l’encodage non ambigu ; le choix du groupe fixe également les contrôles à effectuer.

Le serveur doit vérifier la clé d’encapsulation ML-KEM du client selon FIPS 203 et interrompre l’échange avec illegal_parameter si elle échoue. Le client vérifie la longueur du texte chiffré. Les contrôles de validité ECDHE s’appliquent, notamment le rejet d’un secret X25519 entièrement nul. Une autre erreur de décapsulation ML-KEM conduit à internal_error.

Ces règles empêchent une valeur mal formée de devenir silencieusement un secret. Elles ne vérifient pas l’usine qui a produit le hasard ou le binaire qui a exécuté l’opération.

La preuve appartient au protocole TLS complet

La concaténation n’est pas sûre par sa seule géométrie. Le TLS 1.3 actuel, spécifié dans RFC 9846, lie les ClientHello, l’éventuel HelloRetryRequest, le ServerHello et les messages d’authentification dans le transcript. Le ServerHello dit quel partage a été choisi ; le transcript empêche de détacher ce choix de la session ; Finished prouve la possession des clés dérivées.

RFC 10024 indique que son analyse repose de façon cruciale sur ce transcript. Reprendre les mêmes deux sorties dans un tunnel interne ou un protocole propriétaire ne suffit donc pas à reprendre la conclusion de sécurité.

La terminologie de RFC 9794 aide à contenir la promesse. Un schéma PQ/T hybride combine au moins un composant post-quantique et un composant traditionnel. « Post-quantique » décrit une propriété recherchée, pas l’impossibilité éternelle d’une attaque classique ou quantique.

L’exploitation devrait ainsi conserver une preuve bornée : groupes offerts, key shares effectivement envoyés, éventuel nouveau ClientHello, groupe sélectionné, alertes de validation, suite de signature de CertificateVerify et succès de Finished. Une préférence inscrite dans un fichier de configuration ne vaut pas reçu d’exécution.

Le générateur commun est le contre-exemple fourni par la norme

Lors d’une encapsulation ML-KEM, le serveur tire une valeur aléatoire m. Le client la retrouve pendant la décapsulation. RFC 10024 note que si m révèle des informations sur d’autres sorties du générateur, le client reçoit également ces informations. Le scalaire éphémère ECDHE dépend lui aussi d’un hasard cryptographiquement sûr, même s’il n’est pas transmis directement.

La norme en tire une conséquence explicite : si les deux algorithmes utilisent le même générateur aléatoire non sûr, la divulgation de son état par l’un compromet aussi la sécurité de l’autre.

Il faut conserver le qualificatif « non sûr ». Un CSPRNG correctement conçu, alimenté, réensemencé et protégé ne devient pas mauvais parce que deux fonctions l’appellent. La norme n’exige pas non plus deux appareils physiques. Elle exige que l’on ne déduise pas l’indépendance d’un simple inventaire d’algorithmes.

RFC 8937 décrit le risque situé plus en amont. Une entropie initiale déficiente peut affaiblir toutes les instances qu’elle ensemence. Le document propose notamment une enveloppe facultative qui mélange un matériau dérivé d’une opération de clé privée de longue durée afin de renforcer le hasard entre les sessions. Qu’un opérateur retienne cette technique ou une autre, il doit montrer les sources, l’ensemencement, les reprises après fork, les snapshots, le rollback et les tests de santé.

Le hasard est le cas écrit noir sur blanc. Le même raisonnement opérationnel s’applique à une bibliothèque vulnérable qui héberge les deux composants, à un HSM dont un firmware commun les expose, à un processus dont la mémoire contient les deux secrets ou à un compte d’administration capable de désactiver l’ensemble. Cela ne réfute pas la construction mathématique ; cela identifie l’endroit où une seule panne peut traverser les deux branches.

L’ordre FIPS distribue une obligation, pas une médaille

FIPS 203 normalise ML-KEM-512, 768 et 1024. Le texte présente ML-KEM comme considéré sûr face à un adversaire doté d’un ordinateur quantique. Cette prudence est utile : normalisation et implémentation correcte sont deux choses différentes.

NIST SP 800-227 rassemble des recommandations d’usage des KEM, y compris pour les constructions composites. Citer le document n’établit pas quelles recommandations ont réellement été appliquées dans un module donné.

RFC 10024 expose ensuite une conséquence de l’ordre des secrets. Les recommandations NIST permettent à HKDF de recevoir deux secrets distincts si le premier provient d’un mécanisme d’établissement de clé approuvé FIPS. Pour SecP256r1MLKEM768 et SecP384r1MLKEM1024, ECDHE vient en premier : l’implémentation ECDHE doit être certifiée pour l’usage décrit, sans que cette condition d’ordre impose la certification de l’implémentation ML-KEM. Pour X25519MLKEM768, ML-KEM vient en premier ; c’est donc son implémentation qui doit être certifiée.

« Premier » ne veut pas dire « plus sûr ». La certification exigée ne couvre pas automatiquement le second composant, le CSPRNG, la politique de négociation, la chaîne de livraison ou tout le service. Une assertion de conformité doit nommer le module, la version, le certificat et la frontière exacte.

Le registre fournit un vocabulaire, pas une quittance

Le registre IANA des groupes TLS attribue 4587, 4588 et 4589. Seul X25519MLKEM768 porte Recommended Y. Les deux groupes secp portent N, ce qui, selon la note du registre, ne signifie pas forcément qu’ils sont défectueux : ils peuvent répondre à des usages spécifiques.

Les valeurs expérimentales 25497 et 25498 des groupes Kyber de brouillon sont désormais obsolètes et déconseillées. La télémétrie devrait les distinguer des identifiants finaux, au lieu de résumer les deux états par « PQC ».

Un numéro enregistré établit une syntaxe commune. Il ne prouve pas qu’un client l’offre, qu’un serveur le sélectionne, que tous les points de présence exécutent la même version ou que la politique autorise le résultat. La recherche d’errata de RFC 10024 n’affichait aucun enregistrement le 30 août 2026 ; c’est un état daté du registre, non une certification des logiciels.

L’authentification suit sa propre trajectoire

RFC 9954 exclut expressément l’authentification de nouvelle génération de son périmètre. Une session peut négocier correctement le groupe 4588 tout en authentifiant le serveur avec une signature traditionnelle. La confidentialité contre « collecter aujourd’hui, déchiffrer demain » et la résistance future à l’usurpation n’obéissent pas au même calendrier.

Une observation honnête sépare donc le groupe d’accord de clés, la signature du certificat, le terminal TLS réel et l’autorisation finale de l’application. « Migration PQC achevée » écrase ces quatre surfaces.

La primauté du code exécuté, formulée par Heng Lu dans Running-Code Primacy, donne la règle de preuve : la politique déclarée doit céder devant le transcript et le résultat observé. La doctrine de la spécification initiale minimale et de la décision future localisée explique pourquoi l’IETF fixe l’interopérabilité sans choisir chaque frontière d’exploitation.

L’analyse des couches de réalité et du pouvoir symbolique sépare le mot « hybride » de l’état technique qu’il représente. Celle de la souveraineté pratique des données demande qui peut changer la bibliothèque, le terminal, l’entropie, la télémétrie et le rollback. C’est dans ces droits d’action que se trouve l’indépendance réelle.

Le protocole sait combiner deux secrets. Il ne peut pas certifier que l’organisation n’a pas placé leur destin dans la même main.