Resumen

  • TLS partió de un máximo de 16 KiB y después permitió que el cliente escogiera un fragmento menor común a ambos sentidos. Esa simetría ocultaba que recibir y autenticar un registro completo suele ser la obligación de memoria decisiva.
  • RFC 8449 dio a cada extremo una declaración independiente de recepción. El emisor ajusta los registros enviados hacia ese receptor; el valor no mide la ruta ni limita el mensaje de la aplicación.

Una capacidad que cambia al invertir el sentido

Pensemos en un sensor que entrega datos gradualmente a un motor criptográfico. Para enviar, puede ir expulsando el cifrado. Para recibir, no debería entregar texto claro hasta verificar el registro protegido completo. Si expusiera un prefijo antes de autenticar el final, una falsificación podría provocar una acción que el posterior rechazo ya no desharía.

El tamaño asigna un coste: quien envía decide cuánto encierra en una unidad protegida; quien recibe aporta la memoria atómica para conservarla y comprobarla. Compartir protocolo no implica compartir hardware. RFC 8449 corrigió esa confusión al convertir el número en una afirmación del receptor, no en una propiedad simétrica del canal.

El máximo general y la primera reducción

TLS 1.2 fragmenta datos superiores en TLSPlaintext de hasta 2^14 bytes. Puede partir un mensaje entre registros o juntar varios del mismo tipo. Por eso, registro TLS, mensaje de aplicación, segmento TCP y paquete IP son fronteras distintas.

Los 16 KiB amortizaban cabeceras y criptografía, pero obligaban a prepararse para el peor registro permitido. La protección y la compresión podían ampliar todavía más el objeto transmitido. Para un equipo pequeño, el buffer de recepción podía condicionar todo el diseño.

max_fragment_length, aparecido en las extensiones de 2006 y conservado por RFC 6066, dejó que el cliente pidiera 512, 1024, 2048 o 4096 bytes. El servidor que aceptaba debía repetir exactamente el valor; desde entonces ambos fragmentaban datos y handshake dentro de ese máximo, también durante la sesión reanudada conforme a aquel contrato.

El perfil IoT RFC 7925 explicó su beneficio: un cliente limitado podía reducir la RAM destinada a registros entrantes en lugar de aceptar los 16 KiB normales. La restricción dejó de ser una sorpresa privada.

Un solo valor cobraba el coste a los dos sentidos

El diseño antiguo expresaba como máximo 4096, muy por debajo de 16384. Un cliente capaz que ofreciera la extensión podía degradar el rendimiento sin necesidad: más registros repiten cabeceras, expansión criptográfica y trabajo.

Además, el servidor no podía responder con un límite menor propio. El cliente proponía y el mismo valor gobernaba ida y vuelta. Sin embargo, la limitación suele pertenecer a quien recibe. Un extremo puede cifrar y transmitir de forma incremental y no poder autenticar un gran registro entrante sin almacenarlo entero.

La cifra compartida parecía neutral, pero callaba al servidor y convertía dos capacidades distintas en una sola.

El nuevo número mira hacia el extremo que lo anuncia

record_size_limit expresa el máximo plaintext protegido que el anunciante acepta recibir en un registro. Su par debe respetarlo al enviar hacia él. El anunciante puede usar registros mayores en sentido contrario si respeta el límite del otro extremo y el máximo general de la versión.

Así, una conexión admite dos cifras. Un dispositivo pequeño exige respuestas fragmentadas y todavía puede enviar unidades mayores a un servicio con memoria abundante. Un servidor limitado puede declarar su propia necesidad. Incluso a los extremos sin restricción se les recomienda anunciar la extensión, porque permiten que el otro lado responda con un límite utilizable.

Si TLS recibe un registro protegido superior a lo anunciado, termina con record_overflow fatal. DTLS también puede descartar el registro. No se admite un valor inferior a 64, pero 64 no es una recomendación. Los registros excesivamente pequeños aumentan trabajo, reducen rendimiento y pueden agravar el riesgo de denegación de servicio.

El límite cuenta el interior protegido

En TLS 1.2 y anteriores, la cifra cubre la entrada a compresión y cifrado; el padding añadido por el cifrado queda fuera de esa cuenta. En TLS 1.3, abarca todo TLSInnerPlaintext: contenido, tipo interno y padding del registro.

TLS 1.3 puede rellenar para ocultar longitudes, pero ese relleno consume la capacidad declarada. La privacidad y la carga útil comparten presupuesto. Los mensajes no protegidos no están sujetos a la extensión. En reanudación o renegociación antigua, el límite se vuelve a negociar y pertenece al handshake que creó las claves protectoras.

La memoria del receptor no es la ruta

Un límite pequeño puede parecer PMTU porque ambos producen unidades menores. RFC 8449 los separa. El límite de registro nace en el extremo y queda fijado en el handshake; la PMTU nace en la ruta, gobierna paquetes y puede cambiar. Varios registros DTLS pequeños aún pueden compartir un datagrama UDP.

Tampoco limita una respuesta HTTP, una cadena de certificados o un mensaje, que pueden ocupar varios registros. No promete ancho de banda, capacidad de cálculo, tamaño de código, batería ni seguridad superior. Resuelve una obligación concreta de asignación y autenticación.

IANA marca hoy record_size_limit (28) como Recommended y max_fragment_length (1) como no recomendado. El registro normaliza el mecanismo, pero no demuestra que un producto lo implemente ni cuál sea la cifra adecuada.

La lección histórica no exige máquinas iguales. Exige que cada receptor pueda declarar la frontera que conoce y que el emisor la respete justo en el sentido donde recae el coste.

Fuentes y límites

La base documental es RFC 4366, RFC 5246, RFC 6066, RFC 7925, RFC 8446, RFC 8449 y el registro IANA. No miden despliegue, RAM de productos ni un tamaño óptimo universal.