Resumen

  • El 10 de septiembre de 2026, el IESG denegó una apelación, liberó la retención de publicación y anunció la aprobación de draft-ietf-tls-mldsa-05. El texto especifica cómo usar las firmas ML-DSA de FIPS 204 para autenticar TLS 1.3. Aspira a ser un RFC informativo; al cierre de esta revisión seguía siendo un Internet-Draft sin número de RFC.
  • El registro de SignatureScheme de TLS mantenido por IANA ya contiene mldsa44, mldsa65 y mldsa87 en 0x0904, 0x0905 y 0x0906. Las tres entradas llevan N. RFC 9847 define N como ausencia de una declaración de idoneidad o de consenso de la IETF, no como el marcador D de desaconsejado.
  • Aprobar la publicación, asignar nombres interoperables y recomendar un despliegue son decisiones distintas. La resolución de la apelación cierra una disputa de proceso; no elige ML-DSA puro o compuesto para todos los entornos.
  • Quien active el mecanismo debe emitir un comprobante propio: superficie TLS, perfil y parámetro elegidos, pares y certificados incluidos, pruebas fechadas, límites de fallo, reversión, responsable y próxima revisión.

El consenso permitió publicar, no borrar la objeción

El historial del documento muestra dos momentos. El IESG lo aprobó el 8 de julio y lo retuvo ese mismo día mientras examinaba una apelación. El 10 de septiembre denegó el recurso, levantó la retención y devolvió el borrador al estado de anuncio aprobado. El mensaje de aprobación lo identifica como producto del grupo TLS destinado a la categoría informativa.

El expediente no oculta que hubo fricción. El resumen del shepherd calcula unos 275 mensajes y una relación aproximada de cuatro apoyos por una oposición para seguir adelante. También conserva las alternativas debatidas: no publicar ML-DSA puro, recomendar diseños compuestos o hacer avanzar ambas vías. La respuesta del IESG afirma que revisó las aportaciones del Working Group Last Call, halló apoyo amplio y comprobó que las objeciones se habían considerado y discutido. La apelación fue rechazada; Deb Cooley no participó en la decisión.

El resultado importa, pero tiene un objeto limitado. Confirma que la llamada de rough consensus bastaba para publicar este documento pese al desacuerdo. No certifica que todas las objeciones técnicas sean falsas. Tampoco obliga a un operador a aceptar el mismo riesgo. Un proceso abierto puede terminar con una especificación útil y, al mismo tiempo, dejar elecciones de despliegue sin consenso universal.

La terminología temporal también requiere cuidado. La página actual muestra Approved-announcement sent, pero todavía describe la revisión 05 como Internet-Draft activo. El examen de IANA figura como Version Changed - Review Needed y la acción como In Progress. Aún no hay un número de RFC que pueda citarse. La aprobación está hecha; la producción editorial final no.

La asignación resuelve la ambigüedad entre implementaciones

ML-DSA es el estándar de firma digital poscuántica de FIPS 204. El borrador aprobado no evalúa toda estrategia de migración. Conecta tres conjuntos de parámetros con la negociación de autenticación en TLS 1.3: mldsa44/0x0904, mldsa65/0x0905 y mldsa87/0x0906.

El RFC 9881 ya define los AlgorithmIdentifier X.509 correspondientes. El texto TLS hace que esos identificadores puedan anunciarse como SignatureScheme. Si uno se utiliza en CertificateVerify, la firma y la verificación siguen FIPS 204 con ctx vacío, y el certificado final debe contener el AlgorithmIdentifier correspondiente. Las variantes prehash HashML-DSA quedan fuera.

Esa precisión permite que productos desarrollados por separado formen el mismo mensaje y comprendan el certificado. No demuestra que una autoridad vaya a emitirlo, que todos los clientes lo validen, que la clave esté protegida en el hardware elegido o que una flota pueda revertir una activación parcial. La interoperabilidad de formato reduce una incertidumbre; no cancela las demás.

Las tres filas ya aparecen en el registro vivo de IANA con N. La referencia apunta todavía a una revisión anterior del borrador, mientras Datatracker mantiene la acción IANA en curso. Por eso conviene describir el estado sin redondearlo: los valores existen y son públicos, pero las referencias y la publicación final aún se están cerrando.

Qué dice realmente N

En una pantalla administrativa, N parece significar «no». En RFC 9847 significa algo más preciso. Y expresa consenso de la IETF en que el elemento es recomendable y apto para el propósito definido, con las limitaciones de su documento. D señala que se desaconseja y debe explicar el motivo. N indica que la IETF no ha declarado su idoneidad, que no hay consenso, o que existen usos limitados.

