OpenShift 4.22 activa ML-KEM por defecto y deja ML-DSA como el gran escollo

Red Hat OpenShift 4.22 negocia ya intercambio de claves post-cuánticas por defecto. Cuando un cliente con TLS 1.3 se conecta a un clúster de esa versión, la plataforma elige X25519MLKEM768 sin que nadie toque nada. Según la compañía, ese era el tramo fácil del camino; el complicado son las firmas digitales.

Red Hat ha publicado una actualización de su hoja de ruta sobre criptografía resistente a ataques cuánticos, un año después de la primera entrega. Entonces TLS 1.3 no era el valor por defecto en el plano de control y Go no tenía algoritmos post-cuánticos. Ahora las piezas han encajado y ML-KEM (FIPS 203) entra en producción.

Qué ha cambiado por debajo

Tres capas tuvieron que alinearse. Go 1.24 incorporó crypto/mlkem y habilitó el híbrido X25519MLKEM768 en crypto/tls. RHEL 9.8 y 10.2 llegaron con OpenSSL 3.5 y GnuTLS actualizado, lo que arrastra ML-KEM a RHEL CoreOS y a las imágenes UBI donde corren los pods del núcleo. Y TLS 1.3 quedó disponible en todo el plano de control de OpenShift desde la 4.19: API server, kubelet e ingress controller. OpenShift hereda la criptografía de la intersección de esas capas, así que cuando las tres ganaron ML-KEM, el clúster lo hizo detrás.

Para comprobar que un clúster usa intercambio post-cuántico basta con lanzar, contra un cliente que también soporte X25519MLKEM768:

openssl s_client -connect <endpoint>:6443

El grupo de intercambio debe aparecer como X25519MLKEM768. En RHEL 10.2 o superior el perfil crypto-policy DEFAULT lo activa solo; en 9.8 hay que fijar la subpolítica DEFAULT:PQ con update-crypto-policies --set. TLS 1.3 es requisito para todo esto: TLS 1.2 no sabe negociar algoritmos post-cuánticos. Quien quiera una postura solo TLS 1.3 puede pasar al perfil Modern o definir uno propio, según la documentación de perfiles TLS y este artículo sobre configuración TLS.

ML-DSA no es un cambio de configuración

Las firmas son otro problema. ML-KEM protege una conexión cada vez, en la capa de transporte, y si el otro extremo no lo soporta se cae al intercambio clásico. No toca un solo certificado. ML-DSA (FIPS 204) sustituye en cambio las firmas que sostienen cada decisión de confianza: certificados X.509, firma de código, firmas de imágenes de contenedor, tokens JWT, aserciones SAML, certificados de admission webhooks y firmas de bundles de operadores.

Una cadena de certificados no admite degradación elegante. Si una CA firma con ML-DSA, todo componente que valide ese certificado tiene que entender ML-DSA o la validación falla. La salida práctica es mantener dos cadenas en paralelo, una clásica y otra ML-DSA, y servir la que el cliente pueda verificar. Nada se rompe, pero mientras queden componentes en la cadena clásica la postura no es post-cuántica. En OpenShift eso significa actualizar y reemitir certificados en API server, kubelet, ingress controller, cada proxy sidecar, cada admission webhook y cada operador que valide certificados.

Para quien administra un clúster, la lectura práctica es que actualizar a 4.22 da protección en la capa de transporte sin tocar nada, pero la parte de firmas es un proyecto de arquitectura con inventario de certificados, no una casilla que marcar. Y el inventario, en una plataforma con operadores y webhooks de terceros, rara vez está completo.