Resumen

  • La revisión 03 es un Internet-Draft activo, no un RFC ni evidencia de implementación, despliegue o interoperabilidad.
  • Cada extremo anuncia cuánto texto plano interno está dispuesto a recibir; los valores pueden ser distintos y nunca forman automáticamente un único máximo compartido.
  • El techo no reserva memoria, no obliga a llenarlo y no demuestra que el mensaje de aplicación complete su recorrido.
  • Aumentar el tamaño posible modifica la contabilidad de uso AEAD y exige revisar la política de actualización de claves.

La dirección es parte del dato

TLS 1.3 y DTLS 1.3 suelen limitar el texto plano interno a 2^14 + 1 octetos. La propuesta large_record_size_limit permite que cada parte anuncie un valor entre 64 y 2^30 - 256. La palabra decisiva es «recibir».

El valor del cliente regula lo que el servidor puede enviarle. El valor del servidor regula lo que el cliente puede enviarle. Un extremo puede transmitir legítimamente un registro mayor que el límite que anunció para su propia recepción, siempre que respete la cifra del par. No hay contradicción: son contratos en sentidos opuestos.

Por eso una base de datos con una columna única pierde autoridad. El evento mínimo necesita conexión, rol, sentido, política local, valor anunciado, valor recibido y longitud real del registro autenticado. Sin esos campos, el mismo número puede describir una obligación del cliente o del servidor, y el análisis no sabe cuál.

Un techo no pide que se lo alcance

El receptor comunica un máximo aceptable. El emisor conserva la decisión sobre el tamaño concreto de cada registro. Puede usar unidades menores por latencia, por ritmo de la aplicación, por pérdida esperada, por presión de memoria o por su propia estrategia de envío.

Confundir techo y objetivo crea una optimización peligrosa: llenar cada registro para reducir encabezados, aunque el trabajo interactivo necesite autenticación temprana. La extensión amplía el espacio permitido; no reemplaza la política de agrupación ni promete mejor rendimiento.

El mismo cuidado vale para los extremos del intervalo. Un valor menor que 64 o mayor que 2^30 - 256 causa una alerta fatal illegal_parameter. Ese resultado certifica una negociación inválida, no una recomendación para redondear el dato ni una autorización para continuar con un valor inventado.

La memoria tiene otra autoridad

Aceptar en el protocolo un registro grande no significa asignar un búfer dedicado del mismo tamaño. Una biblioteca puede procesar de forma incremental, compartir pools, limitar la memoria global o aplicar contrapresión. También puede superar una prueba con un registro máximo y fallar bajo muchos emisores lentos que mantienen estados parciales simultáneos.

La capacidad real depende de concurrencia, bytes cifrados pendientes, contexto AEAD, texto plano retenido, padding, reensamblado superior, colas de aplicación y cancelaciones. El protocolo no conoce el presupuesto del host ni las prioridades del servicio.

Una evaluación seria introduce carga adversaria: conexiones que empiezan registros grandes y los terminan despacio, límites asimétricos, padding variable y mensajes que se abandonan tarde. El resultado se expresa como curva de ocupación y política de sobrecarga, no como copia del máximo negociado.

El padding también ocupa el sobre

El límite se aplica al texto plano interno de TLS 1.3. Ese contenido incluye el tipo y puede incorporar padding. Si la carga visible queda justo por debajo del techo, los bytes añadidos pueden convertirla en un registro excesivo.

Esto rompe otra simplificación del panel: medir solamente bytes de aplicación. La privacidad puede decidir cuánto padding añadir; TLS debe respetar el máximo del par; la plataforma paga la memoria y el cifrado. El recibo necesita el tamaño completo, aunque no registre el contenido sensible.

También conviene distinguir longitud interna, longitud del cifrado y segmentación de transporte. Un registro grande puede viajar en muchos segmentos TCP o paquetes de otra capa. Reducir el número de registros no demuestra reducir el número de paquetes.

TLS termina; DTLS normalmente descarta

La consecuencia de un registro demasiado grande depende del protocolo. En TLS, el receptor debe emitir una alerta fatal record_overflow; la conexión no continúa como si el registro nunca hubiera existido.

