Resumen

  • El 3 de septiembre de 2026, el IESG aprobó la revisión 10 de ML-KEM Post-Quantum Key Agreement for TLS 1.3 para publicarla como RFC Informational. El expediente consultado aún no tenía número de RFC.
  • MLKEM512, MLKEM768 y MLKEM1024 quedan descritos como NamedGroups de TLS 1.3 con DTLS-OK=Y y Recommended=N. El RFC 9847 aclara que N no es recomendación, prohibición ni diagnóstico de defecto.

Imaginemos un panel que convierte dos columnas del registro IANA en una sola luz verde. Ve DTLS-OK=Y, ignora Recommended=N y activa el grupo en toda la red. El fallo no está en ML-KEM. Está en una interfaz que ha borrado una decisión.

La revisión 10 define una construcción operable. KeyGen crea la clave pública de encapsulación y la clave secreta de desencapsulación. El cliente coloca la primera en key_share. El servidor ejecuta Encaps, devuelve el ciphertext en su key_share y obtiene un secreto. El cliente aplica Decaps; el secreto común, de 32 bytes, entra en el key schedule de TLS 1.3.

Los identificadores son 512 (0x0200) para MLKEM512, 513 para MLKEM768 y 514 para MLKEM1024. Sus claves públicas miden 800, 1.184 y 1.568 bytes. Sus ciphertexts miden 768, 1.088 y 1.568 bytes. Son dimensiones del protocolo, no resultados de latencia, capacidad o fiabilidad.

También hay reglas de rechazo. El servidor debe ejecutar la comprobación de clave de FIPS 203 y usar illegal_parameter si falla. El cliente debe rechazar con esa alerta una longitud de ciphertext incompatible. Otros fallos de desencapsulación producen internal_error. El transcript incluye los key shares y compromete la clave y el ciphertext dentro del handshake.

La ejecución añade riesgos que el número de registro no observa. La aleatoriedad usada para crear ciphertexts no se puede reutilizar. El receptor con la clave secreta recupera exactamente esa aleatoriedad; si el generador es inseguro, podría aprender relaciones con otras salidas o con su estado. FIPS 203, NIST SP 800-227 y RFC 8937 orientan la implementación, pero no certifican un binario concreto.

El 5 de septiembre, el registro vivo ya mostraba las tres filas, aún referidas a la revisión 05 del borrador individual anterior. Datatracker mostraba al mismo tiempo la revisión 10 aprobada y la acción de IANA en curso. Hay que fechar esa observación: la proyección puede actualizarse y no constituye por sí sola un incidente.

El RFC 9847 define tres valores. Y expresa consenso del IETF sobre la idoneidad para el propósito definido. D desaconseja y exige una razón. N indica que el IETF no ha emitido una conclusión de idoneidad; puede existir aplicación limitada, condiciones de uso o falta de consenso. N no significa necesariamente que el mecanismo sea defectuoso.

Por eso la aprobación del documento no permite decir «el IETF manda habilitarlo». Tampoco permite leer N como «el IETF lo prohíbe». La primera frase convierte publicación en autoridad local. La segunda inventa una censura técnica. Ambas evitan nombrar a quien asume el coste.

DTLS-OK=Y responde otra pregunta: la entrada puede utilizarse con DTLS según la dimensión del registro. No garantiza una biblioteca, una fuente de entropía, un camino de red o una aplicación. Su Y no cancela el N vecino.

El RFC 10024 ofrece un contraste: X25519MLKEM768 tiene hoy Recommended=Y, mientras otros grupos híbridos siguen en N. El nuevo documento pide evaluar seguridad, rendimiento y restricciones operativas antes de elegir ML-KEM autónomo o una construcción híbrida. No traslada esa selección al registro.

La evidencia de despliegue debe avanzar por escalones: versión del documento, captura IANA, build de biblioteca y módulo, controles de RNG, configuración por terminador, oferta ClientHello, selección ServerHello, alertas de validación, handshake finalizado y transacción de aplicación. Una oferta no es selección; una selección no es handshake; un handshake no es servicio ni autorización.

La primacía del código en funcionamiento de Lu Heng encaja precisamente aquí. La especificación mínima permite que dos extremos interpreten los mismos bytes. El operador conserva la decisión futura localizada. Las capas de realidad impiden que un acto editorial, una fila administrativa y un resultado técnico suplanten al siguiente.

La noticia no es que el IETF haya elegido o rechazado ML-KEM autónomo. Es que ha aprobado una descripción interoperable sin fingir una recomendación general. El registro coordina. El responsable local decide, mide y responde.

Fuentes