Summary

  • Un bit Key Phase différent ne devient une mise à jour confirmée que si le paquet est traité avec succès avec la clé et l’IV suivants.
  • Ce succès prouve que le pair a engagé la mise à jour sur cette connexion, mais ni sa raison ni l’effacement des anciennes clés.
  • L’attribution exige de joindre paquet, génération de clés, acquittement, déploiement et journal de politique.

Un tableau de bord relève un changement de phase pendant une mise en production. L’équipe parle aussitôt de rotation de sécurité. La coïncidence temporelle est utile, mais le bit ne contient pas ce motif.

La section 6 du RFC 9001 assigne au bit Key Phase une fonction étroite : indiquer le jeu de clés qui protège un paquet 1-RTT. Initialement à zéro, il bascule à chaque mise à jour. QUIC emploie son propre mécanisme et non le message TLS KeyUpdate. Le signal identifie une génération, pas une décision opérationnelle.

La limite probante figure en section 6.2. Face à la phase opposée, le récepteur essaie la clé et l’IV suivants. Seul un traitement réussi établit que le pair a lancé la mise à jour. Le récepteur doit ensuite actualiser ses clés d’émission avant d’acquitter ce paquet ; un acquittement protégé par les nouvelles clés signale l’achèvement. Une capture qui montre le bit sans résultat de déchiffrement ne montre donc qu’une transition apparente.

La séquence est contraignante. La section 6.1 interdit une mise à jour avant confirmation de la poignée de main, puis une nouvelle mise à jour avant l’acquittement d’un paquet de la phase courante. La clé de protection d’en-tête reste inchangée. Les anciennes clés de paquet sont conservées au moins jusqu’au premier paquet correctement déprotégé avec les nouvelles, puis assez longtemps pour absorber le réordonnancement.

Les sections 6.3 et 6.5 justifient la coexistence temporaire des générations courante, suivante et parfois précédente, sans fuite temporelle. Un bit forgé peut provoquer du calcul ; un échec de déchiffrement ne prouve ni mise à jour légitime ni attaque.

Le dossier d’incident doit conserver rôle du terminal, empreinte de connexion, numéro de paquet, phase, résultat du déchiffrement, générations lecture/écriture, heure de confirmation, paquet déclencheur, acquittement sous nouvelle clé, fenêtre de conservation, version logicielle, époque de déploiement et événement de politique. Le protocole prouve la continuité cryptographique ; ces pièces expliquent l’intention et la cause.