Resumen

  • draft-ietf-tls-tlsflags-18 permite empaquetar hasta 2.040 indicaciones sin contenido en una sola extensión. Sigue siendo un Internet-Draft activo con intención Proposed Standard y estado I-D Exists; la revisión 18 es mantenimiento, no un RFC nuevo.
  • El mismo bit puede comunicar soporte o intención, propuesta, acuse o anuncio permitido. El documento que define cada indicador fija los mensajes válidos, si exige respuesta y cómo interactúa con 0-RTT.
  • Daniel Kade propone un sobre de interpretación que conserve mensaje, rol, dirección, referencia, transcript, reanudación, resultado y decisión local. Es una propuesta editorial, no una obligación del IETF.

Un equipo de inventario quería saber cuántos servidores tenían habilitada una función TLS. El colector ya extraía el nuevo contenedor de indicadores, así que contar bits parecía suficiente. Después apareció una discrepancia: el mismo bit aumentaba en los tickets emitidos por el servidor, pero no en las conexiones donde el cliente intentaba usar la función.

El recuento no estaba roto. Había contado anuncios y los había llamado activaciones.

La diferencia no es una sutileza semántica. Decide qué puede afirmar un auditor, qué debe probar un incidente y si una automatización puede autorizar tráfico. El contenedor propuesto ahorra bytes al compartir el encabezado de muchas extensiones vacías. No convierte esas extensiones en un lenguaje de estado uniforme.

La fecha reciente no cambia la madurez

La ficha oficial identifica draft-ietf-tls-tlsflags-18, publicado el 10 de septiembre de 2026, como Internet-Draft activo del grupo TLS con destino Proposed Standard. Datatracker muestra I-D Exists en el IESG y Waiting for Implementation en el grupo. No hay AD responsable ni fecha de telechat.

La historia del documento y la comparación 17→18 ponen un límite necesario: la revisión más reciente actualiza fechas, número y expiración. No introduce el mecanismo, no aporta pruebas de interoperabilidad y no convierte el borrador en RFC.

El problema atendido por el grupo TLS es práctico. Una extensión cuyo único contenido es estar presente consume cuatro octetos. Si muchas funciones opcionales repiten esa forma, la sobrecarga crece. Un mapa de bits distribuye el coste fijo entre varias señales.

La eficiencia del formato no responde qué ocurrió después de emitir la señal.

Canonicalizar bytes no canonicaliza afirmaciones

La revisión 18 define de uno a 255 octetos y posiciones de indicador entre 0 y 2.039. Los bits se ordenan desde el menos significativo y la longitud termina en el octeto del último bit establecido. Un valor todo cero o con octetos cero finales es inválido y causa illegal_parameter fatal.

Dos implementaciones pueden así coincidir en la posición y detectar formas no mínimas. Ese contrato es valioso. Pero la definición de “flag-type feature” conserva una disyuntiva decisiva: la presencia expresa soporte o intención de uso.

Soportar una función describe una capacidad del software. Pretender usarla describe una elección para una interacción. Proponerla inicia un intercambio. Acusarla confirma una señal cuando el documento particular exige confirmación. Ejecutarla requiere otro hecho. Autorizar sus consecuencias pertenece a una política local.

Guardar solo el bit aplana toda la cadena.

ClientHello, NewSessionTicket y una respuesta no usan el mismo verbo

El borrador permite indicadores no solicitados en ClientHello, CertificateRequest y NewSessionTicket. En ServerHello, EncryptedExtensions, Certificate y HelloRetryRequest no pueden aparecer sin una propuesta anterior pertinente. El receptor debe terminar si recibe una respuesta no solicitada.

Esto hace que el mensaje sea parte del significado.

Un bit del cliente en ClientHello puede proponer una función. En ServerHello o EncryptedExtensions, el servidor puede reconocerla. En NewSessionTicket, el servidor emite una indicación que nunca recibe acuse dentro de ese intercambio. En la secuencia CertificateRequest/Certificate, el servidor propone y el cliente responde.

La columna habilitado no distingue ninguno de esos actos. Tampoco basta un modelo fijo “oferta/aceptación”, porque algunos indicadores no requieren respuesta. La issue 19 del repositorio TLS documenta precisamente la decisión de dejar el acuse a la especificación de cada indicador.

Por eso la ausencia de respuesta no es evidencia universal de rechazo. Puede ser el comportamiento correcto.

Un acuse solo acredita la regla de señalización

Cuando un indicador sí exige respuesta, la única respuesta válida en el contenedor es el mismo bit. Si la función necesita devolver datos estructurados, debe emplear otra extensión. Así se evita que un bit pretenda transportar una negociación que requiere contenido.

La coincidencia entre propuesta y acuse demuestra una parte: los pares observaron la regla prevista. No demuestra que la función se ejerciera más tarde, que produjera el efecto deseado ni que la política de una aplicación aceptara ese efecto.

RFC 8446 ofrece un ejemplo útil con post_handshake_auth. La extensión vacía indica que el cliente está dispuesto a autenticarse después del handshake. No prueba que el servidor enviara CertificateRequest, que el cliente presentara un certificado ni que el servicio concediera permisos. Un bit puede abrir una opción sin cerrar su resultado.

Un registro de estado necesita los eventos posteriores o debe conservar desconocido.

