Résumé

  • La RFC 9369 dissocie délibérément le nom « QUIC version 2 » de la valeur 0x6b3343cf des en-têtes longs. Voir cette valeur est un fait de paquet limité, pas un recensement de déploiement.
  • Le support de v2 exige que les deux extrémités échangent et valident une information de version authentifiée. Cette preuve ne concerne une connexion qu’après le handshake ; elle ne prouve ni adoption de flotte, ni succès applicatif, ni obligation imposée à d’autres réseaux.

Les noms de version offrent une histoire rassurante : v1 serait l’ancien monde, v2 le suivant, et la publication suffirait à dater le mouvement. La RFC 9369 ne laisse pas cette histoire se substituer aux faits. Martin Duke y appelle « version 2 » le nom informel de la deuxième version QUIC publiée sur la voie Standards Track, puis choisit pour le champ Version des en-têtes longs 0x6b3343cf, une valeur dérivée d’un hachage plutôt que le chiffre deux. Le choix ne cherche pas à produire un mystère. Il cherche à empêcher qu’un équipement intermédiaire transforme l’octet familier de v1 en règle immuable.

Il faut donc lire trois objets séparément. La RFC décrit une règle commune. Le registre IANA note une attribution permanente. Une capture observe une valeur dans un paquet, à un endroit et à un instant donnés. Chacun est vérifiable dans son propre cadre. Aucun ne dit combien d’endpoints ont activé v2, si le pair final sait le traiter, si le handshake TLS s’est terminé, ni si un échange HTTP/3 a abouti. Confondre ces plans remplace une chaîne de preuves par une étiquette.

La portée technique de v2 reste volontairement étroite. La RFC reprend presque tout QUIC v1, mais change les types de paquets à en-tête long, le sel Initial, les libellés HKDF et le matériel d’intégrité Retry. Ces écarts suffisent à mettre à l’épreuve la négociation de version et les hypothèses rigides attachées à v1. Ils ne donnent pas à un observateur le droit de déduire l’ensemble des capacités d’une implémentation. La RFC 8999 est explicite : supposer qu’un paquet porteur d’une valeur Version donnée signifie que cette version est réellement en usage est une hypothèse incorrecte.

La première limite se rencontre côté serveur. Un Initial ayant l’apparence de v2 peut toucher un répartiteur, un composant Retry sans état, une couche de transit et un serveur applicatif qui ne partagent pas forcément la même connaissance des versions. La capture faite au premier étage ne décrit pas la configuration du dernier. Un paquet de Version Negotiation ne clôt pas non plus l’enquête. Selon RFC 8999, il n’a ni intégrité ni confidentialité.

Les identifiants de connexion recopiés apportent une assurance modeste d’observation du trafic ; la RFC 9368 exige néanmoins qu’un endpoint authentifie le contenu sémantique avant de changer de version. Le reçu décisif est l’état de handshake validé et lié à cette tentative, non la simple arrivée d’une liste.

RFC 9369 rend la prudence encore plus concrète. Elle ne déprécie pas v1. Puisqu’une annonce Alt-Svc h3 ne distingue pas les versions QUIC, une origine qui la publie devrait continuer à offrir v1 afin d’éviter l’incompatibilité ou le repli TCP pour les clients plus anciens. v1 et v2 sont compatibles ; un endpoint qui les prend en charge devrait pratiquer la négociation compatible pour éviter un aller-retour supplémentaire. Ce sont des règles d’interopérabilité. Elles ne donnent à personne l’ordre de retirer v1, d’activer v2 ou de déclarer invalide un opérateur qui conserve un autre ensemble compatible.

Même le ticket de session v2 a une signification modeste. Le texte indique une intention de maintenir le support tant que le ticket est valide, tout en précisant que ce support n’est pas garanti. Ce signal daté peut enrichir un dossier sur un endpoint. Il ne garantit pas une connexion ultérieure, ne décrit pas une autre arête et ne devient pas une promesse de service pour toute une flotte.

La protection contre le downgrade reste également locale. Un endpoint v2 doit envoyer, traiter et valider le paramètre de transport version_information défini par RFC 9368. Les deux pairs confrontent version choisie et versions disponibles dans un échange authentifié. On peut alors conclure avec précision que ces deux participants ont franchi les contrôles définis pour cette connexion. On ne peut pas en déduire l’identité humaine du pair, l’autorisation applicative, la conservation des données ou la réussite du service.

La contribution de Martin Duke doit être limitée de la même façon. Son profil IETF et RFC 9369 attestent l’auteur d’une spécification Standards Track. Ils ne font pas de lui le propriétaire de QUIC, le décideur de déploiements HTTP/3 ou le représentant automatique des utilisateurs des endpoints. La valeur de son texte est précisément de permettre une variation future sans faire croire qu’un document convertit du code local en réalité globale.

La doctrine de Heng Lu sur la spécification initiale minimale éclaire ce point sans qu’il faille transformer QUIC en manifeste institutionnel. La couche commune fixe les règles déterministes nécessaires à l’interopérabilité et à la sécurité ; l’implémentation, le moment de déploiement et l’adoption restent des choix locaux. Le numéro volontairement non littéral, la compatibilité explicite et la négociation authentifiée de v2 donnent un analogue technique de cette retenue.

Pour exploiter ce mécanisme sans surinterprétation, il faut une chaîne de reçus : valeur d’en-tête et chemin observés, versions annoncées, résultat authentifié de version_information, version sélectionnée, fin du handshake, ALPN négocié, résultat de requête, portée logicielle et fenêtre d’observation. Les échecs et replis font partie du dossier. Ainsi seulement peut-on distinguer un registre, un paquet, une négociation réussie et un service effectivement rendu.

Sources