NSA e IETF: Equidade

Artigo original ↗ Discussão no Hacker News ↗

Âmbito da disputa

  • A discussão centra-se em saber se o grupo de trabalho TLS da IETF deve publicar um RFC informativo descrevendo o uso de ML-KEM puro em TLS (KEM pós-quântico sem híbrido ECC) e na equidade do processo.
  • O autor do artigo é um crítico central do processo e do ML-KEM, mas a discussão se estende de forma mais ampla à governação de padrões, à influência da NSA e à maturidade da PQC.

Processo da IETF: “rough consensus” vs “votação”

  • Alguns argumentam que chamar às decisões do WG “votações” é enganador e enfraquece objeções procedimentais; a IETF funciona explicitamente por “rough consensus”, não por contagem de cabeças.
  • Outros observam que, na prática, chairs e processos ainda podem ser manipulados, mas consideram os argumentos legais sobre “consensus” e exceções antitrust exagerados ou juridicamente ingênuos.
  • Há preocupação de que críticas severas à IETF afastem pessoas que ainda a veem como fazendo, em grande medida, um bom trabalho, apesar de alguns maus atores.

Estado do ML-KEM em TLS

  • Os named groups apenas com ML-KEM já têm codepoints da IANA; o draft especifica sobretudo como usá-los em TLS e está marcado como “recommended = N”.
  • O híbrido ECC+ML-KEM já está padronizado e recomendado; a disputa é sobre documentar o ML-KEM puro como opção.
  • Alguns dizem que não há necessidade procedimental de levar isto pela IETF de todo: qualquer especificação pública basta para codepoints, e um fluxo RFC independente é (teoricamente) possível.

Segurança, maturidade e preocupações de side-channel

  • Um lado: KEMs de reticulado como o ML-KEM estão, para a sua idade, tão bem estudados quanto a ECC estava quando se tornou mainstream; o ML-KEM tem análises formais, histórico de implementação e o TLS híbrido já é amplamente usado.
  • Outro lado: a PQC (e o ML-KEM em particular) é mais recente, com falhas notáveis de implementação (por exemplo, fugas de timing KyberSlash); a tecnologia para implementações robustas e seguras contra side-channels ainda é imatura.
  • Crítica forte de que a FIPS 203 e o draft de TLS do ML-KEM tratam a resistência a side-channels como mera “encouragement” opcional, em vez de requisitos normativos; isto é contrastado com orientações mais específicas em alguns RFCs passados.
  • Alguns defendem que os padrões devem ser explicitamente resistentes a uso incorreto e evitar “footguns” como opções poderosas mas frágeis a side-channels.

Híbrido vs ML-KEM puro

  • Visão pró-híbrido: como a maturidade da PQC e o comportamento face a side-channels são incertos, a PQ deve ser adicionada à ECC existente, não a substituir; várias diretrizes governamentais europeias recomendam explicitamente o híbrido no curto a médio prazo.
  • Visão cética do híbrido: para esquemas bem concebidos, ECC+ML-KEM oferece benefício real marginal (como encadear cifras fortes) ao mesmo tempo que acrescenta complexidade; existe uma prova formal de que um certo híbrido permanece seguro mesmo se o ML-KEM falhar.
  • Alguns observam ambientes (por exemplo, telecomunicações) que alegadamente “têm de” usar ML-KEM puro, pelo que documentá-lo ajuda a interoperabilidade em vez de impor o seu uso.

Papel da NSA e confiança nos padrões

  • Um grupo enfatiza o papel histórico da NSA: pressionar por tamanhos de chave mais fracos no DES, o episódio da backdoor Dual_EC_DRBG, as restrições de exportação dos anos 1990 e os atuais algoritmos classificados Suite A como razões para profunda suspeita.
  • Outros contrapõem que:
    • O ML-KEM foi concebido por equipas académicas, não por uma agência de informações.
    • O principal organismo nacional de normalização e uma agência de sinais de inteligência são entidades distintas, com incentivos por vezes conflituantes (ofensiva vs defensiva).
    • A própria mudança da NSA para usar ML-KEM em níveis elevados de classificação sugere confiança, e não uma backdoor deliberada.
  • Uma minoria argumenta que o padrão de pressão de agências de inteligência contra híbridos é, por si só, suspeito e justifica cautela extrema.

Impacto de publicar (ou não) o RFC

  • Alguns dizem que publicar um RFC informativo com estatuto “not recommended” simplesmente reflete a prática existente e apoia outras SDOs (por exemplo, órgãos de telecomunicações e wireless) que enviaram liaisons a pedir uma referência estável.
  • Outros argumentam que qualquer RFC, mesmo informativo, confere “RFC sheen” e aumentará a adoção, incluindo em contextos onde o ML-KEM puro pode ser um risco desnecessário ou inseguro.
  • Há desacordo sobre se “as pessoas já o estão a fazer” é uma razão válida para padronizar, ou um caminho para legitimar práticas questionáveis.

Manipulação do processo e brigading

  • Vários comentários alegam “brigading” coordenado da mailing list do TLS por críticos do TLS apenas com ML-KEM, incluindo linhas de assunto em modelo e apelos para aderir apenas para se opor ao draft.
  • Participantes da IETF reiteram que aparentes “contagens de votos” não são decisivas; argumentos técnicos fortes e consenso dos implementadores podem sobrepor-se a números brutos.
  • Se o WG recusar publicar, os codepoints do ML-KEM continuam válidos; a principal diferença é a perda de um RFC oficial de ligação ao TLS.