0-RTT conserva decisiones de tiempos distintos

En una reanudación TLS 1.3, el cliente puede enviar datos 0-RTT antes de completar el nuevo intercambio. tls_flags cabe en los mensajes de ese handshake, pero el contenedor no define una política temprana común para todos los indicadores futuros.

La issue 16 separó las responsabilidades: el contenedor resuelve codificación; cada extensión representada debe definir su relación con 0-RTT. Una función puede heredarse de un ticket. Otra puede exigir confirmación fresca. Otra puede anunciar algo que solo vale para una reanudación posterior.

Si el almacén quita el tipo de handshake, la oferta y aceptación de early data y el ticket de origen, un true posterior puede proyectarse hacia atrás. El informe termina atribuyendo a los primeros datos una garantía que aún no existía.

La pregunta correcta no es solo “¿estaba el bit?”. Es “¿qué versión de qué regla gobernaba qué bytes en qué momento?”.

No observado depende del punto de observación

El borrador advierte que las respuestas en ServerHello y HelloRetryRequest son visibles para observadores pasivos. Salvo una razón concreta, conviene ubicar los acuses en mensajes cifrados.

Un sensor de red y un endpoint no producen el mismo tipo de evidencia. El sensor puede ver un ServerHello claro y quedar ciego ante EncryptedExtensions. El endpoint ve el transcript descifrado, pero su registro proviene de una posición privilegiada. Un terminador TLS documenta su propio tramo, no necesariamente la conexión del siguiente salto.

Por ello, “indicador ausente” sin punto de observación es una afirmación incompleta. Puede significar que el par calló, que el mensaje estaba cifrado, que la captura empezó tarde o que el parser no conocía esa posición.

La visibilidad debe quedar junto al bit, no en una nota perdida del sistema de captura.

La asignación del registro no equivale a implementación

La revisión 18 solicita un registro TLS Flags con Value, Flag Name, Message, Recommended y Reference. Los valores 0–15 requerirían Standards Action; 16–2039, Specification Required conforme a RFC 8126. La entrada inicial propuesta es resumption_across_names, valor 8, en NewSessionTicket y con Recommended N.

En la fecha de corte, el registro IANA de ExtensionType muestra por separado el contenedor tls_flags como valor 62, con los mensajes CH, SH, HRR, EE, CR, CT y NST, Recommended N y referencia a la revisión 14. La fila permite coordinar un número. No certifica que un producto interprete cada bit ni que una función esté habilitada.

RFC 8447 explica que N no significa necesariamente defectuoso. Puede reflejar aplicabilidad limitada, un caso específico o falta de consenso IETF. La aprobación del experto de registro tampoco es una recomendación. La issue 32 llevó el borrador a reconocer Y/N/D y a evitar que el documento original pareciera dueño permanente del valor Recommended.

Los borradores actuales 8446bis y 8447bis siguen siendo trabajo en curso. Un registro localiza la regla; no es el historial de una conexión.

El rechazo fatal no diagnostica al responsable

Una longitud no mínima, un valor vacío o un bit en una respuesta no solicitada puede terminar el handshake. Esa evidencia permite decir qué regla se violó y qué alerta produjo el receptor.

No permite decir automáticamente por qué. Puede existir una biblioteca antigua, un registro desactualizado, un fallo del serializador, una política experimental o una entrada maliciosa. “La función falló” es demasiado amplio. “El servidor recibió una respuesta con bit no propuesto y emitió illegal_parameter” conserva la frontera observada.

Diagnóstico, remediación y propietario deben añadirse como decisiones separadas, no esconderse dentro del booleano.

Un sobre de interpretación para cada observación

El control propuesto por Daniel Kade es un sobre de interpretación del indicador.

Debe guardar una referencia acotada al transcript sin exportar secretos; versión TLS; handshake completo o reanudado; 0-RTT ofrecido, aceptado o rechazado; rol del emisor y dirección; mensaje exacto; valor del contenedor; hash de los bytes y longitud canónica; posición del bit; instantánea del registro; especificación y revisión que definen la función.

Después clasifica el evento como propuesta, acuse o anuncio permitido. Indica si el acuse era obligatorio, cuál fue la propuesta asociada y qué resultado de validación se observó. Separa visibilidad pasiva de conocimiento de endpoint y conserva las versiones del parser y la política.

Por último registra el resultado posterior: entendido, seleccionado, ejercido, fallido, sustituido o desconocido. Añade la decisión para la que sirve, propietario, consumidores permitidos, retención, incertidumbre, caducidad y cierre.

No es una modificación del protocolo ni una exigencia del IETF. Es la disciplina mínima para impedir que un dato verdadero adquiera un significado que el transcript no contiene.

Una escalera, no un salto

“Bit 8 visto en NewSessionTicket” es una observación. “El servidor anunció reanudación entre nombres bajo la revisión R” interpreta una norma. “El cliente la intentó” añade ejecución. “El servidor la aceptó bajo la política P” documenta una decisión. “La aplicación autorizó la identidad” exige su propia prueba.

El contenedor reduce bytes repetidos. Un sistema responsable no debe reducir al mismo tiempo los verbos. Un indicador TLS es evidencia excelente de lo que apareció en un mensaje; por sí solo no registra el estado de una función.

Fuentes