Resumen

  • El IESG aprobó el 3 de septiembre de 2026 el perfil TLS/DTLS 1.3 para Internet de las Cosas como Proposed Standard. Su diseño contempla dispositivos longevos y anclas reemplazables; no certifica que una unidad desconectada haya recibido, guardado o usado la nueva autoridad.
  • La evidencia debe seguir cada dispositivo desde el paquete autorizado hasta la lectura persistente, la cadena aceptada, el último uso de la autoridad anterior y el resultado de la aplicación. Un porcentaje de flota no sustituye esa trazabilidad.

El anuncio del IESG aprobó draft-ietf-uta-tls13-iot-profile-25. El registro del Datatracker muestra la versión 25 con el anuncio enviado; el expediente revisado aún no exhibía un número RFC definitivo. El texto aprobado acompaña a la RFC 7925, dedicada a TLS/DTLS 1.2 en entornos restringidos, y actualiza sus requisitos X.509 y criptográficos.

La aportación importante no es declarar más moderno el protocolo. El documento conecta la negociación con memorias pequeñas, conectividad intermitente, credenciales provisionadas fuera de red y vidas útiles largas. Además advierte que mantener una ancla estática durante toda la vida del equipo dificulta el cambio de algoritmo, la rotación de CA, el cambio de fabricante y la respuesta a incidentes.

La ancla de confianza es una decisión local sobre dónde puede empezar la validación. Una raíz incluida por el servidor en el mensaje Certificate no se vuelve confiable porque llegue dentro de la conexión que pretende autenticar. La base preferida es aprovisionarla fuera del intercambio y no enviarla en la cadena.

La unidad que no llamó no debe desaparecer del denominador

La actualización segura de firmware puede transportar nuevas anclas. La arquitectura SUIT de la RFC 9019 separa autor, distribuidor, dispositivo y relaciones de confianza. Pero «paquete entregado» no dice que la firma fuera validada, la escritura sobreviviera a un corte, la nueva generación se activara, el almacén la leyera al reiniciar o una conexión real la escogiera.

Los dispositivos estacionales convierten esta diferencia en un problema de calendario. La organización puede cerrar una campaña después de treinta días mientras una estación remota permanece apagada durante seis meses. Cuando vuelve, tal vez solo confíe en la CA antigua y necesite precisamente ese camino para descargar la corrección.

El propio alcance exige cuidado: distribuir anclas en firmware no actualiza por sí solo certificados de entidad final ni de CA subordinada. La RFC 7030 define EST para el enrolamiento y la obtención de certificados de CA, pero su soporte y su ejecución deben probarse localmente.

X.509, RPK y PSK dejan recibos distintos

El perfil admite certificados X.509, claves públicas brutas y PSK externas. No ordena una credencial universal.

En X.509 existen al menos la ancla, la jerarquía subordinada y el certificado final. Una clave pública bruta de la RFC 7250 reduce la estructura intercambiada, pero sigue necesitando una asociación protegida entre clave e identidad esperada. Un certificado X.509 autofirmado no se transforma en RPK por conveniencia terminológica.

Las PSK externas cambian el tipo de custodia. La RFC 9257 expone riesgos de entropía, identidad y despliegue. La RFC 9258 define importadores vinculados al KDF y al hash de TLS 1.3. Todavía hay que registrar quién generó el secreto, cuántos equipos lo comparten, cuándo rota y qué servicio puede usarlo.

Por eso el primer campo del registro no debe ser «TLS sí/no», sino el modo de credencial y la autoridad concreta que lo administra.

La compatibilidad transitoria puede ocultar una deuda permanente

Durante una rotación, el servidor puede considerar la extensión certificate_authorities para seleccionar una cadena que el cliente declara admitir. Los certificados cruzados newWithOld y oldWithNew de la RFC 9810 pueden tender un puente entre generaciones. No instalan la nueva ancla fuera de banda.

Si el puente permanece, el sensor estacional sigue conectando y el tablero muestra éxito. También permanece utilizable la autoridad que se pretendía retirar. La continuidad deja de ser evidencia de terminación.

Si se elimina el camino antiguo antes del despertar, el sensor puede quedar fuera del único canal autenticado de recuperación. La política necesita una condición de salida respaldada por la última observación de cada cohorte, no solo una fecha corporativa.

Ahorrar memoria no elimina la arquitectura

Cuando el requisito por defecto, cercano a 18 KB de búfer de procesamiento, resulta excesivo, Record Size Limit de la RFC 8449 permite anunciar el mayor registro que se acepta. El valor no representa toda la RAM, el flash, la energía ni el coste de validar una cadena.

La reanudación de sesión definida en la RFC 9846 puede evitar repetir certificados. La cantidad, duración y reutilización de tickets trasladan costes al estado del servidor, la privacidad y el control de repetición. El perfil IoT no habilita 0-RTT para CoAP o MQTT sin un perfil seguro de la aplicación.

La compresión de certificados, la información cacheada y las URL reducen bytes, pero pueden crear dependencia de una caché, un servicio de recuperación o un identificador estable. Conviene anotar qué coste se redujo y qué autoridad o disponibilidad se añadió.

Un registro que siga la vida, no la campaña

Cada fila por dispositivo debe contener generación de hardware, firmware y arranque seguro; raíz de actualización; modo de credencial; huellas, funciones y políticas de las anclas aceptadas. Cada cambio debe producir recibos de autorización, entrega, verificación, escritura duradera, activación, reinicio y lectura posterior.

Luego hay que registrar lo que el servicio presentó y el dispositivo aceptó: certificado final, ruta subordinada, generación de ancla, protocolo negociado y hora. El recibo de la aplicación va aparte. Una negociación TLS confirma un par bajo un camino; no demuestra que una orden se autorizó, se confirmó ni produjo un efecto físico.

La distinción de capas de Lu Heng evita prestar autoridad entre hechos: Proposed Standard es estado simbólico; el almacén es configuración; la validación es ejecución; la continuidad es resultado. Running-Code Primacy exige observar al dispositivo, y la especificación inicial mínima con decisión futura localizada permite interoperabilidad sin imponer una única CA o topología de actualización.

Fuentes