Resumo

  • A RFC 9906 é um documento IETF Standards Track, publicado em novembro de 2025, e atualiza a RFC 5933.
  • GOST R 34.11-94 MUST NOT criar registros DS. Uma delegação que tenha apenas esse DS deve ser tratada como insegura quando não houver outro DS aceitável.
  • ECC-GOST MUST NOT criar DNSKEY ou RRSIG. Assinaturas antigas não suportadas levam os registros associados a um resultado inseguro quando não houver outra RRSIG aceitável.
  • Todas as células afetadas de signing, validation, implementation e use são MUST NOT. Operadores devem migrar para algoritmos suportados, e registros devem proibir o upload e a publicação de DS ECC-GOST.

A tese operacional da RFC 9906 é que a retirada completa precisa impedir tanto a criação de material quanto sua aceitação posterior. A RFC 9905, no caso do SHA-1, tratou de uma transição assimétrica e manteve uma obrigação de compatibilidade de validação. A RFC 9906 não manda manter suporte de validação para ECC-GOST: o material legado não permanece como caminho suportado, e a geração de novo material também é proibida.

Há duas regras distintas. Primeiro, GOST R 34.11-94 não pode criar DS. Se esse for o único DS de uma delegação e não existir outro DS aceitável, os registros abaixo do ponto de delegação devem ser tratados como inseguros. Segundo, ECC-GOST não pode criar DNSKEY nem RRSIG. O validador trata as RRSIG associadas como não suportadas; sem outra RRSIG aceitável, os registros de recurso correspondentes devem ser considerados inseguros. Esse resultado é insecure, não bogus e não failed: não se deve descrevê-lo como falha de validação criptográfica.

A fronteira com a GOST 2012 é explícita. Os algoritmos GOST 2012 documentados na RFC 9558 são distintos, e a RFC 9906 não altera seus níveis de requisito. Portanto, o operador deve identificar o número do algoritmo antes de remover material. A retirada se aplica ao par legado de 2001/1994, não à família GOST 2012.

Fontes