Résumé

  • Dans TLS 1.3, un KeyUpdate fait avancer la clé d’émission d’un seul côté et la clé de réception correspondante chez le pair. Le trafic inverse ne change qu’au moyen de sa propre mise à jour.
  • Effacer les anciennes générations peut soustraire le passé à la divulgation d’un secret ultérieur. En revanche, connaître le secret courant permet de calculer ses descendants : cette rotation ne répare pas une connexion compromise.

Le compteur continue quand la poignée de main est déjà loin

Une connexion durable ne consomme pas seulement du temps. Elle consomme un budget cryptographique : records après records, la même clé d’AEAD protège toujours davantage de données. Les garanties de confidentialité et d’intégrité d’un algorithme authentifié ont des limites d’usage ; elles ne deviennent pas infinies parce que la poignée de main s’est bien déroulée.

TLS 1.3 recommande donc de changer les clés avant d’atteindre ces limites. RFC 9325 invite également les applications qui conservent longtemps leurs connexions à prévoir ce renouvellement. Il ne s’agit pas d’une cadence universelle : le bon seuil dépend de l’algorithme, du volume et de la politique du système.

Les versions antérieures de TLS disposaient de la renégociation, opération vaste qui pouvait mêler de nouveaux paramètres, de nouvelles clés et des questions d’authentification au milieu d’une connexion existante. TLS 1.3 a supprimé cette mécanique. Son KeyUpdate ne choisit pas une nouvelle version, ne remplace pas un certificat et ne redéfinit pas l’utilisateur de l’application. Il ne touche qu’aux secrets de trafic applicatif.

La frontière est un record protégé

La mise à jour n’arrive pas par un canal administratif parallèle. L’émetteur chiffre le message KeyUpdate avec ses anciennes clés, puis emploie les nouvelles pour tous les records suivants. Le destinataire authentifie donc le message avec son état de réception courant avant de faire avancer ce même état pour la suite.

Cette règle donne une frontière nette et vérifiable. Elle interdit toutefois les approximations d’implémentation : basculer trop tôt empêche de lire l’ordre de mise à jour ; basculer trop tard fait échouer le premier record de la nouvelle génération. Le flux protégé doit être traité dans son ordre.

Surtout, la frontière n’est pas bidirectionnelle par nature. Les secrets du trafic client et du trafic serveur sont distincts. Quand A renouvelle son émission, B renouvelle la réception qui lui correspond ; l’émission de B continue avec sa génération propre.

La valeur update_requested permet à A de demander une réponse. B envoie alors son propre KeyUpdate, avec update_not_requested. Il y a bien deux actes protégés et deux transitions directionnelles, pas une substitution simultanée déclenchée par le premier message. Des demandes indépendantes peuvent même se croiser en vol. Chaque pair doit répondre correctement, sans lancer une deuxième demande avant d’avoir reçu la réponse attendue.

Le protocole pose aussi des limites d’autorité. Un KeyUpdate reçu avant Finished est une erreur. Un pair ne doit pas pouvoir imposer une quantité illimitée de dérivations et de travail en multipliant les messages. Renouveler une clé n’accorde pas un droit au déni de service.

L’effacement ferme une porte derrière soi

Après la transition, un endpoint peut supprimer l’ancien secret lorsqu’il n’est plus nécessaire au traitement. Si un attaquant obtient plus tard une génération récente, la fonction de dérivation à sens unique ne lui livre pas pour autant les générations antérieures. L’effacement donne ainsi une protection utile aux anciens échanges enregistrés.

Mais la chaîne a une orientation. Celui qui possède le secret de trafic actuel peut dériver les secrets qui le suivront. Un autre KeyUpdate ne verse ni aléa indépendant ni nouvelle preuve d’identité dans la connexion ; il poursuit une lignée dont l’attaquant connaît déjà l’ancêtre.

Deux événements imposent donc deux réponses. L’approche de la limite d’usage d’une clé appelle une nouvelle génération. La suspicion que le secret courant est divulgué appelle la fin de la connexion et une nouvelle poignée de main apportant une entropie fraîche. Confondre les deux transforme une activité de rotation visible en continuité silencieuse de la compromission.

HTTP/2 a accepté l’opération étroite

Le multiplexage d’HTTP/2 montre l’intérêt de ce périmètre réduit. Changer l’identité authentifiée d’une connexion portant plusieurs requêtes crée une question insoluble : à quelle identité rattacher chaque flux au moment du basculement ? RFC 9113 interdit donc l’authentification post-handshake de TLS 1.3 avec HTTP/2.

Le même texte autorise KeyUpdate, car le renouvellement d’un secret de record ne change directement ni l’identité ni la signification d’une requête. Les flux continuent et une seule direction cryptographique avance. La compatibilité vient de la modestie de l’opération, non d’une exception accordée à toute reconfiguration postérieure à la poignée de main.

QUIC fixe encore une autre limite. RFC 9001 interdit les messages TLS KeyUpdate dans QUIC, bien que TLS fournisse les secrets initiaux. Un transport par datagrammes doit composer avec le réordonnancement ; QUIC utilise son bit Key Phase et ses règles d’accusé de réception. Le besoin de renouvellement est commun, la mécanique ordonnée de TLS ne l’est pas.

La valeur d’une compétence limitée

KeyUpdate n’authentifie personne de nouveau, ne réinitialise pas l’application et ne prouve pas qu’un incident est terminé. Il organise les générations de protection des records, dans chaque sens, au sein d’une connexion qui continue.

Son importance historique tient précisément à cette séparation. TLS 1.3 a remplacé une cérémonie générale par des mécanismes dont l’autorité est explicite. La clé peut changer sans que l’identité change ; et la clé suivante peut être neuve pour l’usage sans être indépendante de son passé.

Sources et limites

L’analyse s’appuie sur RFC 8446, RFC 9001, RFC 9113 et RFC 9325. Ces textes ne mesurent ni le déploiement actuel, ni les valeurs par défaut des bibliothèques, ni une fréquence valable pour tous les services.