Résumé

  • La révision 03 est un Internet-Draft actif, et non un RFC ni une preuve de déploiement ou d’interopérabilité.
  • Chaque pair annonce la taille maximale de texte clair interne qu’il accepte de recevoir ; cette valeur est directionnelle et ne réserve aucune ressource.
  • La diminution du nombre d’en-têtes peut coexister avec plus d’attente, de mémoire occupée ou de coût de retransmission.
  • Les limites d’usage AEAD doivent être recalculées lorsque la taille possible des enregistrements change.

L’économie de fil ne signe pas le délai

TLS 1.3 et DTLS 1.3 bornent normalement le texte clair interne à 2^14 + 1 octets. Le projet propose l’extension large_record_size_limit, dont la valeur valide va de 64 à 2^30 - 256. Son intérêt est intelligible : transporter davantage de données sous une même protection peut réduire la répétition des en-têtes et des opérations associées.

Mais le temps gagné sur un en-tête n’est pas automatiquement rendu à l’application. Un grand enregistrement doit arriver, être authentifié et être intégré au traitement local. Sur un chemin propre, ce regroupement peut servir le débit. Sur un chemin soumis à la perte, ou pour un échange interactif, il peut repousser le premier octet authentifié utile et maintenir davantage de données dans les files.

La bonne mesure relie donc taille d’enregistrement, temps d’arrivée, durée d’authentification, résidence en file, pression mémoire et achèvement applicatif. Le rapport entre octets utiles et octets d’en-tête ne suffit pas. Il décrit une efficacité d’encapsulation, pas une expérience de service.

Deux annonces, deux sens

Le mécanisme ne choisit pas un maximum commun. Le client indique ce qu’il accepte de recevoir du serveur ; le serveur indique ce qu’il accepte de recevoir du client. Les valeurs peuvent être différentes sans contradiction.

Un pair peut même envoyer un enregistrement plus grand que la limite qu’il a annoncée pour sa propre réception, dès lors qu’il respecte la limite annoncée par l’autre pair. Cette phrase paraît paradoxale seulement si l’observabilité a supprimé le sens du trafic. Une colonne unique nommée « limite TLS » est donc une perte de preuve.

Chaque événement doit garder le rôle de l’extrémité, le sens, la politique locale, la valeur envoyée, celle reçue et la taille effectivement authentifiée. Sans cette filiation, un dépassement réel peut être masqué par la valeur de l’autre sens, tandis qu’un envoi parfaitement conforme peut être étiqueté comme anomalie.

L’annonce reste un plafond. Elle ne demande pas au pair de le remplir. Le choix d’envoyer plus petit appartient encore à l’émetteur, selon le trafic, la latence recherchée, la mémoire ou le rythme de l’application.

La mémoire n’est pas dans l’extension

Accepter une valeur élevée ne signifie pas que l’implémentation a réservé autant d’octets pour chaque connexion. Elle peut employer des pools, un traitement progressif, une limitation globale ou une stratégie de retour de pression. À l’inverse, la réussite d’un enregistrement maximal isolé ne prouve pas que mille connexions lentes peuvent conserver chacune un enregistrement incomplet.

Le modèle de capacité doit inclure les octets en vol, les fragments internes, le texte chiffré, l’état d’authentification, le texte clair retenu, la réassemblage supérieur, le remplissage et les demandes annulées. Il doit surtout tester la concurrence contrôlée par un adversaire : beaucoup de débuts d’enregistrement, peu de fins, et des allocations qui vivent plus longtemps que prévu.

Le plafond protocolaire n’est donc pas un conseil de configuration. Le maximum de 2^30 - 256 décrit la syntaxe proposée. Une limite de production doit découler du service, de son allocateur, de son ordonnanceur et de sa politique d’échec.

Le remplissage appartient aussi à la limite

Dans TLS 1.3, le texte clair interne comprend le type de contenu et peut contenir du remplissage. Tous ces octets comptent. Une charge applicative qui tiendrait seule sous le plafond peut devenir trop grande après l’ajout du remplissage.

Ce détail révèle une séparation utile entre les propriétaires. La politique de confidentialité peut choisir le remplissage ; l’équipe applicative choisit les unités de travail ; TLS applique la limite du pair. Si chacun ne compte que ses octets « utiles », personne ne vérifie l’enveloppe finale.

Une valeur d’extension inférieure à 64 ou supérieure à 2^30 - 256 impose une alerte fatale illegal_parameter. Ce verdict établit que la négociation est invalide. Il n’établit ni la source de configuration fautive ni une valeur de repli légitime.

