Resumen

  • La IESG aprobó el 3 de septiembre de 2026 la revisión 25 de TLS/DTLS 1.3 Profiles for the Internet of Things como Proposed Standard; el anuncio aún no le asigna un número RFC definitivo.
  • El documento acompaña a RFC 7925 y actualiza únicamente el perfil X.509 y los requisitos de suites criptográficas. TLS/DTLS 1.2 conserva relevancia para instalaciones heredadas de ciclo largo.
  • La propia revisión establece el límite: la compatibilidad del protocolo es necesaria, pero insuficiente para la interoperabilidad en autenticación y autorización.
  • Certificados, claves públicas sin certificado y PSK externos reparten de otro modo la identidad, el aprovisionamiento y la renovación. Ninguno convierte el handshake en una decisión de permiso.
  • Hace falta un recibo versionado que enlace credencial, identidad esperada, política local, ancla de confianza, vigencia de la sesión, reautenticación, reacción ante errores y reversión, sin exponer secretos.

Un estándar común y una decisión que no se delega

La aprobación resuelve un problema real. Los equipos con poca memoria, batería o ancho de banda no pueden limitarse a copiar todas las opciones de un servidor convencional. El grupo Using TLS in Applications ha producido una guía normativa sobre credenciales, extensiones, reanudación, confidencialidad futura, temporizadores, tamaños de registro, certificados y suites para TLS y DTLS 1.3.

Esa base permite que dos implementaciones entiendan las mismas obligaciones. No dice, sin embargo, que dos operadores vayan a interpretar del mismo modo una identidad ni que concedan el mismo acceso. La revisión 25 lo reconoce expresamente: compatibilidad TLS es el requisito previo; autenticación y autorización exigen un trabajo adicional.

Conviene no inflar ni rebajar el estado. La IESG aprobó el texto para Proposed Standard. Aún falta la publicación editorial y el anuncio no muestra un número RFC final. Tampoco es Internet Standard ni certificación de producto. La decisión de la IETF gobierna el documento común; no prueba el estado de una flota.

El vínculo con RFC 7925 evita otra simplificación. El nuevo perfil no borra TLS/DTLS 1.2. Sólo actualiza su tratamiento de certificados y suites allí donde TLS/DTLS 1.3 lo requiere. Una planta con certificaciones y equipos de larga vida puede convivir durante años con ambas generaciones. El inventario debe conservar esa diferencia.

La identidad no viene en un único envase

El perfil admite tres modos principales. Un certificado X.509 une una clave y un identificador bajo una cadena emisora. Una clave pública cruda autentica una clave sin transportar esa cadena. Un PSK externo trae al intercambio un secreto creado fuera de TLS. La especificación no impone uno, porque coste y operación importan junto con las propiedades criptográficas.

En el modelo de certificado, la distinción entre IDevID y LDevID muestra que identidad no equivale a permiso. La identidad inicial colocada por el fabricante puede iniciar el enrolamiento. El identificador operativo lo entrega normalmente el dueño u operador para un dominio concreto. Usar la primera credencial indefinidamente por comodidad cambiaría su función sin registrar una decisión.

La clave cruda ahorra bytes, pero necesita una unión externa con el par esperado. Si un cliente omite SNI porque usa una clave fijada, una dirección configurada, un certificado propio o una identidad PSK, debe existir otra forma de unión. De lo contrario, el sistema puede verificar exactamente la clave presentada y atribuirla al servicio equivocado.

El PSK concentra poder en el aprovisionamiento. Hay que fijar su identidad, entropía, alcance, separación entre versiones y reemplazo. La revisión recomienda (EC)DHE para conservar secreto hacia delante. Acepta PSK sin intercambio efímero sólo si la pérdida se asume de manera explícita para el despliegue. Ese «explícito» requiere responsable y fecha, no una opción olvidada en firmware.

SNI selecciona contexto de servidor; ALPN distingue protocolos de aplicación. Ambos reducen confusiones. Ninguno decide que un dispositivo autenticado pueda leer datos, accionar maquinaria o cambiar una configuración. La política local conserva esa autoridad.

Donde falta OCSP aparece el reloj del operador

Muchos dispositivos restringidos no consultan OCSP ni CRL durante el handshake. El perfil propone apoyarse normalmente en certificados operativos breves y mecanismos automáticos de enrolamiento y gestión. La revocación pasa a una ruta diferente: reemplazo, administración y control de sesiones.

Ese diseño exige mirar más allá de la fecha del certificado. Un certificado actualizado no altera por sí mismo una sesión TLS ya establecida. Si una conexión debe conservar validez continua, la aplicación debe provocar reautenticación o cerrarla y abrirla de nuevo. Para autenticación mutua posterior al handshake se necesita además soporte del protocolo de aplicación.

