Résumé

  • La RFC 9973 fait entrer une PSK externe et le secret (EC)DHE dans le calendrier de clés TLS 1.3, sans déplacer l’authentification par certificat vers la PSK.
  • Le binder atteste que les deux extrémités ont associé la même clé à l’identité choisie pour ce handshake. Il n’atteste ni la provenance du secret, ni son exclusivité, ni le droit d’exécuter une action.
  • La bonne unité d’audit est une chaîne de garde : création, distribution, stockage, offre, sélection, validation du certificat, décision applicative, écriture durable et observation.

Un fabricant remet un appareil avec une clé publique et un secret chargé en usine. Le réseau de l’acheteur veut l’admettre avant que l’appareil possède une identité opérationnelle ordinaire. Un connecteur TLS qui ajoute le secret au chiffrement semble donner une réponse élégante : certificat pour nommer le pair, secret pour renforcer la confidentialité. Mais l’objet réellement gouverné n’est pas une simple clé. C’est l’ensemble des copies, des personnes, des systèmes de fabrication et des procédures de secours qui peuvent encore disposer de cette clé.

La RFC 9973 fixe précisément la part commune du problème. L’extension tls_cert_with_extern_psk permet à TLS 1.3 de conserver l’authentification par certificat tout en incorporant une PSK externe dans le calendrier de clés avec le secret (EC)DHE. Une PSK créée par un handshake antérieur est une PSK de reprise ; une PSK obtenue autrement est externe. Cette distinction ne relève pas d’un détail de vocabulaire : le protocole n’autorise pas à les intervertir dans ce chemin.

Le client doit accompagner l’extension de key_share, supported_groups, psk_key_exchange_modes et pre_shared_key, ne peut pas la mêler à early_data, et doit proposer psk_dhe_ke pour le handshake initial. Le serveur ne renvoie l’extension que s’il accepte l’une des PSK externes offertes et réalise aussi l’authentification par certificat. Les PSK listées doivent être externes ; une PSK de reprise dans cette liste provoque un arrêt illegal_parameter.

Un choix de clé n’est pas un certificat de garde

L’identité choisie par le serveur est un index de l’offre du client. Le binder correspondant est une valeur HMAC liée à une partie du transcript. Sa validation établit que client et serveur ont associé la même valeur à cette identité dans cette exécution. C’est une preuve nécessaire de cohérence cryptographique. Ce n’est pas une preuve que le fournisseur a produit un secret de qualité, qu’un seul détenteur le connaît, que sa copie dans une sauvegarde a été effacée, ou que son emploi est limité à cet appareil.

La RFC est plus rigoureuse qu’un discours commercial parce qu’elle expose sa propre limite : la génération, la distribution et la gestion des PSK externes restent hors de son champ. Pourtant, sa promesse conditionnelle de confidentialité à long terme dépend de leur confidentialité, de leur entropie et de leur authenticité. Elle demande une génération sûre et une taille suffisante ; RFC 4086 rappelle pourquoi une apparence aléatoire ne suffit pas lorsque l’environnement de génération peut être reproduit.

L’authentification ne migre pas vers la PSK. Les messages Certificate et CertificateVerify continuent de porter l’authentification, et la RFC interdit d’utiliser la PSK externe comme base unique de celle-ci. Cela change aussi la lecture de la menace quantique : le secret peut ajouter une condition à la confidentialité d’archives si l’attaquant ne le connaît pas, mais il ne rend pas, par lui-même, la signature de certificat résistante à une future machine quantique cryptographiquement pertinente. RFC 9958 éclaire ce cadre, non le comportement d’un produit donné.

La réutilisation fixe une autre frontière. Une PSK connue par un groupe peut être compatible avec l’authentification par certificat, mais augmente le cercle qui peut conserver le secret. Une même identité PSK apparaît dans le ClientHello en clair ; elle peut donc devenir un identifiant de suivi. La rotation et Encrypted Client Hello sont des atténuations possibles, pas des preuves que le suivi est impossible.

Un dossier qui respecte les responsabilités

La filière doit conserver l’objet et sa raison d’être : classe de génération ou dérivation, population autorisée, version TLS et hachage admis, circuit de distribution, détenteurs, rotation et destruction. Le secret lui-même reste dans son service de garde ; l’audit garde des identifiants sûrs et des attestations, non une copie supplémentaire du secret.

Pour les connexions sensibles, le dossier relie ensuite l’offre et l’acceptation de tls_cert_with_extern_psk, l’identité choisie sous une forme non révélatrice, psk_dhe_ke, la validation du certificat, l’issue Finished ou l’alerte, puis la politique applicative. Enfin seulement viennent le droit d’inscription, de lecture ou de commande, le commit et une observation indépendante. Un journal TLS ne remplace aucun de ces trois derniers maillons.

La priorité du code exécuté de Heng Lu impose cette discipline : une option activée ou un inventaire de certificats n’est pas l’exécution observée. Sa distinction entre souveraineté formelle et contrôle pratique est tout aussi nette : le titulaire nominal du secret peut ne pas être celui qui sait encore l’extraire. La RFC propose une syntaxe commune minimale ; l’organisation reste comptable de toute la réalité qui l’entoure.

Sources