Résumé

  • Le texte actif est draft-ietf-tls-extended-key-update-13, publié le 4 juillet 2026 ; la révision 11 de la commande est désormais ancienne, et aucun de ces textes n'est un RFC approuvé.
  • La séquence request/response/finish renouvelle le secret partagé et les deux secrets de trafic, mais ses étapes ne constituent pas une attestation distante de l'effacement local.
  • Une conclusion de reprise doit relier négociation, ordre des messages, génération fraîche, destruction de l'ancien état, premières traces dans chaque direction et test applicatif aller-retour.

Un projet en mouvement, pas une capacité normalisée

Le Datatracker de l'IETF classe la révision 11 comme antérieure. La révision 13 expire le 5 janvier 2027, vise le statut Proposed Standard, mais reste à l'état « I-D Exists », sans directeur de domaine responsable ni date de téléconférence IESG. Un Internet-Draft peut encore être modifié, remplacé ou abandonné.

La différence de version est substantielle : le sous-type 2 s'appelle maintenant key_update_finish, la protection de tous les messages EKU par les anciennes clés est explicitée, et le cas de l'attaquant actif est mieux délimité. Un inventaire sérieux doit donc noter la révision réellement implémentée, pas seulement le nom de la fonction.

Trois conditions avant même le premier échange

Le client propose Extended_Key_Update dans les TLS flags du ClientHello. Le serveur ne l'accuse réception dans EncryptedExtensions que s'il le prend en charge et l'a activé. Sans cet accord, l'application qui exige une sécurité post-compromission doit lancer une nouvelle poignée de main complète.

Après négociation, l'ancien message TLS KeyUpdate devient interdit et provoque unexpected_message. La requête et la réponse doivent réutiliser le groupe choisi lors de la poignée de main initiale ; changer de groupe au milieu de la session entraîne illegal_parameter. Le support du code, l'activation de la politique et la négociation de la session sont donc trois reçus distincts.

La transition n'est pas atomique

L'initiateur envoie key_update_request avec une part de clé éphémère. Le répondant renvoie key_update_response, puis bascule sa clé d'envoi. L'initiateur dérive les nouveaux secrets, bascule sa réception, émet un key_update_finish vide sous l'ancienne clé, puis change sa clé d'envoi. Le répondant ne bascule sa réception qu'après avoir authentifié ce finish encore ancien.

Pendant cet intervalle, chaque extrémité peut voir une génération différente selon le sens. Un unique champ « version de clé de connexion » détruit cette information. Si deux requêtes se croisent, la valeur key_exchange lexicalement la plus faible perd ; une égalité ferme la connexion. Les journaux doivent conserver la compétition et l'ordre directionnel.

La dérivation combine le nouveau secret partagé, une valeur liée au main secret précédent et un transcript hash couvrant la poignée de main et les échanges EKU. Elle produit les secrets de trafic client et serveur, l'exporter secret et le resumption main secret. Contrairement au KeyUpdate classique, le futur n'est plus entièrement calculable depuis la chaîne compromise.

Ce que le protocole ne peut pas voir

Une capture peut montrer de nouvelles parts de clé et un enregistrement accepté. Elle ne révèle ni la qualité du générateur aléatoire, ni une éventuelle réutilisation d'éphémères, ni les copies anciennes restées dans le tas, un HSM, le noyau ou une image de panne. Le texte dit que l'implémentation DEVRAIT supprimer les secrets antérieurs au plus vite ; le pair ne peut pas certifier cet acte.

La preuve exploitable est une jointure : version et groupe négociés, identifiant non secret de la génération éphémère, empreintes des trois messages, génération des secrets successeurs, résultat d'effacement pour chaque couche, puis premier enregistrement accepté sous la nouvelle clé dans chaque sens.

La menace doit elle aussi avoir changé. La reprise suppose une compromission transitoire et l'expulsion de l'adversaire des deux pairs. Un intrus persistant lit le nouvel état ; un adversaire actif possédant les clés courantes peut substituer les messages, sauf si l'authentification supplémentaire de la section 11 est effectivement disponible, exigée et réussie. Réparer une connexion ne répare pas une clé d'identité à long terme compromise.

DTLS ajoute ses propres reçus : epochs, retransmissions, conservation temporaire de l'ancien état et ACK. L'initiateur ne termine sa bascule d'envoi qu'après l'accusé de réception sous le nouvel epoch. Une télémétrie TLS ne prouve pas cela par simple changement d'étiquette.

Sources