Résumé

  • Une trame CRYPTO est une portion contiguë, repérée par offset et longueur, du flux de négociation d’un seul niveau de chiffrement.
  • Ses limites, comme celles du paquet, ne prouvent ni un message TLS complet, ni une séquence complète de messages, ni un certificat accepté, ni une fin de négociation.
  • L’observation doit séparer transport QUIC, réassemblage, analyse TLS, clés, retransmission et états de service.

Le piège commence avec une observation apparemment nette : après retrait de la protection de paquet QUIC, un observateur voit une trame CRYPTO et lui attribue un événement ClientHello ou Finished complet. Or QUIC ne fournit que l’offset, la longueur et le niveau de chiffrement de cette portion de données. La trame transporte des octets de négociation cryptographique ; elle ne déclare pas la frontière d’un message TLS.

La trame tient entièrement dans un paquet QUIC, mais cela ne rend pas la négociation de taille paquet. Un message TLS ou une séquence de messages peut traverser plusieurs trames CRYPTO et plusieurs paquets. À l’inverse, une seule trame peut commencer au milieu d’un message et se terminer avant sa fin. Lorsqu’une information cryptographique perdue est renvoyée, elle est reframée dans de nouvelles trames CRYPTO protégées avec les clés du même niveau de chiffrement que les octets d’origine. Des limites différentes ne prouvent donc ni un second message ni une répétition sémantique.

Le flux n’est pas global à la connexion. Chaque niveau de chiffrement possède son propre flux CRYPTO, avec des offsets commençant à zéro. Initial, Handshake et 1-RTT peuvent transporter CRYPTO ; 0-RTT ne le peut pas. Deux offsets égaux à des niveaux différents ne désignent pas une même position. QUIC assemble les octets par niveau, conserve les trous et peut retenir les données d’un niveau futur jusqu’à ce que TLS soit prêt. Les octets devenus contigus sont ensuite remis à TLS dans l’ordre.

Cette chaîne distingue clairement les responsabilités. QUIC gère l’ordre, les pertes et le tamponnage des octets hors ordre. TLS gère le tamponnage des octets livrés dans l’ordre et l’analyse des messages complets. TLS peut avancer progressivement ou attendre un message ou une séquence de messages complète. Le résultat du retrait de la protection de paquet ne vaut donc pas résultat d’analyse TLS. La disponibilité d’une clé vient du traitement TLS ; elle n’est pas établie par la seule présence d’une trame. La trame ne prouve pas davantage qu’une clé a été installée.

Le registre d’exploitation doit refléter cette séparation. Il peut consigner la version QUIC, le type de paquet, l’espace de numéros de paquets, le niveau de chiffrement, le résultat de la protection de paquet et le numéro de paquet. Il peut ensuite consigner offset, longueur et empreinte de données respectueuse de la vie privée. Il faut distinguer la plage contiguë reçue, les trous gardés par QUIC et la plage livrée à TLS. Un type de message TLS ne devrait apparaître qu’après l’analyse d’un message complet.

CRYPTO ne transporte que des messages de négociation TLS. Les alertes TLS sont associées à des codes d’erreur QUIC CONNECTION_CLOSE ; les données applicatives et les autres types de contenu TLS ne peuvent pas être transportés dans des trames CRYPTO. CRYPTO ne possède ni contrôle de flux, ni identifiant de flux, ni FIN, ni fin explicite. Les implémentations doivent accepter au moins 4096 octets CRYPTO hors ordre ; un offset maximal excessif peut produire FRAME_ENCODING_ERROR ou CRYPTO_BUFFER_EXCEEDED. Ces mécanismes concernent le transport et la protection des ressources.

Ils ne constituent pas des résultats de validation de certificat, de changement de clé ou de disponibilité applicative.

Une transition de niveau impose aussi de la rigueur. Si TLS passe à un niveau supérieur alors que des données de l’ancien niveau restent non consommées par TLS, l’extrémité traite la situation comme PROTOCOL_VIOLATION. La suppression des clés Initial ou Handshake entraîne la suppression des données correspondantes, mais ne marque pas la fin sémantique d’un message TLS. De même, la fin de la négociation TLS n’existe que lorsque la pile TLS la signale après son Finished et la vérification du Finished pair. La confirmation QUIC et la disponibilité applicative sont des états ultérieurs et distincts.

Cette frontière évite aussi cinq confusions voisines. TR-048 porte sur la confirmation de négociation et la disponibilité applicative. TR-049 porte sur la coalescence de paquets dans un datagramme UDP. TR-045 porte sur ce que prouve un accusé de réception. TR-056 porte sur la reconstruction des numéros de paquets. TR-063 porte sur la migration vers une adresse préférée. Aucun de ces axes ne transforme une portion CRYPTO en message TLS complet.

La règle éditoriale et opérationnelle est donc de réclamer une preuve au niveau où l’on formule l’affirmation. Une trame prouve le transport d’une plage d’octets protégée à un niveau donné. Le réassemblage prouve une continuité par niveau. Le parseur TLS prouve un message complet. Les états de certificat, de clé, de fin TLS, de confirmation QUIC et de disponibilité applicative exigent leurs propres reçus.