Résumé

  • L’achèvement du handshake QUIC est local et dépend du point de vue de chaque endpoint.
  • HANDSHAKE_DONE, ou l’ACK 1-RTT admissible côté client, confirme un état de protocole et entraîne l’abandon des clés Handshake.
  • La confirmation doit être associée aux preuves relatives au 0-RTT et au résultat applicatif avant toute déclaration de disponibilité.

Le piège commence souvent par un tableau de bord. HANDSHAKE_DONE arrive, l’indicateur passe au vert, et l’équipe lit ce vert comme la preuve que le service est prêt. Pourtant, le serveur a peut-être rejeté les données anticipées. Dans ce cas, le client doit réinitialiser tous les flux concernés, ainsi que l’état applicatif qui leur était attaché. Le signal n’est pas faux; c’est son interprétation qui dépasse la preuve disponible.

RFC 9001 définit l’achèvement du handshake depuis le point de vue local. La pile TLS locale doit avoir envoyé un message Finished et vérifié le message Finished du pair. Cette condition ne survient pas nécessairement au même instant chez les deux endpoints. Une exigence fondée sur l’achèvement doit donc préciser quel endpoint observe quoi, au lieu de transformer une progression locale en événement mondial simultané.

Les règles de confirmation diffèrent ensuite selon le rôle. Lorsque le handshake s’achève au serveur, celui-ci est confirmé et doit envoyer HANDSHAKE_DONE dès que l’achèvement est acquis. Côté client, la réception de HANDSHAKE_DONE confirme le handshake. Le client peut aussi déduire cette confirmation d’un accusé de réception couvrant un paquet qu’il a envoyé avec des clés 1-RTT. RFC 9000 réserve l’envoi de HANDSHAKE_DONE au serveur. La trame indique au client que le serveur a reçu et traité son paquet Handshake; elle ne constitue pas une réponse de l’application.

Cette distinction devient concrète dans le cycle de vie des clés. Lorsque le handshake est confirmé, l’endpoint doit abandonner les clés Handshake. L’époque cryptographique Handshake est ainsi retirée. Rien dans cette transition ne certifie toutefois que la négociation applicative est terminée, qu’une requête est parvenue au code métier, qu’un stockage durable a réussi ou qu’une dépendance est saine.

Les clés Initial suivent une règle différente. Le client les abandonne lorsqu’il envoie pour la première fois un paquet Handshake. Le serveur les abandonne lorsqu’il traite avec succès un paquet Handshake pour la première fois. L’usage réussi des clés Handshake montre qu’un échange Initial supplémentaire n’est plus nécessaire, mais il ne transforme pas l’abandon des clés Initial en confirmation du handshake. Un journal qui regroupe ces événements perd une information essentielle.

Le 0-RTT doit rester séparé. Le serveur l’accepte en incluant l’extension early_data dans EncryptedExtensions et le rejette en omettant cette extension. En cas de rejet, il ne doit pas traiter les paquets 0-RTT; le client doit réinitialiser tous les flux et l’état applicatif lié à ces flux. HANDSHAKE_DONE ne peut pas convertir après coup ces données rejetées en travail accepté.

Le risque de rejeu relève du protocole applicatif. Les données applicatives envoyées en 0-RTT peuvent être traitées plusieurs fois en raison d’un rejeu. Le client ne doit les utiliser que si l’application le demande spécifiquement, et le protocole applicatif doit définir les usages acceptables. Une confirmation réussie ne prouve donc ni la sécurité contre le rejeu, ni une exécution exactement une fois, ni un engagement durable, ni l’acceptation de la demande anticipée.

Même l’ACK 1-RTT doit rester dans son périmètre. Lorsqu’il couvre le plus petit numéro de paquet 1-RTT du client, il établit la condition de confirmation définie par RFC 9001. Il ne prouve pas la consommation par l’application, l’écriture durable, l’autorisation ou la réussite métier. La bonne lecture est celle d’un reçu d’état cryptographique: précis, utile et incomplet.