Résumé

  • draft-ietf-tls-tlsflags-18 regroupe jusqu’à 2 040 indications sans contenu dans une seule extension TLS. Il s’agit d’un Internet-Draft actif visant Proposed Standard, encore à l’état I-D Exists, et non d’un RFC ou d’un rapport de déploiement.
  • Un bit peut exprimer une capacité ou une intention, une proposition, un acquittement ou une annonce non sollicitée autorisée. La spécification de chaque indicateur fixe son sens, son besoin de réponse et son comportement avec 0-RTT.
  • Daniel Kade propose une enveloppe d’interprétation qui relie le bit au message, au rôle, au sens, au transcript, à la révision normative et à la décision locale. Ce contrôle éditorial n’est pas une exigence de l’IETF.

Le responsable sécurité demandait une réponse simple : le serveur prenait-il en charge la fonctionnalité ? Le lac de données possédait une ligne TLS et un bit à un. L’analyste répondit oui.

Puis quelqu’un demanda où le bit avait été trouvé. Était-ce une proposition du client dans ClientHello, une réponse du serveur dans EncryptedExtensions, ou une annonce placée dans NewSessionTicket ? Fallait-il même une réponse pour cet indicateur ? La connexion était-elle reprise, avec des données précoces ? Le système avait supprimé ces dimensions au moment de l’ingestion.

Le booléen était exact au niveau du stockage et indéterminé au niveau de la décision.

Une révision d’entretien, pas un changement d’autorité

La fiche Datatracker présente la révision 18, publiée le 10 septembre 2026, comme un Internet-Draft actif du groupe TLS visant le niveau Proposed Standard. L’état IESG reste I-D Exists et l’état du groupe Waiting for Implementation. Aucun Area Director responsable ni aucune téléconférence IESG n’est renseigné.

La chronologie et la comparaison officielle 17→18 empêchent une lecture exagérée de la date. La nouvelle révision actualise le numéro, la date et l’expiration. Elle ne modifie pas les règles opératoires. Elle prolonge le travail jusqu’en mars 2027 sans produire un RFC, une preuve d’interopérabilité ni un constat d’adoption.

Le groupe TLS traite néanmoins un coût réel. Une extension dont la seule information est sa présence occupe quatre octets. Répéter ce format pour chaque fonctionnalité facultative gaspille de l’espace. Un conteneur de bits mutualise le coût. Le gain syntaxique est clair ; l’état de chaque fonctionnalité reste extérieur au conteneur.

La position du bit est standardisée, pas son histoire

La révision 18 définit une chaîne de un à 255 octets, soit 2 040 positions. Dans chaque octet, le premier indicateur occupe le bit de poids faible. La longueur doit s’arrêter à l’octet contenant le dernier bit à un. Une valeur entièrement nulle ou terminée par des octets nuls déclenche une alerte fatale illegal_parameter.

Cette canonicalisation résout un problème de lecture. Deux implémentations peuvent repérer le même indicateur et refuser une représentation ambiguë. Elle ne transforme pas l’indicateur en verdict uniforme.

Le projet dit qu’une fonctionnalité de type flag est facultative et que la présence de son extension vide, ou de son bit, indique une prise en charge ou une intention d’emploi. Ces deux expressions couvrent déjà plusieurs états. Être capable ne veut pas dire proposer sur cette connexion. Proposer ne veut pas dire recevoir un acquittement. Être acquitté ne veut pas dire être exercé. Être exercé ne veut pas dire être autorisé par la politique de l’application.

La spécification propre à chaque bit doit donc rester jointe à l’observation.

Le message transforme le verbe

Un indicateur non sollicité peut apparaître dans ClientHello, CertificateRequest ou NewSessionTicket. Dans ServerHello, EncryptedExtensions, Certificate ou HelloRetryRequest, le même type de bit doit répondre à une proposition antérieure conforme. S’il apparaît sans cette origine, le pair doit interrompre la négociation.

La position change ce que l’événement dit.

Dans ClientHello, le client propose. Dans une réponse du serveur, le bit peut acquitter cette proposition, mais seulement si la spécification particulière prévoit un acquittement. Dans NewSessionTicket, l’annonce du serveur ne reçoit aucune réponse du client. Avec CertificateRequest puis Certificate, les rôles et le sens changent encore.

Une colonne supported=true efface ces verbes. Même offered/accepted impose une grammaire fausse aux indicateurs sans acquittement. L’issue 19 du dépôt du groupe a justement conclu que le conteneur ne devait pas rendre la réponse obligatoire : chaque indicateur définit son comportement.

Cette flexibilité est raisonnable pour le protocole. Elle oblige le système de preuve à conserver davantage de contexte.

Un acquittement identique ne prouve pas l’exécution

Lorsqu’une réponse est exigée, elle doit reprendre le même bit dans tls_flags. Si la réponse a besoin de données, la fonctionnalité doit employer une extension structurée ; le conteneur de bits n’est pas adapté.

Cette règle limite volontairement la portée de l’acquittement. Deux bits correspondants attestent que les pairs ont suivi la convention de signalisation. Ils ne démontrent pas que l’application a atteint la condition d’emploi, que la fonctionnalité a réussi, qu’une identité a été acceptée ou qu’une politique locale a autorisé la conséquence.

Le précédent de RFC 8446 est parlant. post_handshake_auth indique que le client accepte le principe d’une authentification ultérieure. Il ne prouve ni qu’un CertificateRequest a été envoyé, ni que le client a répondu, ni que l’application a accordé un droit. Le signal ouvre une possibilité ; les événements suivants établissent l’état.

0-RTT interdit la projection rétroactive

