Resumen

  • RFC 10024 define X25519MLKEM768, SecP256r1MLKEM768 y SecP384r1MLKEM1024 para combinar ML-KEM con un componente tradicional de curva elíptica en el acuerdo de claves de TLS 1.3.
  • El secreto de sesión y la autenticación del servidor son resultados distintos. Un grupo híbrido puede proteger el primero mientras el certificado y la firma CertificateVerify continúan siendo clásicos.
  • Bas Westerbaan comparte la autoría con Krzysztof Kwiatkowski, Panos Kampanakis y Douglas Stebila. El RFC permite medir una etapa de la migración sin presentarla como cobertura total.

En seguridad, la palabra «híbrido» puede sonar a estado final: lo antiguo y lo nuevo ya funcionan juntos, por lo que el sistema estaría preparado. RFC 10024 ofrece una lectura más precisa. Lo que funciona en conjunto son dos componentes de un mecanismo concreto de acuerdo de claves.

El estándar propuesto por el IETF, publicado en agosto de 2026, asigna grupos estables a tres combinaciones. X25519 se une con ML-KEM-768; secp256r1 con ML-KEM-768; y secp384r1 con ML-KEM-1024. Cliente y servidor intercambian las partes previstas y construyen un secreto compartido que incorpora ambas.

La motivación es el archivo del adversario. Quien guarda hoy tráfico cifrado puede apostar por romper mañana el acuerdo de claves clásico con un ordenador cuántico relevante. Combinar una base tradicional y otra poscuántica evita que la protección del secreto de sesión descanse únicamente en una de ellas.

Pero TLS hace más cosas durante la misma conversación.

El apretón de manos no es una sola garantía

TLS 1.3 utiliza el acuerdo de claves para alimentar su programa de derivación y producir claves de tráfico. En un apretón de manos basado en certificados, la cadena de confianza y la firma CertificateVerify autentican al servidor. Los mensajes forman un transcript común, pero responden preguntas diferentes.

La primera pregunta es si los extremos obtuvieron secretos de conexión bajo la construcción negociada. La segunda es si el extremo que afirma representar un nombre controla la clave privada de un certificado confiable y firmó el transcript mediante un algoritmo aceptado.

RFC 9794 evita confundir las familias: establecimiento de claves híbrido PQ/T, KEM híbrido, cifrado de clave pública híbrido y firma digital híbrida tienen definiciones propias. RFC 9935, al fijar identificadores X.509 para ML-KEM, también muestra que PKI y certificados forman otro plano. Disponer de identificadores no despliega una autoridad de certificación; negociar ML-KEM no crea una firma poscuántica.

La amenaza cambia con el plano. El acuerdo híbrido se dirige sobre todo al atacante pasivo que conserva sesiones para descifrarlas en el futuro. La firma poscuántica responde al atacante activo capaz de falsificar una identidad clásica. Ambos riesgos son importantes. No se corrigen con el mismo comprobante.

Lo que demuestra una migración por etapas

Cloudflare Research presenta a Bas Westerbaan como Research Engineer dedicado a impulsar la criptografía poscuántica desde la ingeniería y la estandarización hasta experimentos de gran escala y despliegue. Su ficha del IETF incluye RFC 10024 y otros trabajos relacionados.

La atribución, sin embargo, debe conservar el equipo. Krzysztof Kwiatkowski, Panos Kampanakis y Douglas Stebila son coautores. El documento se apoya en el diseño general de RFC 9954, la terminología de RFC 9794, TLS 1.3 y el estándar ML-KEM de NIST. Westerbaan representa una continuidad entre esas capas, no una autoría exclusiva.

Un artículo de Cloudflare de septiembre de 2025 expuso la frontera con claridad. Más de un tercio del tráfico generado por personas hacia su red usaba TLS 1.3 con acuerdo de claves híbrido poscuántico. A la vez, la empresa explicó que las firmas y certificados poscuánticos seguían en proceso de estandarización para TLS y la PKI de Internet y que WARP aún no los había incorporado.

Ese ejemplo no autoriza a extrapolar el porcentaje a toda la red ni a todas las fechas. Tampoco certifica cada salto interno de Cloudflare. Sí demuestra que el despliegue amplio de una propiedad puede coexistir con otra propiedad pendiente. La migración gradual es un hecho técnico; ocultarla bajo «seguro frente a cuántica» sería una decisión editorial.

De la oferta al resultado observado

Un cliente incluye grupos en supported_groups. Eso prueba que los ofrece, no que el servidor seleccione uno. La selección confirma la negociación en el extremo visible. Todavía quedan implementación, fuentes de aleatoriedad, canales laterales, versiones de biblioteca y política de retorno.

Al completar la conexión, hay evidencia de que ambos extremos produjeron claves de tráfico utilizables. Para auditar la autenticación hace falta leer además la cadena de certificados y el algoritmo de firma. Para auditar la arquitectura hay que ubicar la terminación TLS, los proxies, el origen, las sesiones reanudadas, 0-RTT y cualquier túnel intermedio.

Tras el descifrado, la propiedad del apretón de manos deja de describir el tratamiento de los datos. Registros, bases, colas, copias de seguridad y otros servicios pueden usar claves completamente distintas. Recuperarse de un incidente puede exigir rotar certificados, claves de firma, tickets de sesión, secretos de aplicación y cifrado en reposo. Una medición en el borde no resuelve esa lista.

RFC 10024 también advierte que no debe suponerse segura una hibridación parecida en otros protocolos. El combinador, el orden, las longitudes y el transcript forman parte del análisis. Dos algoritmos colocados juntos no constituyen por sí solos un nuevo protocolo seguro.

RFC 9851 congela nuevas funciones de TLS 1.2 y orienta la innovación hacia TLS 1.3. Esa dirección reduce la tentación de improvisar extensiones en el protocolo antiguo, pero no sincroniza automáticamente certificados, bibliotecas, hardware y almacenamiento.

El registro que falta detrás de la etiqueta

La primacía del código en funcionamiento de Heng Lu propone verificar el resultado ejecutado, no la declaración. Para TLS poscuántico, el registro debería poder reproducir cliente, extremo, fecha, versión, grupos ofrecidos y elegidos, biblioteca, cadena de certificados, firma CertificateVerify, lugar de terminación, reanudación, protección aguas abajo y punto de descifrado.

La precisión también reparte responsabilidad. El IETF define mecanismos. Navegadores y bibliotecas implementan. Operadores configuran. Autoridades de certificación emiten. Equipos de red administran proxies. Aplicaciones guardan datos. Respuesta a incidentes revoca y recupera. Ningún propietario puede declarar completado el trabajo ajeno desde una única captura.

RFC 10024 convierte una parte crucial de la migración en algo nombrable y comprobable. Su mejor uso es cerrar exactamente esa parte del inventario, no borrar el resto.

Fuentes