NSA e IETF: equidad

Artículo original ↗ Discusión en Hacker News ↗

Una disputa sobre cómo estandarizar el intercambio de claves poscuántico en TLS está revelando profundas divisiones sobre cuánto confiar tanto en los nuevos esquemas basados en retículas (ML‑KEM/Kyber) como en el proceso de consenso de la Internet Engineering Task Force. Los críticos argumentan que publicar un RFC para ML‑KEM “puro”, sin exigir su uso híbrido junto con métodos de curva elíptica ya establecidos y con orientaciones débiles sobre resistencia a canales laterales, corre el riesgo de crear una aprobación de facto de una criptografía todavía inmadura, especialmente dada la historia de la NSA y NIST con estándares debilitados. Los partidarios responden que ML‑KEM fue seleccionado mediante una competencia abierta, ya está desplegado y cuenta con códigos TLS, y que documentar cómo usarlo en TLS es necesario para la interoperabilidad y no un mandato para adoptarlo.

Alcance de la disputa

  • El hilo se centra en si el grupo de trabajo TLS de la IETF debería publicar un RFC informativo que describa el uso de ML-KEM puro en TLS (KEM poscuántico sin híbrido ECC), y en la equidad del proceso.
  • El autor del artículo es un crítico central del proceso y de ML-KEM, pero la discusión abarca más ampliamente la gobernanza de los estándares, la influencia de la NSA y la madurez de la PQC.

Proceso de la IETF: “consenso aproximado” vs “votación”

  • Algunos sostienen que llamar “votaciones” a las decisiones del grupo de trabajo es engañoso y debilita las objeciones procedimentales; la IETF explícitamente funciona por “consenso aproximado”, no contando cabezas.
  • Otros señalan que, en la práctica, los presidentes y los procesos aún pueden ser manipulados, pero consideran que los argumentos legales sobre “consenso” y las excepciones antimonopolio están exagerados o son jurídicamente ingenuos.
  • Hay preocupación de que la crítica dura a la IETF aleje a personas que siguen viéndola como una organización que, en general, hace un buen trabajo, a pesar de algunos malos actores.

Estado de ML-KEM en TLS

  • Los grupos nombrados de solo ML-KEM ya tienen códigos de IANA; el borrador principalmente especifica cómo usarlos en TLS y está marcado como “recommended = N”.
  • El híbrido ECC+ML-KEM ya está estandarizado y recomendado; la disputa es sobre documentar ML-KEM puro como una opción.
  • Algunos dicen que no hay necesidad procedimental de llevar esto por la IETF en absoluto: cualquier especificación pública basta para los códigos, y un flujo RFC independiente es (teóricamente) posible.

Seguridad, madurez y preocupaciones de canal lateral

  • Un lado: los KEM de retículas como ML-KEM están bastante estudiados (para su antigüedad), del mismo modo que lo estaba ECC cuando se volvió dominante; ML-KEM tiene análisis formales, historial de despliegue y TLS híbrido ya se usa ampliamente.
  • El otro lado: la PQC (y ML-KEM en particular) es más nueva, con fallos de implementación notables (por ejemplo, fugas temporales KyberSlash); la tecnología para implementaciones robustas y seguras frente a canales laterales sigue siendo inmadura.
  • Crítica fuerte a que FIPS 203 y el borrador de TLS de ML-KEM traten la resistencia a canales laterales como una “recomendación” opcional y no como un requisito normativo; se contrasta con orientaciones más específicas en algunos RFC anteriores.
  • Algunos sostienen que los estándares deberían ser explícitamente resistentes al mal uso y evitar “footguns” como opciones potentes pero frágiles frente a canales laterales.

Híbrido vs. ML-KEM puro

  • Visión pro-híbrido: dado que la madurez de la PQC y el comportamiento frente a canales laterales son inciertos, la PQ debería añadirse al ECC existente, no reemplazarlo; varias directrices gubernamentales europeas recomiendan explícitamente el híbrido en el corto y medio plazo.
  • Visión escéptica del híbrido: para esquemas bien diseñados, ECC+ML-KEM aporta un beneficio real marginal (como encadenar cifrados fuertes) mientras añade complejidad; existe una demostración formal de que cierto híbrido sigue siendo seguro incluso si ML-KEM falla.
  • Algunos señalan entornos (por ejemplo, telecomunicaciones) que supuestamente “tienen que” usar ML-KEM puro, por lo que documentarlo ayuda a la interoperabilidad en vez de forzar su uso.

Papel de la NSA y confianza en los estándares

  • Un sector enfatiza el papel histórico de la NSA: impulsar tamaños de clave más débiles en DES, el episodio de la puerta trasera de Dual_EC_DRBG, las restricciones de exportación de los años 90 y los algoritmos clasificados actuales de Suite A como razones para una profunda suspicacia.
  • Otros responden que:
    • ML-KEM fue diseñado por equipos académicos, no por una agencia de inteligencia.
    • El organismo nacional de estándares y una agencia de inteligencia de señales son entidades distintas, con incentivos a veces conflictivos (ofensiva vs. defensiva).
    • El propio movimiento de la NSA para usar ML-KEM en niveles altos de clasificación sugiere confianza y no una puerta trasera deliberada.
  • Una minoría argumenta que el patrón de presión de agencias de inteligencia contra los híbridos es en sí sospechoso y justifica una cautela extrema.

Impacto de publicar (o no) el RFC

  • Algunos dicen que publicar un RFC informativo con estado “not recommended” simplemente refleja la práctica existente y apoya a otros SDOs (por ejemplo, organismos de telecomunicaciones e inalámbricos) que han enviado contactos pidiendo una referencia estable.
  • Otros sostienen que cualquier RFC, incluso informativo, confiere “aura de RFC” y aumentará el despliegue, incluso en contextos donde ML-KEM puro puede ser un riesgo innecesario o inseguro.
  • Hay desacuerdo sobre si “ya hay gente haciéndolo” es una razón válida para estandarizarlo o un camino para avalar de manera acrítica prácticas cuestionables.

Manipulación del proceso y brigading

  • Varios comentarios alegan “brigading” coordinado de la lista TLS por críticos de TLS de solo ML-KEM, incluidos asuntos de correo con plantillas y llamados a unirse solo para oponerse al borrador.
  • Los participantes de la IETF reiteran que los aparentes “conteos de votos” no son decisivos; los argumentos técnicos sólidos y el consenso de implementadores pueden pesar más que los números brutos.
  • Si el grupo de trabajo decide no publicar, los códigos de ML-KEM siguen siendo válidos; la principal diferencia es la pérdida de un RFC oficial de vinculación con TLS.