Resumo

  • draft-ietf-dance-client-auth-14 faz o cliente TLS 1.3 transmitir o nome proprietário completo do seu TLSA; o servidor consulta esse nome, valida DNSSEC e compara o registro ao certificado ou à chave pública bruta.
  • A correspondência prova uma relação limitada entre DNS e chave. A atribuição atual, a allowlist, a permissão da aplicação e o efeito observado exigem provas próprias.

O servidor abre a possibilidade com dane_clientid vazio em CertificateRequest. O cliente responde em Certificate com o nome completo do registro. O servidor não deriva porta nem transporte: pergunta ao DNS exatamente o nome recebido. Se o RRset TLSA for validado por DNSSEC e uma associação combinar com o material criptográfico apresentado, o par demonstrou controle da chave privada correspondente.

O que falta é decisão local. A etiqueta pode designar pessoa, dispositivo, carga de trabalho ou identidade específica de serviço, mas DNSSEC autentica dados, não a política que dá sentido ao nome. A revisão 14 reconhece que servidores mantêm regras próprias de allowlisting e autorização. Depois delas, a aplicação ainda precisa julgar recurso, tenant, ação e transação.

O processo ainda está aberto

A revisão 14, de 11 de setembro de 2026, aparece no Datatracker como Internet-Draft ativo do grupo DANCE, destinado a Proposed Standard. O segundo IETF Last Call termina em 29 de setembro. Não é aprovação, RFC ou evidência de implantação.

O Security Directorate marcou Ready com comentários menores. O DNS Directorate marcou Not ready: os formatos _service e _device não atenderiam ao registro de nomes sublinhados do RFC 8552, e a explicação de ClientName confundiria apresentação textual com limite de 255 octetos. Os dois pareceres permanecem válidos no registro atual.

Variações de autenticação, mesma fronteira de autoridade

O servidor valida o TLSA até um trust anchor configurado ou confia em um resolvedor validador acessado com segurança e no bit AD. Resposta sem assinatura, delegação insegura, falha DNSSEC, NXDOMAIN e NODATA não formam um conjunto autenticado. A política escolhe abortar ou manter o cliente sem autenticação.

DANE-EE 3 compara diretamente certificado ou chave; o nome pode nem estar no certificado. DANE-TA 2 e PKIX 0/1 ainda exigem ClientName como dNSName no SAN segundo o RFC 7671. Chaves públicas brutas seguem o RFC 7250. Esses caminhos alteram a prova criptográfica, não o direito de usar uma aplicação.

Uma trilha séria separa ClientName, consulta e TTL, validador e trust anchor, campos TLSA, certificado ou SPKI, atribuição do nome, estado do dispositivo/conta, allowlist, decisão da aplicação e resultado. Cache DNS pode sobreviver a uma reatribuição. Handshake pode passar e a aplicação negar. Ação autorizada pode falhar ou ser revertida.

TLS 1.3 cifra Certificate, mas a consulta DNS seguinte pode expor o nome. A minimização de QNAME do RFC 9156 reduz a informação vista em níveis superiores. Exposição observada não é prova de comprometimento.