Le dépassement n’a pas le même destin

Pour TLS, recevoir un enregistrement plus grand que la limite applicable conduit à une alerte fatale record_overflow. Le flux ordonné s’arrête. Cette conséquence doit apparaître dans les objectifs de disponibilité : une divergence de politique peut couper une session longue.

Pour DTLS, le projet dit que l’enregistrement surdimensionné devrait être abandonné et ne devrait pas déclencher d’alerte fatale. Le datagramme peut être perdu sans que l’association entière soit détruite, et une réponse fatale à du trafic malveillant peut aggraver le déni de service.

Un contrôle commun qui exige la même réponse pour TLS et DTLS produit donc de faux écarts. Il faut enregistrer le protocole, l’époque, la direction, la taille observée, le plafond, l’action et l’alerte éventuelle. « Rejeté » ne suffit pas à distinguer fermeture et abandon silencieux.

La frontière de l’application reste ailleurs

Un enregistrement TLS n’est pas nécessairement un message applicatif. Un message peut traverser plusieurs enregistrements, et un enregistrement peut contenir des portions que le protocole supérieur traitera séparément. Le transport peut encore segmenter l’enregistrement sur plusieurs paquets.

Le projet évoque l’intérêt de grands enregistrements pour éviter certains découpages supérieurs, notamment dans des usages DTLS à grands messages. Il ne promet pas qu’un objet applicatif tiendra toujours dans une unité, ni qu’il arrivera atomiquement. La congestion, la perte, le réassemblage et l’annulation gardent leurs propres règles.

Il faut donc suivre une chaîne de reçus : plafond annoncé, taille choisie, enregistrement reçu, authentification réussie, réassemblage terminé, message accepté, résultat observé. Compter seulement les négociations « compatibles grands enregistrements » gonfle le dénominateur du succès sans observer l’usage réel.

Le budget cryptographique change d’unité

Les limites de sûreté d’un AEAD dépendent de la construction, du nombre d’invocations et de la quantité de données protégées. Pour AES-GCM, le nombre de blocs a une importance directe. Le projet prévoit d’ajuster les calculs lorsque la taille autorisée dépasse celle du régime traditionnel, avec un facteur lié à LargeRecordSizeLimit / 2^14 et un comptage plus précis lorsque nécessaire.

Conserver un ancien seuil de KeyUpdate tout en augmentant fortement les octets par enregistrement peut donc rendre le tableau de bord trompeur. Le nombre d’enregistrements reste faible alors que le budget en blocs avance plus vite. Le contrôle doit connaître la suite cryptographique, le sens, l’époque de clé, les octets authentifiés et l’événement de rotation.

Ce besoin ne condamne pas les grands enregistrements. Il interdit seulement de réutiliser une preuve calculée pour une autre enveloppe. La négociation réussie ne signe pas la gouvernance des clés.

Une adoption progressive, par charge

Une équipe prudente commence par des plafonds adaptés aux classes de trafic, très en dessous du maximum de syntaxe. Elle teste séparément le vrac, l’interactif et les datagrammes. Elle mesure les queues et la mémoire avec des émetteurs lents, de la perte, du remplissage et de nombreux enregistrements incomplets.

Elle vérifie les deux sens et les deux protocoles. Elle aligne la rotation de clés. Elle définit aussi le retour arrière : une nouvelle annonce plus basse s’applique aux nouvelles négociations, sans réécrire magiquement l’état des connexions établies.

Les indicateurs doivent garder des dénominateurs explicites. Parmi les connexions ayant négocié l’extension, combien ont effectivement envoyé de grands enregistrements ? Parmi ces enregistrements, combien ont été authentifiés ? Parmi les messages réassemblés, combien ont produit le résultat attendu ? Chacune de ces questions porte sur un contrôle différent.

Sources et limites

Le dossier figé réunit la révision 03 et ses pages officielles, le groupe TLS, TLS 1.3 et son projet de révision, DTLS 1.3, l’extension existante de taille d’enregistrement, l’encapsulation DTLS/SCTP, MLS, QUIC, les exigences AEAD, les suites AES-GCM et le registre IANA TLS.

Ces sources établissent des textes de protocole et de registre. Elles n’établissent aucune implémentation livrée, adoption, interopérabilité, économie de mémoire, amélioration de débit ou de latence, panne, attaque ou réussite applicative. Le tableau de performance de l’ouverture est un cas construit.

Sources