Resumo

  • Em 10 de setembro de 2026, a IESG negou um recurso, liberou a suspensão de publicação e enviou o anúncio de aprovação do draft-ietf-tls-mldsa-05. O texto descreve o uso das assinaturas ML-DSA do FIPS 204 na autenticação do TLS 1.3. A categoria pretendida é RFC Informational; na verificação, o documento ainda era um Internet-Draft sem número de RFC.
  • O registro TLS SignatureScheme da IANA já contém mldsa44, mldsa65 e mldsa87 em 0x0904, 0x0905 e 0x0906. As três entradas estão marcadas como N. Pelo RFC 9847, N indica que a IETF não fez declaração de adequação ou não tem consenso; não é o marcador D de desaconselhado.
  • Aprovar a publicação, atribuir identificadores interoperáveis e recomendar implantação são atos diferentes. A decisão do recurso encerra uma controvérsia processual sobre a publicação, mas não escolhe ML-DSA puro ou composto para todo operador.
  • Um adotante deve emitir um comprovante local com a superfície TLS, o parâmetro e o perfil escolhidos, populações de pares e certificados, evidências datadas, limites de falha, reversão, responsável e data de revisão.

O consenso decidiu publicar

O histórico no Datatracker registra uma aprovação em 8 de julho, seguida no mesmo dia por uma suspensão enquanto a IESG analisava um recurso. Em 10 de setembro, a IESG negou o pedido, retirou a suspensão e devolveu o texto ao estado de anúncio aprovado. A comunicação oficial o apresenta como produto do grupo de trabalho TLS destinado à publicação como RFC Informational.

A divergência não foi apagada. O resumo do shepherd fala em cerca de 275 mensagens e estima uma proporção próxima de quatro manifestações favoráveis para uma contrária ao avanço. Também identifica posições diferentes: não publicar ML-DSA puro, recomendar esquemas compostos ou publicar os dois caminhos. A resposta da IESG ao recurso afirma que revisou a consulta final do grupo, encontrou apoio amplo e verificou que as objeções foram consideradas e discutidas. Deb Cooley, diretora da Área de Segurança, não participou da decisão.

Esse resultado confirma uma decisão de processo: havia rough consensus suficiente para o documento avançar apesar da oposição. Ele não transforma a proporção de mensagens em plebiscito de implantação, nem a negativa do recurso em prova de segurança. O risco de uma cadeia de certificados, de um conjunto de clientes ou de uma operação específica continua pertencendo a quem controla esse sistema.

Também existe uma diferença entre aprovação e publicação concluída. A página atual do draft exibe Approved-announcement sent, mas ainda o classifica como Internet-Draft ativo. A revisão da IANA está em Version Changed - Review Needed e a ação em In Progress. Sem um número de RFC, o fato preciso é que a publicação foi autorizada, não que o RFC já tenha sido emitido.

Três valores fecham uma lacuna de linguagem

O FIPS 204 padroniza o ML-DSA como algoritmo de assinatura digital pós-quântica. O documento da IETF faz um trabalho mais delimitado: conecta os três conjuntos de parâmetros à negociação de assinatura do TLS 1.3. ML-DSA-44 corresponde a mldsa44 e 0x0904; ML-DSA-65, a mldsa65 e 0x0905; ML-DSA-87, a mldsa87 e 0x0906.

O RFC 9881 fornece os AlgorithmIdentifiers X.509 correspondentes. O draft TLS liga esses identificadores aos SignatureSchemes. Quando um deles é usado em CertificateVerify, assinatura e verificação seguem o FIPS 204 com ctx vazio, e o certificado de entidade final precisa usar o identificador compatível. As variantes pré-hash HashML-DSA não fazem parte desse mecanismo.

Essa especificação permite que implementações independentes interpretem os mesmos valores e formatos de certificado. Ela não prova que uma autoridade certificadora emitirá a cadeia necessária, que todos os clientes a aceitarão, que a proteção da chave no hardware escolhido é suficiente ou que uma frota mista consegue desfazer uma ativação parcial. Interoperabilidade no fio é evidência necessária, não conclusão operacional.

As três linhas já estão no registro ao vivo da IANA com N. A referência ainda aponta para uma revisão antiga do draft, enquanto o Datatracker mostra trabalho da IANA em andamento. A descrição responsável preserva os dois fatos: os valores estão atribuídos e visíveis; a limpeza de referências e o fluxo editorial final ainda não terminaram.

N não significa “negado”

O RFC 9847 transforma a coluna Recommended em um campo de três estados. Y informa consenso da IETF de que o item é recomendado e adequado à finalidade definida, respeitadas as limitações do documento. D significa desaconselhado e exige uma razão. N quer dizer que a IETF não avaliou ou não declarou a adequação, que não há consenso ou que o uso pode ser restrito.

