Résumé

  • L’acceptation de QUIC 0-RTT est une décision TLS et transport, pas la preuve d’une exécution applicative unique.
  • Un ACK de paquet atteste d’un traitement de transport, pas de la résistance à la relecture ni d’un commit durable.
  • Le protocole applicatif doit fixer l’usage acceptable des données anticipées et séparer toutes les preuves de traitement et de résultat.

QUIC 0-RTT permet au client de réutiliser une configuration liée à une connexion précédente, notamment un ticket de session TLS, pour envoyer des données applicatives avant la fin de la nouvelle négociation. Le serveur accepte ce mode en envoyant l’extension TLS early_data dans EncryptedExtensions. Il traite ensuite les paquets 0-RTT reçus et les accuse réception. S’il omet cette extension, le 0-RTT est refusé et les paquets concernés ne doivent pas être traités comme des données anticipées acceptées.

Cette séquence fournit une preuve précise, mais limitée. Elle ne démontre pas qu’un gestionnaire applicatif a exécuté l’action une seule fois, ni que la demande a atteint un service aval ou une frontière de persistance. Elle ne prouve pas davantage la vivacité du client, son identité authentifiée avant la fin de la négociation, un effet métier ou un résultat financier. La validation d’adresse peut apporter un élément supplémentaire, sans transformer une demande susceptible d’être rejouée en action unique.

Le risque vient de l’exposition à la relecture héritée des données anticipées TLS. Les protections TLS sont nécessaires mais ne constituent pas une garantie universelle pour l’application. Le traitement du transport QUIC est idempotent : rejouer des trames ne crée pas en soi un état de connexion invalide. Les conséquences persistantes apparaissent dans les informations applicatives transportées. STREAM, RESET_STREAM, STOP_SENDING et CONNECTION_CLOSE peuvent avoir une signification applicative et devenir dangereux en 0-RTT. Le protocole utilisant QUIC doit donc définir un profil d’usage acceptable.

HTTP rend cette frontière visible. En l’absence d’information meilleure, les clients peuvent employer des méthodes sûres dans les données anticipées et ne doivent pas envoyer de méthodes dangereuses ou de sûreté inconnue. L’en-tête Early-Data signale une propagation sous conditions anticipées. Une réponse 425 Too Early signifie que le serveur refuse de prendre le risque d’un traitement susceptible d’être rejoué ; la nouvelle tentative ne doit pas utiliser elle-même le 0-RTT. Attendre ensuite la fin de la négociation ne rend pas rétroactivement la demande sûre. Les instances distribuées doivent appliquer une politique cohérente.

Le registre opérationnel doit conserver séparément le ticket de session et la configuration mémorisée ; 0-RTT tenté, accepté ou refusé ; ACK de paquet ; propagation de Early-Data et traitement de 425 ; identité de la demande et clé d’idempotence éventuelle ; tentatives d’exécution ; effets de bord ; reçu de commit durable ; observations de relecture ou de nouvelle tentative ; résultat client ou financier. Les clés d’idempotence, journaux de transaction et registres distribués sont des recommandations d’exploitation, sauf exigence propre au protocole applicatif.

La bonne décision n’est donc pas de désactiver partout 0-RTT, mais de le limiter aux opérations dont les conséquences d’une relecture sont explicitement bornées. L’acceptation reste la preuve d’une décision de données anticipées, jamais celle d’un commit.