Resumen

  • RFC 9662 incorpora TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 al mínimo interoperable, conserva RSA/CBC durante la migración y establece reglas distintas para las versiones TLS y DTLS.
  • Implementar, habilitar, ofrecer, preferir y negociar son hechos diferentes; ni siquiera el último confirma que un evento concreto haya entrado en el canal y quedado disponible para una investigación.
  • El recibo defendible enlaza la política y la época de conexión con la identidad del evento, el resultado de transporte, la aceptación, la escritura durable, el índice y la lectura posterior.

El equipo del dispositivo mostró una captura del ClientHello: la suite moderna estaba allí. El equipo del colector mostró el ServerHello: se había seleccionado otra. Ambos afirmaban que su control estaba en verde, y ninguno podía explicar dónde había quedado el evento que buscaba la investigación.

La disputa no es una rareza del protocolo. Es el resultado de usar el verbo «ofrecer» como sustituto de «negociar» y, después, «negociar» como sustituto de «entregar». La RFC 9662 evita la primera confusión al precisar el nuevo mínimo criptográfico para los transportes seguros de syslog. La organización debe evitar la segunda con evidencia por mensaje.

El documento actualiza las RFC 5425 y 6012. Mantiene TLS_RSA_WITH_AES_128_CBC_SHA como suite obligatoria de implementar durante la transición y añade TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, que debe ser preferida. Esta decisión crea solapamiento entre generaciones de equipos. No dice que ambas suites deban estar habilitadas siempre ni que una conexión concreta haya usado la opción preferida.

La gramática de una conexión importa

Implementar describe el código disponible en un producto. Configurar describe la política que un operador aplicó a un extremo. Ofrecer describe una propuesta enviada durante una negociación. Preferir ordena opciones cuando existe solapamiento. Negociar identifica la versión y la suite seleccionadas para una época de conexión.

Esos cinco estados no son equivalentes. Un equipo puede implementar una suite que la política desactiva. Puede ofrecer una opción que el par no comparte. Puede declarar una preferencia que un intermediario o un orden distinto impide materializar. Puede negociar correctamente y, aun así, no enviar el evento previsto.

Por eso el registro debe conservar las listas ofrecidas por ambos extremos cuando sea viable, el resultado seleccionado, el identificador de la conexión, las políticas aplicables y sus revisiones. Una métrica agregada de «compatibilidad» no permite distinguir una carencia de producto de un error de configuración, una falta de solapamiento o una decisión de excepción.

El historial y el texto canónico —la versión de texto, la fuente XML, la ficha del RFC Editor, sus erratas y el historial del Datatracker— fijan lo que dice el estándar. Ninguno observa la negociación de una instalación.

Primero identifique el transporte; luego interprete la versión

En el mapeo de syslog sobre TLS, TLS 1.2 continúa siendo obligatorio de implementar. TLS 1.3 debería soportarse y, cuando esté implementado, debe preferirse. Se trata de un mínimo de interoperabilidad y una dirección de modernización, no de una medición del parque.

En el mapeo sobre DTLS, DTLS 1.0 no debe utilizarse, DTLS 1.2 debe utilizarse y DTLS 1.3 debería soportarse y preferirse cuando exista. La deprecación recogida en RFC 8996 y la guía de RFC 9325 forman parte del contexto, pero no eliminan las diferencias operativas entre flujo y datagrama.

Decir solo «versión 1.2» borra esas diferencias. TLS 1.2 tiene una superficie de continuidad y retransmisión distinta de DTLS 1.2. Lo mismo ocurre con TLS 1.3 y DTLS 1.3. La protección criptográfica de un datagrama no crea un acuse de recibo de la aplicación; una conexión de flujo abierta no confirma que la cola siga drenando.

La suite antigua es un puente observable

RFC 9662 permite que un administrador conserve RSA/CBC si hace falta para que syslog siga fluyendo hasta actualizar el dispositivo. Prohibir de inmediato la única suite común puede quitar a la organización la telemetría del activo más difícil de renovar. Mantenerla sin control puede convertir una transición en una dependencia permanente.

La excepción necesita objeto, no solo aprobación: clase de dispositivo, versión, extremo, colector, suite, motivo, controles compensatorios, responsable, caducidad y prueba de salida. También necesita uso observado. Si nunca se negocia, quizá pueda retirarse. Si se negocia en cada conexión, señala un bloqueo concreto de la migración.

El registro TLS de IANA coordina números y estados, pero no puede indicar qué opción habilitó un operador o qué eligió una pareja. El registro, la implementación, la configuración, la oferta y el resultado vivo son fuentes distintas.

El rechazo de 0-RTT no resuelve el trayecto ordinario

RFC 9662 prohíbe los datos tempranos de TLS 1.3 porque el protocolo syslog no incorpora protección contra repetición y el 0-RTT tiene propiedades más débiles frente a replay. La regla evita que un mensaje de registro viaje por ese camino ambiguo.

No convierte el envío posterior al handshake en exactamente una vez. El productor puede duplicar el evento, una cola puede descartarlo, una reconexión puede partir la secuencia, un datagrama puede perderse, el colector puede rechazarlo, la escritura puede fallar o el índice puede hacerlo invisible.

Hay que probar dos controles por separado: rechazo efectivo de datos tempranos y recorrido completo de un evento canario ordinario. Un intento de 0-RTT rechazado demuestra una política. Un identificador que reaparece en almacenamiento y en la búsqueda demuestra otra cosa.

La autenticación no cruza la frontera del colector

El marco de certificados de RFC 5280 permite validar una ruta, pero la operación también debe verificar la identidad de referencia, el ancla esperada y la autorización local. Una cadena matemáticamente válida no prueba que sea el servicio pretendido.

Incluso una autenticación correcta describe al par y al canal. Para el evento hacen falta un identificador seguro, marca de creación, secuencia o contexto, entrada y salida de cola, época de conexión, intento de envío, resultado de transporte, identificador de aceptación, escritura durable, índice, clase de retención y una lectura posterior.

El modelo debe preservar los resultados negativos: sin suite común, versión prohibida, fallo de certificado o identidad, par no autorizado, datos tempranos, rotura de conexión, desbordamiento, pérdida de datagrama, rechazo, fallo de almacenamiento, índice equivocado o lectura ausente. Agruparlos como «fallo TLS» destruye la asignación de responsabilidad.

Empiece por la pregunta del investigador

¿Puede una persona autorizada recuperar el evento esperado dentro de la retención comprometida? Desde esa respuesta se puede retroceder al objeto durable, la aceptación del colector, el envío, la época de conexión, el registro de la cola y la política. Así se impide que un equipo presente su control local como prueba de todo el sistema.

La Minimum Initial Specification de Heng Lu ayuda a mantener pequeño y explícito el mínimo compartido, sin ocultar la decisión local. Reality Layers separa el símbolo normativo del hecho observado. Running-Code Primacy devuelve autoridad a la conexión y al evento realmente procesados.

RFC 9662 mejora una condición necesaria para syslog seguro. La disciplina directiva consiste en no venderla como condición suficiente. Lo ofrecido, lo negociado y lo conservado deben seguir siendo afirmaciones independientes hasta que un identificador las una.

Fuentes