Résumé

  • TLS autorisait des fragments de 16 Kio, puis max_fragment_length a laissé le client choisir une valeur plus petite, identique dans les deux sens. Ce compromis masquait une contrainte souvent propre au récepteur.
  • RFC 8449 a remplacé ce réglage symétrique par deux déclarations directionnelles : chacun annonce le record protégé qu’il peut recevoir, et l’émetteur adapte uniquement le trafic qui va vers lui.

Deux sens, deux coûts de mémoire

Un objet embarqué peut alimenter un moteur de chiffrement au fil de l’eau et évacuer le résultat aussitôt. À la réception, il doit souvent disposer du record protégé entier avant d’en authentifier le contenu. Livrer un préfixe non vérifié à l’application reviendrait à laisser une contrefaçon produire un effet avant que le contrôle final ne la découvre.

La taille d’un record répartit donc une charge. L’émetteur décide combien de données placer dans une unité protégée ; le récepteur paie la mémoire nécessaire pour la retenir et la valider. Deux rôles protocolaires équivalents peuvent reposer sur des matériels radicalement différents.

C’est cette dissymétrie que RFC 8449 a fini par inscrire dans TLS. La réforme ne consistait pas seulement à réduire un nombre, mais à faire de ce nombre la parole du récepteur concerné.

Le plafond de 16 Kio

TLS 1.2 découpe les données des couches supérieures en TLSPlaintext de 2^14 octets au plus. Un message applicatif peut traverser plusieurs records ; plusieurs messages du même type peuvent aussi partager un record. La frontière TLS n’est donc ni celle d’une requête, ni celle d’un segment TCP, ni celle d’un paquet IP.

Un record généreux amortit en-têtes et opérations cryptographiques. Il oblige cependant le pair à se préparer au pire cas. La compression et la protection peuvent encore agrandir l’objet transporté. Pour un appareil à faible RAM, réserver de quoi accepter le maximum pouvait devenir une part majeure du produit.

Le premier remède, paru dans les extensions TLS de 2006 puis repris par RFC 6066, s’appelait max_fragment_length. Le client demandait 512, 1024, 2048 ou 4096 octets. Si le serveur acceptait, il devait renvoyer exactement la même valeur, puis les deux côtés fragmentaient immédiatement données et messages de poignée de main. La limite demeurait pendant la session, reprise comprise selon ce modèle.

Cette solution a servi. Le profil IoT RFC 7925 y voyait un moyen de ne pas imposer à un client contraint des buffers capables d’absorber les 16 Kio du TLS ordinaire. Une limite cachée dans le matériel devenait enfin visible à son interlocuteur.

La symétrie qui empêchait le serveur de parler

Le mécanisme portait pourtant ses propres freins. Sa plus grande valeur, 4096, restait très inférieure au plafond normal de 16384. Un client sans contrainte risquait donc de réduire inutilement les records en offrant l’extension. Or davantage de records signifie davantage d’en-têtes, d’expansion cryptographique et de traitements.

Surtout, le serveur ne pouvait pas annoncer un plafond inférieur à la proposition du client. Et la valeur négociée valait dans les deux sens, alors que l’obligation est fréquemment liée à la réception. On peut chiffrer et émettre progressivement tout en étant incapable d’authentifier un gros record entrant sans le conserver entier.

Le réglage commun paraissait égalitaire ; il fusionnait en réalité deux capacités différentes et réservait l’initiative au client.

Une déclaration tournée vers soi

Avec record_size_limit, la valeur signifie : « voici la taille maximale de plaintext protégé que je consens à recevoir dans un record ». Le pair ne doit pas dépasser cette valeur dans les records qu’il envoie vers le déclarant. Dans l’autre sens, celui-ci peut produire des records plus grands, à condition de respecter la déclaration adverse et le plafond de la version TLS.

Une seule connexion peut ainsi porter deux limites. Un capteur impose de petits records au service qui lui répond, sans réduire nécessairement ce qu’il envoie à un centre de données bien doté. Un serveur contraint peut, lui aussi, exprimer sa capacité. Même une extrémité sans besoin particulier est encouragée à offrir l’extension : elle ouvre alors la voie à la déclaration du pair.

La conséquence est locale et déterminée. Un record TLS dépassant la limite annoncée entraîne un record_overflow fatal. En DTLS, le récepteur peut aussi rejeter seulement le record. Une valeur inférieure à 64 est illégale ; 64 n’est pas pour autant un conseil de performance. RFC 8449 prévient que des records minuscules multiplient le travail, réduisent le débit et peuvent favoriser le déni de service.

Ce que le compteur inclut

Sous TLS 1.2 et les versions antérieures, la limite vise l’entrée de la compression et du chiffrement ; le bourrage ajouté par le chiffrement n’est pas compté de la même façon. Sous TLS 1.3, elle couvre tout le TLSInnerPlaintext, donc le contenu, l’octet de type interne et le bourrage TLS 1.3.

Le bourrage peut atténuer l’observation des longueurs, mais il ne contourne pas la capacité annoncée. La confidentialité de forme consomme le même budget entrant que les données. Les messages non protégés restent hors de cette extension. Lors d’une reprise ou d’une renégociation ancienne, la limite est renégociée et s’attache à la poignée de main qui a produit les clés du record.

Ni MTU, ni taille de message

Une limite plus petite et une PMTU plus petite conduisent toutes deux à émettre des unités réduites, mais ne constituent pas la même preuve. La première vient de la mémoire de l’extrémité et se fixe pendant la poignée de main. La seconde vient du chemin réseau, contraint les paquets et peut évoluer en cours de connexion. Plusieurs petits records DTLS peuvent encore tenir dans un même datagramme UDP.

L’extension ne borne pas davantage une réponse HTTP, une chaîne de certificats ou un message applicatif, qui peuvent traverser plusieurs records. Elle ne résout ni la taille du code, ni le calcul, ni la bande passante, ni toute pénurie de mémoire. Elle encadre une seule obligation atomique : le plaintext protégé que le récepteur traite comme un record.

Le registre IANA classe aujourd’hui record_size_limit (28) comme Recommended et max_fragment_length (1) comme non recommandé. Ce statut organise l’interopérabilité ; il ne mesure ni le déploiement ni la qualité des implémentations.

L’histoire est celle d’une fausse symétrie abandonnée. TLS n’avait pas à rendre les machines égales. Il devait permettre à chacune de décrire la limite qu’elle seule connaissait, puis faire respecter cette limite dans le sens où le coût allait tomber.

Sources et limites de preuve

L’analyse repose sur RFC 4366, RFC 5246, RFC 6066, RFC 7925, RFC 8446, RFC 8449 et le registre IANA des extensions TLS. Ces textes ne fournissent ni taux de déploiement actuel, ni profil RAM des produits, ni taille optimale universelle.