O texto é explícito: N não implica necessariamente que o mecanismo tenha defeito. Portanto, a atribuição de um valor não é sinal verde; a letra N tampouco é sinal vermelho. Ela mantém disponível uma linguagem comum para implementação e experimentação sem inventar uma recomendação que a IETF não fez.

Se cada codepoint virar aprovação, a manutenção de registro se torna uma autoridade de segurança por acidente. Se N virar “reprovado”, a ausência de consenso se transforma em proibição e testes controlados passam a parecer ilegítimos. O campo só funciona quando sistemas e relatórios mantêm seu significado original.

Puro e composto continuam em planos institucionais diferentes

O documento aprovado trata de ML-DSA puro. Um Internet-Draft individual ativo descreve à parte assinaturas compostas, combinando ML-DSA com um algoritmo tradicional no TLS 1.3. O Datatracker informa que esse draft individual não tem endosso de um stream da IETF. Ele prova que existe uma alternativa técnica desenvolvida, não que os dois perfis tenham a mesma autoridade.

O perfil puro dispensa a validação bem-sucedida de uma segunda assinatura, mas concentra a garantia em ML-DSA e sua implementação. Um perfil composto pode manter uma componente clássica caso o algoritmo novo ou seu código falhe, ao custo de certificados e mensagens maiores, mais processamento e novos pontos de incompatibilidade. O modelo de ameaça e a população de pares definem o peso desses custos.

A lista de implementações no anúncio também tem escopo limitado. Código em OpenSSL, BoringSSL, rustls-post-quantum, s2n-tls, wolfSSL, Bouncy Castle ou GnuTLS mostra caminhos concretos de engenharia. Não mostra ativação padrão, tráfego de produção, cadeias compatíveis, configuração comum, latência aceitável ou reversão ensaiada em uma frota real.

O comprovante de implantação pertence ao operador

O primeiro campo deve nomear o uso TLS, não apenas dizer “pronto para pós-quântico”. Autenticação de servidor, autenticação de cliente, serviço privado delimitado e ensaio público são objetos diferentes. O parâmetro ML-DSA e a escolha puro/composto precisam ficar explícitos.

Depois vem a população: emissores, perfis de certificado, endpoints, clientes, bibliotecas e fronteiras de hardware. A negociação deve ter resultado definido quando o outro lado não anuncia o novo valor. A conexão falha, usa outra cadeia, muda de rota ou recua para um algoritmo permitido? Um fallback silencioso pode preservar disponibilidade e eliminar a garantia que motivou o projeto.

As evidências precisam de data e diversidade. Testes de interoperabilidade devem cruzar famílias de implementação, e não apenas duas versões da mesma biblioteca. Tamanho do handshake, CPU e latência precisam ser medidos sob concorrência realista. Geração de chave, assinatura, verificação, modo aleatório ou determinístico e vazamentos de implementação devem ser examinados no limite operacional concreto. Emissão e validação da cadeia completa também devem passar pelo ensaio.

Por fim, o registro aponta quem amplia e quem desliga, qual telemetria aciona a reversão, como certificados e chaves distribuídos serão retirados, quando a evidência expira e quando a decisão será revista. O comprovante não altera a coluna da IANA. Ele localiza a decisão futura na instituição capaz de responder por ela.

Limites das evidências

Nenhuma fonte citada demonstra ativação padrão ou uso geral em produção. Elas não estabelecem superioridade universal do perfil puro ou composto. A resposta ao recurso é um juízo processual, não uma prova criptográfica. A padronização pelo NIST não avalia um ambiente TLS específico. A presença das linhas no registro não comprova o encerramento de todo o trabalho da IANA e do RFC Editor.

O achado delimitado é este: a IETF autorizou a publicação de uma especificação que dá significado interoperável a três parâmetros ML-DSA no TLS 1.3, enquanto o registro preserva N. A próxima decisão pertence ao adotante e precisa de uma evidência própria.

Fontes

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. IESG — Anúncio de aprovação de Use of ML-DSA in TLS 1.3
  5. IETF Datatracker — draft-ietf-tls-mldsa-05
  6. IETF Datatracker — Histórico do documento
  7. IESG — Resposta ao recurso, artefato 320
  8. IANA — Parâmetros de Transport Layer Security
  9. RFC 9847 — Atualizações de registros IANA para TLS e DTLS
  10. NIST — FIPS 204, padrão ML-DSA
  11. RFC 9881 — Identificadores de algoritmo para ML-DSA
  12. RFC 9846 — O protocolo TLS 1.3
  13. IETF Datatracker — Use of Composite ML-DSA in TLS 1.3