TLS post-quantique : ce que contiennent les nouvelles recommandations PQC de l'IETF

Le 4 juillet 2026, le groupe de travail IETF Using TLS in Applications (UTA) a publié la troisième révision de l'Internet-Draft intitulé « Post-Quantum Cryptography Recommendations for TLS-based Applications », formellement référencé draft-ietf-uta-pqc-app-03. Rédigé par Tirumaleswar Reddy (Nokia) et Hannes Tschofenig (Université de la Bundeswehr de Munich), draft-ietf-uta-pqc-app se situe sur le Standards Track et prend forme comme le profil de référence pour rendre les applications basées sur TLS prêtes pour l'ère quantique.

Jusqu'ici, le débat post-quantique s'est largement concentré sur les algorithmes, en particulier la standardisation par le NIST de ML-KEM, ML-DSA et SLH-DSA. Ce draft s'attaque à la couche où la migration se joue réellement : les applications. TLS 1.3, DTLS 1.3, QUIC, le DNS chiffré et les protocoles support dont dépend pratiquement chaque échange client-serveur sur Internet. Le document reconnaît une vérité inconfortable. Le secteur a déjà mené des transitions cryptographiques, de l'abandon de SSLv2 au passage de RSA aux courbes elliptiques, mais la transition post-quantique est différente. Les clés et les signatures sont plus volumineuses, les implémentations sont plus jeunes, et les compromis de performance jouent dans les deux sens.

Pour les organisations qui exploitent leur propre PKI et leur propre infrastructure de certificats, draft-ietf-uta-pqc-app mérite une lecture attentive. Il traduit la menace quantique abstraite en décisions protocolaires concrètes, dont plusieurs atterrissent directement sur le bureau de l'équipe PKI.

Deux menaces, deux calendriers

La contribution la plus structurante de draft-ietf-uta-pqc-app est de séparer clairement la transition en deux problèmes distincts, régis par deux horloges distinctes.

La première horloge sonne déjà. La confidentialité des données est exposée dès aujourd'hui aux attaques « Harvest Now, Decrypt Later » (HNDL) : un adversaire enregistre maintenant le trafic TLS chiffré, le stocke, et le déchiffre le jour où un ordinateur quantique cryptographiquement pertinent (CRQC) devient disponible. La fenêtre de vulnérabilité n'est pas la durée de la session TLS. C'est la durée d'utilité des données elles-mêmes, qui peut s'étendre sur des décennies pour des dossiers médicaux, des plans industriels ou des secrets d'État. C'est pourquoi le draft traite l'échange de clés comme le front urgent.

La seconde horloge tourne plus lentement, mais on ne peut l'ignorer. L'authentification, cette vérification d'identité par certificat au cœur de chaque handshake TLS, ne peut pas être cassée rétroactivement. Un CRQC qui arriverait en 2035 ne peut pas forger une signature vérifiée en 2026. Le draft souligne néanmoins une asymétrie qui donne à réfléchir. Alors que la signature d'un message CertificateVerify vit quelques millisecondes, les certificats de CA racine portent couramment des durées de validité de 20 ans ou plus. Créer, certifier et distribuer de nouvelles CA racine est un processus pluriannuel. Si un CRQC arrive plus tôt que prévu, il n'y aura pas le temps d'improviser une migration de PKI.

Du principe au protocole : les exigences de confidentialité

Sur la question de la confidentialité, draft-ietf-uta-pqc-app ne prend pas de détours. Il impose aux applications utilisant (D)TLS exposées aux attaques HNDL de migrer vers (D)TLS 1.3 et d'adopter un échange de clés quantum-ready. Deux voies sont définies.

La voie privilégiée par le draft est l'échange de clés hybride, qui combine un algorithme traditionnel et un algorithme post-quantique de sorte que la session reste sûre tant que l'un des deux composants tient. Trois groupes hybrides sont spécifiés pour TLS 1.3 : X25519MLKEM768, SecP256r1MLKEM768 et SecP384r1MLKEM1024. La logique est celle de la défense en profondeur. Les implémentations PQC sont jeunes, et la cryptanalyse est une cible mouvante.

