NSA e IETF: equidad

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

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.