Summary

  • Le BoF CURRENT d’IETF 126 a étudié l’emploi de MLS pour gérer les clés du record layer TLS 1.3, mais le groupe n’est pas chartered et le compte rendu juge le problème encore insuffisamment compris.
  • Dans le profil à deux parties, le pair qui applique le commit envoie un EpochKeyUpdate authentifié et peut employer le nouvel état ; l’initiateur doit attendre cette confirmation avant d’activer son état provisoire.
  • « Mise à jour envoyée », « clé installée localement », « ancien secret supprimé » et « service applicatif sous la nouvelle époque » sont quatre preuves différentes.

Deux états vrais au même instant

A envoie un ConnectionUpdate. B valide le commit, l’applique, renvoie EpochKeyUpdate et commence à utiliser les nouvelles données de clé. Son journal est exact. A reste pourtant dans l’état Awaiting EpochKeyUpdate. Tant que la réponse n’a pas été reçue et authentifiée avec l’état issu du commit en attente, A ne peut pas rendre cet état courant.

Cette dissymétrie n’est pas une anomalie : elle empêche un émetteur de prendre sa propre intention pour la réception effective du pair. Elle devient dangereuse seulement lorsque l’exploitation la résume en un voyant « rotation réussie ».

Le profil à deux parties et le projet MLS-TLS sont des Internet-Drafts individuels, tous deux en révision 01. CURRENT reste un BoF sans charte. Les minutes d’IETF 126 signalent des doutes sur le périmètre, sur l’écart entre un protocole à deux parties et plusieurs cas d’usage multipartites, ainsi que sur ce que des extensions TLS existantes pourraient déjà résoudre. Il faut donc décrire une proposition en formation, pas une architecture approuvée.

La sécurité après compromission ne commence pas à l’envoi

RFC 9420 fixe une limite nette : une proposition Update n’apporte pas à elle seule la post-compromise security. Elle doit entrer dans un Commit traité par les membres. La protection devient effective au traitement du Commit, pas à sa création. La forward secrecy dépend en outre de la suppression effective des anciennes clés privées et des clés de message déjà utilisées.

Les projets CURRENT transportent cette discipline vers un canal à deux parties : MLS exporte les secrets, le record layer TLS protège les données, et des commits en bande font progresser l’époque. Le message d’acquittement est authentifié sous le nouvel état. Il prouve que le pair connaît cet état ; il ne prouve pas encore que tous les anciens secrets ont disparu de tous les emplacements ni que l’application a continué à fonctionner.

La récupération après compromission suppose aussi que l’adversaire n’accède plus au terminal au moment où les secrets frais arrivent. Dire « PCS activée » nomme une propriété recherchée. Cela ne date pas la fermeture de la fenêtre d’exposition.

Une collision laisse une histoire

Les deux pairs peuvent lancer une mise à jour simultanément. Le projet tranche alors selon les rôles initiaux : un côté ignore le commit concurrent, l’autre abandonne son commit en attente et applique celui du pair. Le résultat peut converger, mais les deux parcours locaux diffèrent.

Après une interruption, une reprise peut retransmettre un commit en attente. Le récepteur doit reconnaître un commit déjà appliqué pour ne pas l’exécuter deux fois. Dans un autre cas, un commit reçu confirme implicitement qu’un état provisoire précédent a bien été intégré. La détection même de l’interruption reste hors périmètre et dépend du transport.

Conserver uniquement le numéro final d’époque détruit cette provenance. Il devient impossible de savoir si la convergence vient de l’acquittement normal, d’une collision, d’une retransmission ou d’une reprise complète.

Une chaîne de reçus, pas une case

La Minimum Initial Specification de Lu Heng invite à limiter la couche commune aux messages et transitions déterministes nécessaires. Running-Code Primacy donne ensuite priorité à l’état réellement validé et installé par les terminaux. La discipline des couches de réalité sépare : création de la mise à jour, envoi du commit, authentification par le pair, application, retour de l’acquittement, installation chez l’initiateur, suppression de l’ancien matériau et première donnée applicative authentifiée dans la nouvelle époque.

Cette prudence correspond à l’état du texte. L’analyse de sécurité complète, la séparation inter-protocoles et certains détails de format portent encore des TODO. Un BoF peut identifier un besoin sérieux ; il ne transforme pas une esquisse en consensus.

Sources et limites

Ces sources ne prouvent ni groupe de travail chartered, ni consensus IETF, ni draft adopté, ni RFC, ni analyse de sécurité achevée, ni interopérabilité, déploiement, récupération mesurée après compromission, usage PQC, incident ou résultat de service.