Resumen

  • RFC 9761 amplía MUD con perfiles TLS y DTLS observables; el fabricante describe lo esperado, pero el operador conserva la decisión y la consecuencia.
  • Hay que cruzar pertenencia al perfil y reconocimiento del cortafuegos. Lo conocido e inesperado puede activar controles; lo que el propio cortafuegos desconoce no debe bloquearse sólo por esa ignorancia.
  • TLS 1.3 oculta gran parte del saludo, y ECH y DNS cifrado reducen más el contexto. Recuperarlo mediante un proxy abre otra decisión de privacidad y confianza.

El dato nuevo no apareció primero en un registro de amenazas. Apareció en el perfil firmado del fabricante. El dispositivo había incorporado un parámetro TLS reciente; el cortafuegos seguía ejecutando un módulo antiguo y no sabía interpretarlo.

Clasificar ese tráfico como ataque habría premiado al componente menos actualizado. RFC 9761 diseña una salida distinta. Si el perfil declara el parámetro y el cortafuegos no lo reconoce, éste debe ignorarlo para la comparación, permitir según la política restante y avisar de su desfase. Si tampoco figura en el perfil y el cortafuegos no lo conoce, la mera novedad sigue sin bastar para bloquear.

Tres actores, tres afirmaciones

RFC 8520 permite que quien fabrica un objeto de propósito limitado describa las comunicaciones necesarias para ese uso. La descripción puede convertirse localmente en reglas. No es una orden remota ni una transferencia de responsabilidad: el fabricante afirma intención; la red decide aplicación.

RFC 9761 añade versiones TLS/DTLS, suites, extensiones, grupos, firmas, modos PSK, ALPN, anclas de confianza, autoridades aceptables y compresión de certificados. El módulo extiende las ACL de RFC 8519, mientras IANA mantiene parte del vocabulario. Así nacen tres afirmaciones separadas: el perfil dice qué se espera, el paquete muestra qué se ofreció y el cortafuegos revela qué sabe nombrar.

Un sistema de cumplimiento que las funde pierde la causa del desajuste. Puede castigar al dispositivo por la obsolescencia del inspector o considerar limpio a un proceso malicioso que copió una oferta legítima.

La decisión depende de dos respuestas

Primero: ¿el parámetro observado pertenece al perfil vigente? Segundo: ¿lo reconoce la versión del cortafuegos que tomó la decisión?

Sí y sí significa esperado, no inocuo. Un programa hostil puede usar las mismas suites y extensiones. No y sí produce una desviación con semántica conocida. Puede indicar software no autorizado, una versión antigua, un cambio de firmware no publicado o una asociación errónea de modelo. La red puede alertar, aislar o bloquear, pero debe conservar el código exacto y la regla que justificó la acción.

Sí y no identifica otro responsable: el perfil avanzó y el inspector no. RFC 9761 pide alertar al proveedor del cortafuegos y al dueño del dispositivo. No y no deja una incertidumbre todavía mayor. La conducta correcta es no bloquear por desconocimiento. El invariante proviene de los intermediarios compatibles con TLS 1.3: los valores desconocidos deben poder cruzar el camino.

Una extensión necesita espacio antes de tener nombre

RFC 8701 convierte esa idea en una prueba continua. GREASE inserta valores reservados para descubrir servidores e intermediarios que sólo toleran el catálogo antiguo. RFC 9761 prohíbe incluir GREASE en el perfil MUD. Si cada aparición se considera incumplimiento, el control de seguridad pasa a fabricar la osificación que GREASE pretendía evitar.

Los registros IANA de parámetros TLS, parámetros YANG y MUD coordinan nombres y módulos. Una asignación no prueba adopción. Para reconstruir el hecho operativo hacen falta la fecha del perfil, la revisión del registro y la generación realmente cargada por el cortafuegos.

La regla de permitir y avisar no es una licencia general. Conserva la autoridad local sobre un riesgo que sí puede describirse, a la vez que impide que el retraso de un proveedor se convierta en prohibición global de cada extensión nueva.

La ventana de observación se hace más pequeña

TLS y DTLS 1.2 exponen ClientHello, ServerHello y Certificate. TLS 1.3 cifra casi todo después de ClientHello; DTLS 1.3 aplica una protección equivalente. El cortafuegos pasivo sigue viendo algunas ofertas y elecciones, pero no el certificado del servidor ni todos los campos que el perfil podría describir.

ECH puede ocultar SNI y otros datos del ClientHello. El DNS cifrado puede ocultar la consulta que relacionaba un nombre con el flujo. Cuando el dispositivo elige un resolvedor no designado por la red, la política MUD basada en dominios pierde su punto de aplicación. DDR y DNR permiten anunciar resolvedores cifrados elegidos por la red; hay que comprobar tanto el anuncio como su uso.

La alternativa de inspección completa es un proxy TLS. RFC 9761 lo limita a dispositivos que la empresa posee y administra, exige cumplir las reglas internas de seguridad y privacidad y desaconseja usarlo siempre que sea posible. El proxy ve más porque termina la protección: se convierte en extremo de confianza, desplaza la validación del certificado y puede manejar información personal o sanitaria.

RFC 9325 ayuda a evaluar algoritmos débiles. RFC 8613 muestra que OSCORE puede proteger objetos de aplicación de extremo a extremo aunque otro componente opere en la capa de transporte. Son opciones arquitectónicas, no autorización automática para interceptar.

El parecido no es identidad

El propio RFC reconoce que el malware puede imitar un perfil válido. Ajustarse a cada modelo, conservar destinos creíbles, usar certificados compatibles y seguir actualizaciones eleva el coste, pero no vuelve imposible la copia. El resultado “coincide” sólo elimina una clase de discrepancia.

La evidencia útil enlaza identidad y modelo observados, URL y firma MUD, versión del perfil, firmware, flujo, código TLS, resultado de pertenencia, versión del analizador, contexto DNS/IP, estado ECH, uso de proxy, decisión y comprobación del terminal. is-supported=false informa de que el fabricante ya no promete actualizaciones; no demuestra por sí mismo que el equipo esté averiado o comprometido.

La doctrina de las capas de realidad evita que un documento suplante a la ejecución. La primacía del código en funcionamiento exige registrar qué versiones actuaron. Una especificación inicial mínima con decisión futura localizada permite coordinar el significado sin entregar a IETF, IANA o al fabricante el mando de cada red.

La contribución duradera de RFC 9761 no es convertir el perfil en identidad. Es impedir que una comparación parcial se presente como conocimiento total.