La ancla de confianza crea una deuda todavía más larga. Un equipo puede permanecer activo durante un cambio de CA, de fabricante o de algoritmo. Una actualización de software puede distribuir la ancla nueva; no demuestra que cada equipo la instaló, la seleccionó y abandonó la antigua. Esos estados deben medirse por cohorte, con excepciones y posibilidad de reversión.

Delegar una tarea al operador no debilita el estándar. Hace visible quién controla el intervalo entre una credencial comprometida y la última sesión que todavía la representa. Si el recibo sólo dice «certificado reemplazado», ese intervalo queda sin dueño.

Ahorrar recursos no elimina los costes

En el ejemplo mínimo del documento, dos certificados ECC consumen cerca del 40 % de la carga del handshake TLS 1.3 con autenticación mutua. Cadenas menos profundas, compresión, caché y reanudación reducen tráfico y cálculo. Pero toda optimización cambia otra prueba.

Los tickets de sesión necesitan cantidad, duración y regla de reutilización que equilibren estado del servidor, replay y privacidad. Buscar certificados fuera del handshake añade DNS o directorios y puede revelar identificadores estables. El caché exige invalidación. Menos bytes en la radio pueden significar más autoridad en un servicio externo.

La prohibición de 0-RTT enseña una frontera limpia. Un protocolo de aplicación no debe usarlo sin un perfil que nombre mensajes seguros y explique el retroceso a 1-RTT. La revisión 25 dice que CoAP y MQTT no disponían entonces de dicho perfil y no les habilita 0-RTT. Que la biblioteca pueda enviar antes no significa que la aplicación tenga permiso para hacerlo.

Los errores siguen la misma lógica. En una instalación sin usuario presente, alguien debe definir qué alerta permite reintentar, cuál lleva a otra credencial y cuál ordena un estado seguro. TLS genera el hecho; la aplicación y el operador deciden el efecto.

El recibo de frontera

El registro propuesto no es una copia del certificado ni un volcado de configuración. Comienza por versión del perfil y compilación. Añade modo de credencial, referencia estable, identidad esperada, método de unión, protocolo y rol de aplicación, versión de política y clase de acción permitida.

Su parte temporal conserva generación de ancla, generación de certificado o PSK, canal de entrega, activación observada, caducidad y reemplazo. La parte de sesión distingue apertura completa y reanudada, edad del ticket, última reautenticación y duración máxima. Una excepción a forward secrecy necesita dueño, alcance y vencimiento.

La parte de seguridad enlaza errores con reintento, alternativa, degradación o parada segura. Registra 0-RTT como deshabilitado o, si un perfil futuro lo admite, mensajes cubiertos y control anti-replay. Una corrección añade estado; no borra el que explica conexiones previas.

La nota 64 de Heng Lu aporta sólo una regla editorial: el acuerdo compartido debe ser mínimo, determinista y verificable localmente. No prueba un despliegue. Aplicada aquí, impide pedir a la IETF una política universal de acceso y también impide esconder una decisión local detrás del nombre del estándar.

Lo que no está demostrado

No hay en estas fuentes una prueba de producto, un incidente ni una evaluación de operador. La IESG no ha elegido la autoridad certificadora, el PSK, la tabla de permisos o el estado seguro de nadie. Tampoco ha certificado una implementación.

La sección poscuántica no convierte el perfil en resistente a ordenadores cuánticos. Las suites normativas son clásicas y esa sección es informativa. La vida larga de los objetos hace urgente planear el cambio, no declararlo resuelto.

El texto tampoco sostiene que todo objeto carezca de recursos para OCSP o CRL. Describe un patrón y recomienda que cada caso mida riesgo y complejidad. Un dispositivo capaz puede mantener un control distinto.

El valor de la aprobación está precisamente en aclarar el reparto: la IETF reduce la incompatibilidad común; cada despliegue conserva y debe documentar la autoridad de admitir, mantener o detener al dispositivo.

Fuentes

  1. IESG — acción sobre el perfil TLS/DTLS 1.3 para IoT
  2. IETF — revisión 25 aprobada
  3. RFC 9846 — TLS 1.3
  4. RFC 9147 — DTLS 1.3
  5. RFC 7925 — perfiles TLS/DTLS para IoT
  6. RFC 5280 — perfil PKI X.509
  7. RFC 9257 — PSK externos
  8. RFC 9258 — importación de PSK externos
  9. RFC 9019 — actualización de firmware IoT
  10. RFC 8995 — BRSKI
  11. RFC 9525 — identidad de servicio TLS
  12. RFC 9325 — uso seguro de TLS y DTLS
  13. Heng Lu — Minimum Initial Specification