Resumo

  • O owner name de TLSA incorpora porta, protocolo de transporte e domínio-base. O resultado positivo prova uma associação naquele contexto e modelo de validação, não confiança universal no certificado, host ou organização.
  • A evidência precisa reter nome consultado, estado DNSSEC, certificate usage, selector, matching type, material apresentado, regra da aplicação e horário. “DANE passou” sozinho não permite reproduzir a decisão.

Uma porta nova cria uma pergunta nova

Considere um teste ilustrativo. service.example apresenta o mesmo certificado nas portas TCP 443 e 8443. A zona assinada publica um RRset TLSA utilizável apenas em _443._tcp.service.example. O cliente da porta 443 valida DNSSEC e compara o objeto especificado. Para 8443, a consulta correta é _8443._tcp.service.example; o sucesso anterior não pode ser importado.

O cenário não acusa um produto. Ele testa a frase “esse certificado já passou no DANE nesse host”. RFC 6698 não atribui reputação DANE ao host. Porta e transporte fazem parte do nome para que serviços na mesma máquina mantenham associações, responsáveis e ciclos de rotação diferentes.

Quando o banco grava somente hostname e fingerprint, elimina justamente o escopo que tornava o resultado verdadeiro. Mais tarde, a mesma chave pode aparecer em vários listeners sem que o registro mostre qual deles havia sido autorizado.

O nome precisa ser derivado e preservado

Em TLS direto sobre TCP, a forma comum é _porta._tcp.domínio-base. A porta é decimal; o rótulo de transporte separa TCP de outros mecanismos; o domínio-base vem da especificação da aplicação.

CNAME pode deslocar a resolução. Aplicações baseadas em SRV usam a derivação do RFC 7673. SMTP DANE começa na descoberta MX e possui regras próprias para domínio-base, identificadores de referência, falhas DNS e fallback. O endereço final do socket não reconstrói sozinho a autoridade.

O registro mínimo deve guardar destino original, etapas MX/SRV/CNAME, nomes antes e depois da expansão, porta, transporte, consulta TLSA, estado DNSSEC e regra normativa. Sem a cadeia, outra equipe não consegue repetir “TLSA matched”.

Os quatro usages não são sinônimos

PKIX-TA(0) restringe uma CA e mantém a validação PKIX. PKIX-EE(1) restringe o certificado final, ainda exigindo caminho PKIX válido. DANE-TA(2) publica uma associação de trust anchor via DNSSEC. DANE-EE(3) associa diretamente o serviço ao certificado final ou à chave.

Uma coincidência de bytes não apaga essas diferenças. No uso 1, material correspondente não salva certificado expirado nem cadeia inválida. No uso 3, não se devem inventar verificações de nome que o perfil da aplicação não exige. SMTP DANE também restringe os usos adequados ao seu modelo oportunista.

Assim, a decisão inclui quem publicou qual uso, para qual serviço, sob qual zona assinada, que cliente o implementou e que política decidiu o comportamento de falha.

Selector e matching type definem o que foi comparado

Selector 0 escolhe o certificado DER completo; selector 1 escolhe SubjectPublicKeyInfo. Um certificado pode ser renovado com a mesma chave: o primeiro objeto muda, o segundo talvez não.

Matching type 0 compara os bytes; 1 usa SHA-256; 2 usa SHA-512. Uma sequência hexadecimal isolada não informa se representa certificado, chave ou resumo.

Cada opção muda o custo de rotação e recuperação. Associação ao certificado inteiro é estreita, mas exige atualização coordenada na renovação. SPKI facilita renovação com a mesma chave e amplia o efeito de uma chave comprometida. Uma âncora DANE cobre outro raio de mudança. Custódia e rollback, não a aparência do hash, orientam a escolha.

DNSSEC é o que autoriza a publicação

Receber um RR type 52 bem formado não basta. O validador separa secure, insecure, bogus e indeterminate. Extended DNS Error ajuda a explicar, mas não substitui DS, DNSKEY e RRSIG.

Uma resposta não assinada não pode reduzir a validação de certificados. Por outro lado, quando a aplicação trata um RRset secure e utilizável como compromisso, fallback silencioso depois de uma falha reabre downgrade. Em SMTP DANE, um servidor cuja associação segura não autentica não deve receber a mensagem por aquele caminho.

DNSSEC autentica publicação sob um nome. Não prova custódia exclusiva da chave TLS nem configuração correta. O comprometimento da assinatura DNS pode publicar novo DANE-EE; o da chave TLS pode satisfazer o registro antigo. São planos diferentes de autoridade.

A aplicação ainda precisa decidir

TLSA pode provar que o material do handshake satisfez uma associação. Não prova ALPN correto, autoridade HTTP admissível, identidade do cliente, permissão do usuário ou conclusão da transação.

Um proxy termina a conexão validada e inicia outra fronteira. O backend precisa de sua própria evidência. Compartilhar certificado final entre servidores não equivalentes também permite substituição. RFC 7672 recomenda evitar esse compartilhamento quando os destinos não são funcionalmente equivalentes.

A frase auditável é específica: “o SPKI apresentado correspondeu ao usage 3 secure desse nome nesse horário”. “O domínio autorizou a ação” excede a prova.

Rotação é uma janela de sobreposição

Uma mudança defensável publica a nova associação antes de depender dela, mantém material antigo e novo, observa resolvers e clientes, e só então retira o anterior após considerar TTL, assinaturas e endpoints.

Renovação com a mesma chave pode preservar SPKI; troca de chave não. Rotação de trust anchor difere da troca de certificado final. É preciso datar publicação autoritativa, visibilidade em cache, implantação, retirada e validade de RRSIG. Um resolver verde não prova convergência global.

Teste tentando sair do escopo

Apresente o mesmo certificado em duas portas e publique TLSA para uma. Troque transporte. Use CNAME, SRV e MX. Faça o material de usage 1 coincidir enquanto quebra PKIX. Renove com a mesma chave e depois com chave nova durante uma sobreposição.

Produza estados secure, insecure, bogus e indeterminate. Por fim, faça TLSA passar enquanto ALPN ou a autorização da aplicação falha. Um sistema correto mantém esses resultados separados.