La seconde voie, l'échange de clés ML-KEM pur (ML-KEM-512, ML-KEM-768, ML-KEM-1024), est réservée aux déploiements dont le cadre réglementaire ou de conformité impose exclusivement des algorithmes post-quantiques.

Le draft se montre tout aussi pragmatique sur les frictions de déploiement. Mettre à jour une bibliothèque TLS est une première étape nécessaire mais pas suffisante, car les groupes PQC ne sont pas toujours activés par défaut. Les applications qui figent les versions de protocole ou les suites cryptographiques doivent mettre à jour explicitement leur configuration, et celles qui s'appuient sur les valeurs par défaut de la bibliothèque sont invitées à vérifier, par la documentation ou par des tests d'interopérabilité, que les groupes PQC sont effectivement négociés. Une section entière est consacrée à un problème opérationnel subtil : le ClientHello. Les key shares hybrides sont suffisamment volumineux pour dépasser la MTU, ce qui fragmente le handshake sur plusieurs paquets que les middleboxes peuvent mal traiter, en particulier sur DTLS. Le draft pèse trois stratégies : envoyer d'emblée les key shares traditionnels et hybrides (rapide, mais lourd), signaler la prise en charge de l'hybride et accepter un aller-retour HelloRetryRequest (léger, mais plus lent), ou recourir à la prédiction de key share via le DNS pour permettre aux clients d'adapter leur premier message. Aucune n'est déclarée universellement correcte. Le choix dépend de l'environnement réseau.

Authentification : la PKI au premier plan

C'est dans les chapitres consacrés à l'authentification que draft-ietf-uta-pqc-app parle le plus directement aux exploitants de PKI, et trois thèmes s'y détachent.

Le premier est la décision de format de certificat. Les déploiements peuvent opter pour du purement post-quantique, avec des certificats ML-DSA, ou SLH-DSA pour ceux qui acceptent des signatures plus volumineuses en échange d'hypothèses de sécurité conservatrices. Ils peuvent aussi adopter des certificats composites qui lient une clé traditionnelle (ECDSA, RSA, Ed25519) et une clé post-quantique dans une seule structure X.509. La vérification composite ne réussit que si toutes les signatures composantes se vérifient, ce qui produit une propriété notable, analysée en détail par le draft : même après qu'un CRQC a cassé le composant traditionnel, l'usurpation TLS reste hors de portée tant que le composant PQC demeure sûr. En pratique, cela offre aux organisations une fenêtre de transition maîtrisée plutôt qu'une migration d'urgence, y compris dans un scénario où l'arrivée d'un CRQC serait jugée imminente.

Le deuxième thème est un avertissement que le secteur avait besoin d'entendre : un certificat d'entité finale post-quantique émis sous une hiérarchie de CA classique n'apporte aucune authentification post-quantique. Chaque signature critique pour la validation, de la feuille jusqu'à l'ancre de confiance, doit être protégée par un schéma PQC ou hybride, car un attaquant équipé d'un CRQC pourrait forger des signatures réalisées avec des clés de CA traditionnelles n'importe où dans la chaîne. Le draft érige en conséquence l'approvisionnement des ancres de confiance en préoccupation de migration de premier ordre. Les systèmes à longue durée de vie ou difficiles à mettre à jour, comme les équipements embarqués et industriels, peuvent nécessiter des ancres de confiance PQC ou hybrides installées dès la fabrication, parce qu'une mise à jour sur le terrain n'arrivera peut-être jamais. Le draft met également en garde : les politiques de repli qui acceptent des chaînes uniquement traditionnelles méritent d'être explicites, puisqu'elles dégradent silencieusement la propriété de sécurité.

