C'est douteux, étant donné que TLS 1.3 c'est pas résistant aux attaques PQ dans sa forme actuelle (RFC 8446), les algos de négociation et d'échange des clefs standardisés sont basés sur les courbes elliptiques (ECDHE) et les corps finis (DHE) qui sont tous vulnérables aux attaques PQ connues.
La résistance aux attaques PQ passe par un mécanisme d'échange des clefs hybride, utilisant notamment ML-KEM (Kyber, algo standardisé NIST en 2024). Le travail est en cours avec un RFC draft : https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ qui est déjà en test dans Chrome depuis la version 131 (implémentation de X25519MLKEM768), et déployé côté serveur chez Cloudflare et Google. Le problème principal de cette solution, c'est l'augmentation considérable de la taille de clef, qui augmente la taille du ClientHello et peut poser problème avec les répartiteurs de charge et les middleboxes d'inspection du trafic TLS trop vieilles.
Ou rester sur du symétrique en augmentant un peu la taille de la clef

(pour résister à Grover)