En DTLS, el borrador indica que el datagrama excesivo debería descartarse y que no debería generarse una alerta fatal. La pérdida ya forma parte del modelo de datagramas, y responder de forma destructiva a tráfico que puede ser hostil aumenta la superficie de denegación de servicio.

Un monitor que espera la misma señal en ambos mundos interpreta mal el cumplimiento. Debe registrar protocolo, época, sentido, longitud, límite y acción. Una ausencia de alerta en DTLS puede ser el comportamiento esperado, mientras que esa misma ausencia en TLS requiere investigación.

El registro no define el mensaje

La motivación del borrador incluye reducir encabezados repetidos y, en ciertos usos de DTLS, evitar fragmentación en capas superiores. No convierte los límites de registro en fronteras universales de la aplicación.

Un mensaje puede atravesar varios registros. Un registro puede contener datos que el protocolo superior separa. El transporte puede dividir todavía más la unidad protegida. La finalización exige observar autenticación, reensamblado, análisis de la aplicación, autorización y resultado.

Por eso «extensión negociada» no es un indicador de entrega. Tampoco lo es «registro recibido» si la autenticación falla o la aplicación rechaza el mensaje. Los denominadores deben avanzar etapa por etapa: conexiones que anunciaron, registros realmente grandes enviados, registros autenticados, mensajes completos y operaciones aceptadas.

Menos encabezados no fija la latencia

Agrupar más texto bajo una operación AEAD puede mejorar la eficiencia de cargas masivas. También puede retrasar el momento en que la aplicación obtiene contenido autenticado, aumentar la ocupación de colas o hacer más costosa una pérdida. El borrador no resuelve esa elección por el operador.

Hay que medir tiempo hasta autenticación, permanencia en cola, memoria por conexión, registros parciales concurrentes, colas de control detrás de unidades grandes y latencia final de la aplicación. Una media favorable puede ocultar una cola de percentil alto que empeora para tráfico interactivo.

Las políticas pueden necesitar perfiles distintos: volumen, control, streaming, datagramas grandes. Todos usan la misma sintaxis de negociación, pero no comparten una respuesta de servicio.

La clave ve bloques, no sólo registros

Los límites de seguridad de AEAD dependen de la construcción y de cuánto material se procesa. Para AES-GCM, los bloques cifrados importan de manera explícita. El borrador ajusta la contabilidad cuando los registros superan el tamaño tradicional, con un factor relacionado con LargeRecordSizeLimit / 2^14 y análisis de bloques cuando corresponde.

Si el equipo aumenta el techo y deja intacto un umbral histórico de KeyUpdate expresado sólo en número de registros, el control ya no describe el mismo consumo. Se necesitan suite, sentido, época de clave, bytes o bloques autenticados, recuento de registros y motivo de rotación.

No es una afirmación de que el mecanismo sea inseguro. Es una exigencia de coherencia: la prueba criptográfica debe usar la envolvente que realmente se autorizó.

Desplegar por etapas conserva la prueba

El máximo de la sintaxis no debe ser el valor inicial de producción. Conviene elegir techos por clase de trabajo, probar concurrencia y sobrecarga, y subirlos sólo con evidencia. TLS y DTLS requieren ensayos separados; los dos sentidos, también.

El retroceso merece diseño. Bajar la política cambia lo que se anuncia en nuevas sesiones, pero no borra el estado ya acordado en conexiones vivas. El plan debe decidir drenaje, compatibilidad y cómo distinguir un par sin soporte de una desactivación local.

El tablero final presenta una cadena, no una casilla: valor configurado, anuncio direccional, aceptación, tamaño elegido, autenticación, uso de recursos, mensaje reconstruido y resultado. Así el ahorro de encabezados puede evaluarse sin convertirlo en una promesa ajena.

Fuentes y límites

El paquete congelado contiene la revisión 03, su historial y referencias oficiales; el grupo TLS; TLS 1.3 y su borrador de actualización; DTLS 1.3; la extensión previa de límite de registro; DTLS sobre SCTP; MLS; QUIC; requisitos AEAD; suites AES-GCM; y el registro TLS de IANA.

Estas fuentes establecen texto de protocolo y registro. No prueban implementación, adopción, interoperabilidad, ganancia de rendimiento, ahorro de memoria, mejora de latencia, incidente ni resultado de aplicación. El panel inicial es un caso construido para mostrar la pérdida de dirección.

Fuentes