Resumo

  • Enviada em 11 de setembro, a revisão 14 de draft-ietf-dance-client-auth continua em Working Group Last Call e não é um RFC nem um padrão aprovado.
  • A nova redação enumera quatro resultados diferentes de um conjunto TLSA validado por DNSSEC: falha de validação, resposta não autenticada, NXDOMAIN e NODATA. O servidor aborta ou, se sua política permitir, trata o cliente como não autenticado.
  • Uma ficha mínima de decisão de consulta pode guardar a classe DNS, o caminho de confiança, a versão da política e a autorização posterior. Trata-se de proposta editorial, não de requisito da IETF.

Um avanço textual, não um selo final

O Datatracker registra “TLS Client Authentication via DANE TLSA records” como documento ativo do grupo DANCE, na Área de Segurança da IETF. A revisão 14 é de 11 de setembro de 2026. Seu destino pretendido é Proposed Standard, mas a situação atual permanece In WG Last Call, com acompanhamento do document shepherd. No IESG, aparece Waiting for AD Go-Ahead::AD Followup.

O histórico impede confundir atualização com aprovação. A revisão 13 foi publicada em 23 de julho. Em 28 de julho, o estado do grupo voltou de Submitted to IESG for Publication para In WG Last Call. A versão de setembro é trabalho em curso.

O trecho alterado é pequeno. A revisão 13 dizia o que fazer se a validação DNSSEC falhasse. A revisão 14 cobre qualquer resultado que não seja um RRset TLSA validado por DNSSEC e lista quatro classes. A especificação ganhou precisão sobre a entrada sem retirar a decisão final do operador.

Para todas, a regra oferece a mesma bifurcação normativa. O servidor deve encerrar com o alerta TLS handshake_failure ou, quando sua política autorizar, considerar o cliente não autenticado. Continuar não significa conceder acesso; significa apenas que a conexão não terminou nessa etapa.

O nome vem do cliente

O DANE dos RFC 6698 e 7671 é conhecido pelo uso de TLSA para verificar a chave ou o certificado do servidor. O projeto DANCE aplica a confiança baseada em DNS ao outro participante.

O servidor compatível anuncia a extensão proposta dane_clientid em CertificateRequest. O cliente que pretende usar DANE responde, em sua mensagem Certificate, com o nome completo do registro TLSA. O servidor consulta exatamente esse nome; não o deriva de porta e transporte. O mecanismo exige TLS 1.3 ou DTLS 1.3 ou posterior.

O servidor pode validar DNSSEC localmente até uma âncora configurada, em geral a raiz. Também pode confiar num resolvedor validador acessado por conexão segura e exigir o bit AD. Essas alternativas podem produzir a mesma classificação, mas não a mesma cadeia de custódia da decisão.

No corte desta pesquisa, o registro IANA de extensões TLS não exibe valor atribuído a dane_clientid. O rascunho fala da atribuição no futuro. Não há fundamento para afirmar número, implantação ou suporte de fornecedores.

Quatro diagnósticos que não são sinônimos

Uma falha de validação DNSSEC informa que os dados não foram autenticados segundo a cadeia e as regras aplicáveis. Isso não determina se houve ataque, erro operacional ou outra causa.

Uma resposta não autenticada por zona sem assinatura ou delegação insegura é diferente. Nesse ponto não há cadeia segura que exija a mesma validação. O RFC 4033 distingue zona assinada, zona não assinada e expectativa criada por uma âncora de confiança. Chamar toda resposta insegura de inválida apaga essa arquitetura.

NXDOMAIN significa que o nome consultado não existe. NODATA permite que o nome exista, sem um registro TLSA daquele tipo. A distinção do RFC 2308 orienta investigações diferentes: identidade removida não é o mesmo que identidade criada sem credencial publicada.

Nenhuma classe é um veredito de má-fé. Nome desatualizado, delegação deliberadamente insegura, provisionamento incompleto ou cadeia quebrada são hipóteses que exigem evidência adicional.

Se o log grava apenas handshake_failure, perde a diferença. Se grava apenas “conexão aceita sem autenticação”, também. A política pode estar correta e ainda assim produzir um histórico incapaz de explicar por que foi usada.

Correspondência e autorização vêm depois

Um RRset TLSA validado abre a etapa seguinte. O servidor precisa aplicar os campos de uso do certificado, seletor e tipo de correspondência ao certificado ou à chave pública apresentada. Se não houver correspondência, a política volta a escolher entre abortar e tratar o cliente como não autenticado.

Quando há correspondência, o cliente está autenticado pelo mecanismo DANE. Ainda assim, o texto permite regras próprias de allowlist e autorização. Um domínio autenticado pode estar fora da lista permitida. Uma sessão não autenticada pode continuar apenas para uma página pública. Estado de transporte não é sinônimo de privilégio.

O registro operacional precisa, portanto, de três degraus: resultado DNS, correspondência DANE e decisão de autorização. Um único campo de sucesso mistura autoridades e torna a explicação impossível.

Uma ficha pequena e protegida

Levar o prontuário inteiro para TLS criaria outro risco. Nomes de clientes podem identificar pessoas, equipamentos e funções; as considerações de segurança do próprio projeto alertam para correlação. A solução proporcional é uma ficha de decisão de consulta local, com acesso e retenção limitados. Esta é uma proposta editorial de Daniel Kade, não uma regra da IETF, DANCE ou IANA.

A ficha pode vincular horário; representação autorizada ou hash protegido do nome TLSA fornecido; tipo de consulta; uma das quatro classes; estado DNSSEC; validação local ou resolvedor protegido; referência da âncora ou política de resolução; versão da política do servidor; e ramo escolhido. Se a execução chegar à comparação do certificado e à autorização, esses resultados aparecem em campos separados.

Uma etapa não alcançada deve continuar como não alcançada. NXDOMAIN não autoriza inventar falha de certificado, e delegação insegura não deve virar “bogus” por conveniência. Relatórios públicos podem agregar contagens e mudanças de regra sem expor nomes ou trajetos individuais.

O Policy Mirror de Heng Lu pede que ator, regra e evidência permaneçam visíveis. O operador DNS controla nomes e delegações; o cliente fornece a identidade a consultar; o servidor escolhe validação e tratamento TLS; a aplicação concede direitos. A Minimum Initial Specification preserva decisões futuras ao limitar o núcleo comum. A revisão 14 deixa a tolerância no servidor. A ficha impede que essa tolerância perca sua justificativa observável.

Fontes

  1. IETF Datatracker — draft-ietf-dance-client-auth-14
  2. Histórico do documento
  3. Revisão 13
  4. Revisão 14
  5. Grupo de trabalho DANCE
  6. RFC 6698 — DANE TLSA
  7. RFC 7671 — operação de DANE
  8. RFC 2308 — cache negativo de DNS
  9. RFC 4033 — introdução e requisitos de DNSSEC
  10. Registro IANA de TLS ExtensionType
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification