Resumo

  • A RFC 9558 associa o algoritmo DNSSEC 23 ao GOST R 34.10-2012 e o tipo de digest DS 5 ao GOST R 34.11-2012, com codificação estritamente delimitada.
  • É uma publicação Informational do fluxo Independent Submission, sem consenso do IETF e sem atestado independente de adequação criptográfica ou implantação.
  • O resultado defensável depende de recibos separados para registro, suporte no assinador, publicação, DS no pai, capacidade do validador, validação da cadeia e decisão da aplicação.

A mudança passou no laboratório e sumiu na rede do cliente

O operador assinou a zona com o algoritmo 23. A DNSKEY tinha 64 octetos no formato indicado. As RRSIG estavam no período de validade. O pai publicou um DS de tipo 5. A verificação no ambiente de homologação terminou em Secure.

Na rede de um cliente, o recursor não implementava a combinação. Conforme a semântica consolidada pela RFC 6840, ele desconsiderou os DS referentes a algoritmo de chave ou digest que não suportava. Como não restou outro caminho, tratou a zona como não assinada. Não havia uma assinatura comprovadamente ruim; faltava uma rota executável naquele software.

Esse é o limite que uma entrada de registro não consegue atravessar. IANA torna o objeto identificável. A RFC torna o formato reproduzível. Só o código instalado, sua configuração e o estado observado podem tornar a validação real.

Nem todo RFC carrega a mesma autoridade

A RFC 9558 saiu em abril de 2024 como Informational no Independent Submission stream. Não é Standards Track, não representa consenso da comunidade IETF e não tem endosso formal no processo de padrões do IETF. O RFC Editor não afirma que o texto seja valioso para implementação ou implantação.

O aviso criptográfico também é explícito. GOST R 34.10-2012 e GOST R 34.11-2012 são padrões nacionais russos cujas propriedades não foram verificadas de forma independente nesse processo. IETF e IRTF não analisaram sua adequação a uma aplicação específica.

Registrar esses limites não diminui o trabalho técnico. Evita que ele seja usado para uma conclusão maior. O documento coordena quem já decide implementar a suíte; não decide a política de aceitação do assinador, do recursor ou da organização usuária.

A interoperabilidade mora nos detalhes binários

O perfil escolhe a variante de assinatura de 256 bits, o digest de 256 bits e o conjunto de parâmetros A. O ponto elíptico Q=(x,y) ocupa 64 octetos na DNSKEY: 32 octetos little-endian de x, seguidos por 32 de y. Chave pública e assinatura têm 512 bits; o digest tem 256.

Uma biblioteca pode manipular o ponto matemático correto e ainda gravar a ordem de bytes errada. Para APIs X.509 já conscientes de GOST, a RFC fornece um prefixo ASN.1 SubjectPublicKeyInfo fixo de 30 bytes. Ele adapta representações; não cria certificado, autoridade ou confiança.

Na RRSIG, a entrada de assinatura da RFC 4034 é resumida com GOST R 34.11-2012 e assinada com GOST R 34.10-2012. O k mostrado no exemplo serve somente para reprodução e não deve aparecer em assinaturas reais. Igualar um vetor de teste não prova a qualidade do gerador de produção.

O 23 e o 5 fecham junções diferentes

No registro da IANA, ECC-GOST12 ocupa o algoritmo DNSSEC 23. No registro de DS, GOST R 34.11-2012 ocupa o tipo de digest 5 com status OPTIONAL. O primeiro orienta a leitura de DNSKEY e RRSIG; o segundo orienta a ligação do DS no pai à DNSKEY do filho.

Uma RRSIG válida, sem DS utilizável, não forma uma cadeia até o pai. Um DS correspondente, sem suporte do validador, também não. Mesmo com implementação, âncoras distintas, caches e janelas de validade podem produzir conclusões diferentes.

O recibo operacional deve guardar os RRsets exatos, serial da zona, pontos de observação no pai e no filho, inception e expiration, TTL, âncora, versão do validador e inventário de algoritmos. “DNSSEC ligado” é apenas uma configuração alegada.

Insecure e Bogus pedem respostas diferentes

Quando todos os caminhos são descartados por falta de suporte, a zona pode ser tratada como não assinada. Bogus descreve a falha de uma rota que o validador conseguia testar. Misturar ambos os casos leva a correções erradas: refazer assinaturas não instala um algoritmo ausente; atualizar software não corrige uma assinatura realmente inválida.

Toda análise deve responder qual recursor, versão, conjunto de algoritmos, confiança configurada, RRsets e instante produziram o estado. Uma ferramenta que valida de um único ponto mede esse ponto, não a população mundial de resolvers.

Duas KSKs compram compatibilidade e cobram coordenação

A RFC 9558 recomenda uma zona assinada com dois algoritmos de KSK enquanto o suporte GOST não for difundido, exceto quando o objetivo for deliberadamente GOST-only. O caminho alternativo permite que validadores sem algoritmo 23 continuem autenticando a zona.

Ao mesmo tempo, aparecem mais chaves, DS, assinaturas, períodos, caches e decisões de retirada. A RFC 6840 recomenda aceitar qualquer RRSIG válida e concluir Bogus apenas se todas falharem, mas uma política local mais restritiva e dados coletados em momentos distintos ainda podem divergir.

É preciso definir o fim antes do começo. Depois de adicionar a nova rota, medir os validadores importantes. Antes de remover a antiga, verificar o DS parental, a publicação autoritativa, a expiração dos caches e observações externas. Ver duas chaves não é autorização para apagar uma.

O resultado da aplicação fica além da cadeia DNSSEC

Secure prova que um RRset foi autenticado em relação a uma âncora configurada, segundo regras DNSSEC e dentro de um intervalo. Não prova a identidade jurídica do operador, a disponibilidade do serviço, a adequação da criptografia a toda política ou o sucesso de uma conexão posterior.

DO solicita material DNSSEC; CD muda o comportamento de checagem; AD comunica estado autenticado em condições específicas. Um stub em canal não confiável, ou uma aplicação que não usa esse estado, não obtém prova ponta a ponta só porque viu um bit.

O último recibo nomeia o recursor confiado, o canal, o estado recebido, a regra da aplicação, a ação e o efeito observado. A RFC 9558 faz o objeto caber no DNS. Não decide o que o usuário deve fazer com ele.

Fontes

Fontes