El propio RFC advierte que N no implica necesariamente un mecanismo defectuoso. Por tanto, la asignación no es una luz verde, pero N tampoco es una luz roja. La fila permite nombrar la opción y mantener su estado institucional sin convertir a IANA en evaluador universal de despliegues.

Ese diseño evita dos pérdidas de información. Si cada número se interpreta como aprobación, una tarea registral se convierte en política de seguridad. Si N se traduce como rechazo, desaparece el espacio para pruebas controladas y para aplicaciones específicas. El sistema puede albergar una especificación interoperable antes de contar con una recomendación general.

La alternativa compuesta no comparte el mismo estado

El documento aprobado trata ML-DSA puro. Otro Internet-Draft individual activo propone firmas compuestas que combinan ML-DSA con un algoritmo tradicional en TLS 1.3. Datatracker avisa que ese borrador individual no tiene respaldo de un stream de la IETF. Es una propuesta documentada, no una segunda recomendación equivalente.

La elección depende del modelo de amenaza. Un perfil puro evita la obligación de validar una segunda firma, pero concentra la confianza en ML-DSA y su implementación. Un perfil compuesto puede conservar una defensa clásica si falla el componente nuevo, a cambio de mensajes y certificados mayores, más cálculo y más puntos de incompatibilidad. El estado de publicación no decide qué intercambio acepta cada servicio.

La enumeración de implementaciones del anuncio tampoco decide. Que OpenSSL, BoringSSL, rustls-post-quantum, s2n-tls, wolfSSL, Bouncy Castle o GnuTLS contengan código es evidencia de implementación. No prueba activación por defecto, uso productivo, cadenas compatibles, configuración común, coste aceptable ni reversión ensayada.

El comprobante que falta está junto al sistema

La decisión local debe empezar por el alcance. «Preparado para lo poscuántico» es demasiado amplio. El registro debería decir si se trata de autenticación de servidor o cliente, un servicio privado acotado o un ensayo público, y nombrar el parámetro y el perfil puro o compuesto.

Después vienen las poblaciones: emisores, perfiles de certificado, endpoints, clientes, bibliotecas y módulos de claves. La negociación necesita reglas observables. ¿Qué ocurre cuando el otro extremo no anuncia la nueva firma? ¿El sistema usa otra cadena, rechaza la conexión o cae a una opción permitida? Un fallback silencioso puede mantener disponibilidad y destruir al mismo tiempo la propiedad de seguridad que se quería conseguir.

Las pruebas deben cruzar familias de implementación y llevar fecha. Hay que medir bytes, CPU y latencia bajo concurrencia realista; recorrer emisión y validación de la cadena completa; y revisar generación de claves, firma, verificación y filtraciones laterales dentro del límite de operación concreto. Dos binarios de la misma biblioteca no representan todo el ecosistema.

Por último, el comprobante nombra quién amplía, quién detiene, qué telemetría activa la reversión, cómo se retiran certificados y claves ya distribuidos, cuándo caduca la evidencia y cuándo se repetirá la decisión. Esa ficha no compite con la IETF. Completa el tramo que la IETF no puede decidir por un operador.

Límites de la evidencia

Las fuentes no prueban uso general ni activación predeterminada. No resuelven universalmente la elección puro/compuesto. La denegación de la apelación es un juicio sobre el proceso, no una demostración criptográfica. FIPS 204 normaliza el algoritmo, no una topología TLS. La visibilidad del registro no confirma que haya terminado toda la acción de IANA y del RFC Editor.

La conclusión verificable es más estrecha: la IETF autorizó publicar un método interoperable para tres parámetros ML-DSA en TLS 1.3 y mantuvo su recomendación en N. Quien quiera desplegarlo aún debe aceptar y documentar su propia decisión.

Fuentes

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. IESG — Anuncio de aprobación de Use of ML-DSA in TLS 1.3
  5. IETF Datatracker — draft-ietf-tls-mldsa-05
  6. IETF Datatracker — Historial del documento
  7. IESG — Respuesta a la apelación, artefacto 320
  8. IANA — Parámetros de Transport Layer Security
  9. RFC 9847 — Actualización de registros IANA para TLS y DTLS
  10. NIST — FIPS 204, estándar ML-DSA
  11. RFC 9881 — Identificadores de algoritmo para ML-DSA
  12. RFC 9846 — El protocolo TLS 1.3
  13. IETF Datatracker — Use of Composite ML-DSA in TLS 1.3