Le troisième thème est celui de l'économie du handshake. Les chaînes de certificats PQC sont volumineuses, et le draft passe en revue la boîte à outils : la compression de certificats TLS (d'intérêt limité face à des clés PQC à forte entropie), l'extension cached information (efficace, mais assortie de compromis de vie privée liés à la corrélation de sessions), les certificats abrégés qui omettent les intermédiaires déjà connus du client, et les identifiants d'ancre de confiance qui aident les serveurs à sélectionner la bonne chaîne lorsque des hiérarchies traditionnelles, composites et PQC coexistent.

Au-delà de TLS lui-même, draft-ietf-uta-pqc-app étend ses exigences aux protocoles dont les applications dépendent discrètement. Le DNS chiffré (DoT, DoH, DoQ) et Encrypted Client Hello via HPKE sont orientés vers les mêmes profils quantum-ready, car un échange DNS enregistré se moissonne aussi facilement que n'importe quel autre chiffré.

Ce que cela implique pour les opérations de certificats en Europe

Pour les organisations européennes, draft-ietf-uta-pqc-app n'arrive pas dans le vide. Il se pose sur une trajectoire réglementaire déjà contraignante. DORA s'applique au secteur financier depuis janvier 2025, avec ses exigences explicites d'inventaire cryptographique et de gestion des clés fondée sur le risque. Les transpositions de NIS2 étendent des obligations comparables aux entités essentielles et importantes. La feuille de route européenne coordonnée sur la cryptographie post-quantique, ainsi que les recommandations nationales de l'ANSSI et du BSI, convergent vers l'horizon que le draft sert implicitement : une protection hybride des flux à risque élevé bien avant 2030, et des trajectoires de migration complète s'étendant jusqu'en 2035.

Lu sous cet angle, draft-ietf-uta-pqc-app se comprend surtout comme le pendant protocolaire de ces obligations de gouvernance. Les régulateurs demandent aux organisations d'inventorier leur cryptographie et de planifier la migration. L'IETF décrit désormais à quoi ressemble un parc TLS une fois migré. Relier les deux est un problème opérationnel, et c'est en grande partie un problème de cycle de vie des certificats : savoir quels points de terminaison négocient quels groupes, quelles chaînes se terminent sur quelles ancres, quels équipements peuvent recevoir de nouvelles racines et lesquels ne le peuvent pas, et être capable de réémettre à grande échelle lorsqu'un algorithme, un jeu de paramètres ou une hiérarchie entière change.

Cette capacité porte un nom, la crypto-agilité, et les considérations de transition du draft montrent clairement qu'elle n'est pas optionnelle. Les déploiements dont la marge de mise à jour est réduite sont orientés vers les schémas hybrides précisément parce qu'ils ne peuvent pas pivoter rapidement. Les déploiements dotés d'un contrôle administratif fort, comme les réseaux d'entreprise et de télécommunications centralisés, sont identifiés comme ceux qui pourront adopter les signatures PQC le plus tôt. Ce qui fait la différence n'est pas l'algorithme. C'est l'automatisation et la gouvernance qui l'entourent.

En conclusion

Le draft-ietf-uta-pqc-app-03 reste un travail en cours, et les Internet-Drafts peuvent évoluer avant leur publication en RFC. Sa direction est toutefois stable d'une révision à l'autre, son langage normatif est sans ambiguïté sur les points qui comptent le plus, et il s'aligne sur les standards dont il hérite, des algorithmes FIPS du NIST aux travaux de conception hybride pour TLS. Pour les responsables d'applications, il répond à la question de ce qu'il faut concrètement configurer. Pour les équipes PKI, il confirme que la transition post-quantique se gagnera ou se perdra dans la couche des certificats : stratégie d'ancres de confiance, émission composite, optimisation des chaînes et capacité à exécuter une migration par étapes sans casser la production.

La lecture prudente est celle que suggère le draft lui-même : la confidentialité d'abord, l'authentification planifiée dès maintenant. Les organisations qui traitent leur PKI comme un système agile, automatisé et inventorié vivront la décennie à venir comme une suite de changements maîtrisés. Celles qui la traitent comme une infrastructure figée la vivront comme une falaise.