Resumo

  • O RFC 9934 define um arquivo PEM com zero ou uma chave privada PKCS #8 e uma ECHConfigList; se houver segredo, pelo menos uma configuração pública da lista deve corresponder a ele.
  • A correspondência prova coerência dentro do arquivo, não o conjunto carregado pelo servidor, a publicação DNS, a idade do cache, a aceitação ECH ou a privacidade observada.

Uma equipe pode fazer a rotação exatamente como está no manual e ainda terminar com gerações diferentes. O arquivo novo chega ao host, mas o processo não recarrega. O DNS muda, mas um resolvedor mantém a resposta antiga. O cliente tenta a chave velha quando o servidor já a removeu. Nenhuma falha aparece no validador do arquivo.

O RFC 9934 padroniza o objeto usado para entregar material ECH a servidores construídos com bibliotecas TLS distintas. Há zero ou uma chave privada, seguida por uma única ECHConfigList. Quando presente, a chave usa PKCS #8 e o rótulo PRIVATE KEY. A lista usa ECHCONFIG e contém em base64 o mesmo valor público que pode ser publicado em um registro HTTPS. Uma configuração listada precisa combinar com a chave privada.

O escopo é propositalmente local. Um arquivo pode ter apenas a lista pública. A lista pode conter várias configurações em ordem decrescente de preferência. Um servidor pode usar vários arquivos e escolher um subconjunto para retry_configs. O teste de correspondência não afirma que cada membro tem segredo disponível no processo em execução.

Existe também uma divisão de autorização: somente a ECHConfigList pode ir ao DNS; a chave privada não pode ser publicada. A automação precisa produzir uma projeção secreta e outra pública, ligadas por uma identidade de geração e separadas por permissões. Um único pacote para os dois destinos é perigoso; duas saídas sem vínculo verificável são incoerentes.

O RFC 7468 disciplina rótulos, limites e texto base64, inclusive diante de parsers históricos diferentes. O RFC 4648 disciplina a codificação. Ler os bytes não demonstra que o serviço os carregou ou que a custódia é estreita. Backups, snapshots, agentes de deploy e acesso de suporte fazem parte do controle prático.

No RFC 9849, o servidor deve considerar configurações atuais e antigas ainda mantidas por clientes durante o TTL ou mais. A aceitação depende de conseguir abrir o ClientHello interno. Caso falhe, o servidor trata o externo, rejeita ECH e pode enviar configurações de nova tentativa. O cliente precisa confirmar a aceitação; a conexão rejeitada não serve imediatamente para dados da aplicação.

Rotacionar significa coordenar criação, instalação, reload, zona autoritativa, expiração recursiva e retry. Retirar cedo demais quebra clientes ainda legítimos. Conservar indefinidamente aumenta exposição e custo. A janela precisa ser declarada e medida, não inferida do sucesso de um job.

O dossiê deve unir hash do arquivo, resultado do parser, quantidade e ordem dos blocos, correspondência criptográfica, leitores efetivos, recibos de instalação e reload, hash do conjunto ativo, RRSet autoritativo, observações recursivas com idade, lista vista pelo cliente, config_id, aceitação ou rejeição, hash de retry, certificado, Finished e observação de aplicação. O segredo nunca entra no dossiê.

O RFC 9848 mostra que a privacidade ainda depende do entorno. Endpoints mistos podem sofrer downgrade por bloqueio; DNS em claro, endereço IP, análise de tráfego e conjunto de anonimato pequeno ainda revelam sinais. O RFC 9460 padroniza o anúncio, não a memória secreta do servidor.

Pelo princípio de Heng Lu, cada execução fala apenas pelo que observou. O parser prova o arquivo; o servidor, o conjunto carregado; o DNS, a publicação; o cliente, a negociação; a aplicação, o efeito. O formato mínimo comum preserva interoperabilidade sem fingir que existe uma única política universal de rotação.

Fontes