Une reprise TLS 1.3 peut transporter des données 0-RTT avant la fin du nouveau handshake. Le projet autorise son conteneur dans les messages concernés mais ne donne pas un sens précoce universel à tous les bits futurs. Chaque document définissant un indicateur doit expliquer son interaction avec 0-RTT.

L’issue 16 formule nettement la séparation : tls_flags est un cadre d’encodage ; les extensions triviales qu’il représente restent responsables de leur sémantique 0-RTT. Une fonctionnalité peut être mémorisable dans la session, une autre exiger une décision fraîche, une troisième ne concerner que des tickets à venir.

Si le collecteur garde seulement true, il risque d’appliquer au trafic précoce une décision obtenue plus tard. Pour une mesure d’usage, l’erreur déplace une statistique. Pour une décision d’identité ou de sécurité, elle attribue aux premiers octets une autorité qui n’existait pas encore.

Il faut conserver handshake complet ou repris, offre et acceptation 0-RTT, ticket concerné, spécification de l’indicateur et instant de la décision.

La visibilité dépend de l’endroit où le bit voyage

Le projet rappelle qu’un acquittement dans ServerHello ou HelloRetryRequest est visible à un observateur passif. Il recommande généralement un message chiffré lorsque cette exposition n’est pas nécessaire.

Ainsi, « absent » n’a de sens qu’avec un point d’observation. Une sonde réseau peut lire un indicateur clair sans voir celui d’EncryptedExtensions. Le journal d’un endpoint voit le transcript déchiffré mais possède une autre autorité et une autre obligation de rétention. Un proxy terminant TLS voit sa propre négociation, pas nécessairement celle entre d’autres participants.

Le lieu du message est une coordonnée technique et une frontière de confidentialité. Le supprimer revient à faire passer l’ignorance du capteur pour le silence du pair.

Le registre oriente l’interprétation, il n’atteste pas la réalité

La révision 18 demande un registre TLS Flags contenant Value, Flag Name, Message, Recommended et Reference. Les valeurs 0 à 15 relèveraient de Standards Action ; 16 à 2039 de Specification Required selon RFC 8126. L’entrée initiale proposée est le bit 8 resumption_across_names, dans NewSessionTicket, avec Recommended N.

Au moment de la recherche, le registre IANA ExtensionType comporte déjà une ligne distincte pour le conteneur tls_flags : valeur 62, messages CH/SH/HRR/EE/CR/CT/NST, Recommended N, référence à la révision 14. C’est une photographie du registre, pas un certificat de prise en charge d’un bit chez un fournisseur.

RFC 8447 précise que N ne signifie pas nécessairement « défectueux ». L’usage peut être limité, spécifique, ou ne pas avoir reçu le consensus requis. La validation d’un expert désigné n’est pas une approbation opérationnelle. L’issue 32 a en outre conduit le projet à aligner la colonne sur la gamme Y/N/D et à éviter qu’un seul document soit supposé figer éternellement la recommandation.

Les travaux 8446bis et 8447bis restent eux-mêmes des projets. Un registre donne une coordonnée et une référence. Il ne remplace ni le transcript, ni l’exécution, ni la politique du déploiement.

Une erreur fatale reste une preuve bornée

Un encodage non minimal, une valeur nulle ou un indicateur placé dans une réponse sans proposition peut justifier l’arrêt du handshake. Le résultat est précieux : il relie des octets à une règle et à une alerte.

Il ne révèle pas automatiquement la cause. Bibliothèque obsolète, instantané IANA périmé, sérialiseur fautif, expérience mal configurée et entrée hostile peuvent produire un symptôme voisin. Écrire « fonctionnalité défaillante » confond observation et diagnostic.

La forme défendable est plus précise : rôle émetteur, message, direction, octets ou leur empreinte, version du parseur, règle violée, alerte produite et éléments disponibles pour l’enquête. La cause et le propriétaire de la correction restent des champs séparés.

L’enveloppe d’interprétation

Daniel Kade propose d’attacher à chaque indicateur une enveloppe d’interprétation.

Elle relie une référence bornée au transcript, la version TLS, le caractère complet ou repris du handshake, l’état de 0-RTT, le rôle et le sens, le message exact, la valeur du conteneur, l’empreinte de la chaîne brute, sa longueur canonique, la position du bit, l’instantané du registre et la révision du document qui définit le bit.

Elle indique ensuite si l’événement propose, acquitte ou annonce sans sollicitation ; si une réponse est requise ; quelle proposition antérieure est correspondante ; et quel résultat de validation a été observé. Elle sépare visibilité passive et connaissance d’endpoint, puis conserve les versions du parseur et de la politique.

Enfin, elle décrit ce qui a réellement suivi : compréhension, sélection, exercice, échec, remplacement ou inconnu. Elle nomme la décision autorisée, son propriétaire, les consommateurs, la rétention, l’incertitude, l’expiration et la preuve de clôture.

Cette enveloppe n’appartient pas au projet IETF. Elle ne demande pas d’exporter des secrets. Elle empêche simplement un système aval de prendre un bit exact pour un état qu’aucun participant n’a attesté.

Monter l’échelle des affirmations

« Bit 8 vu dans NewSessionTicket » est une observation. « Le serveur annonce la reprise entre noms selon la révision R » est une interprétation. « Le client a tenté la reprise » est un événement ultérieur. « Le serveur l’a acceptée sous la politique P » est une décision. « L’application a accordé un droit » exige encore une autre preuve.

L’économie d’octets mérite d’être conservée. L’économie de contexte, elle, transforme une syntaxe compacte en conclusion excessive. Un indicateur TLS peut prouver la présence d’un bit dans un message. Il ne constitue pas à lui seul le relevé d’état d’une fonctionnalité.

Sources