Resumo

  • Um RRset TLSA só vira evidência DANE por meio do resultado DNSSEC: dados inseguros ou indeterminados são inutilizáveis, e dados bogus exigem falha.
  • Uso do certificado, seletor e tipo de correspondência determinam o que é comparado e quais regras de validação se aplicam.
  • Uma associação publicada com segurança ainda pode ser inutilizável ou não combinar com o certificado ou a chave realmente apresentada pelo servidor.
  • O controle precisa separar os estados publicado, seguro, utilizável, correspondente e aceito.

Imagine que um certificado de serviço seja renovado com sucesso à meia-noite. A nova cadeia está ativa em todos os servidores, mas alguns clientes ainda mantêm em cache uma associação TLSA da chave pública anterior. O DNS contém TLSA, o endpoint HTTPS parece saudável e o chamado é encerrado. Esses clientes abortam porque a associação autenticada deixou de combinar com a chave servida.

O cenário é hipotético. Ele mostra a distância entre publicar uma associação e reconciliar todos os elementos necessários para a aceitação.

Publicação é apenas o primeiro estado

A RFC 6698 forma TLSA com uso do certificado, seletor, tipo de correspondência e dados de associação. Os três parâmetros definem se a associação restringe uma cadeia de CA pública, fornece uma âncora de confiança ou identifica um certificado final emitido pelo domínio; se compara o certificado completo ou SubjectPublicKeyInfo; e se usa dados exatos, SHA-256 ou SHA-512.

O nome consultado também deriva da porta, do transporte e do domínio-base TLSA. Consultar outro serviço ou parar em um alias inseguro pode fornecer bytes DNS válidos para uma decisão errada. A RFC 7671 inclui a expansão CNAME segura na escolha do domínio-base. Um inventário que guarda só o RDATA perde a identidade do serviço a que a associação deveria se aplicar.

DNSSEC decide se a associação pode ser usada

A RFC 6698 torna o estado DNSSEC decisivo. Um RRset TLSA seguro deve ser usado, salvo se a política local proibir aquela associação. Uma resposta bogus impede ou interrompe TLS. Um RRset inseguro ou indeterminado não serve para autenticação TLSA.

“Publicado no DNS” é mais fraco que “validado como seguro”, e seguro ainda não significa utilizável. Uso, seletor ou tipo desconhecido torna a associação inutilizável, assim como dados malformados e um algoritmo fraco demais para a política do cliente.

Sem nenhuma associação utilizável, a aplicação processa TLS normalmente, sem entrada TLSA. Com uma ou mais, executa as comparações exigidas e precisa encontrar uma correspondência. Clientes com recursos ou políticas diferentes podem tratar o mesmo RRset de modo distinto sem negar que ele foi publicado.

O certificado servido ainda precisa satisfazer o registro

O uso muda o sentido da correspondência. Alguns usos preservam a validação PKIX; usos DANE podem estabelecer uma âncora respaldada por DNSSEC ou associar diretamente a entidade final. O seletor determina se uma renovação que mantém a chave continua combinando ou se cada byte do certificado importa.

A RFC 7671 acrescenta obrigações operacionais. DANE-TA requer material suficiente da cadeia e, em casos definidos, o certificado da âncora. DANE-EE com seletor SPKI pode sobreviver à renovação quando a chave não muda, mas falha se outra chave for apresentada. A agilidade de resumo só entra depois de remover associações malformadas ou não suportadas.

Saúde do servidor não é saúde DANE. Um cliente PKIX convencional pode concluir TLS enquanto um cliente DANE deve rejeitar. Uma aplicação oportunista pode seguir com TLS não autenticado quando não há associação segura utilizável; uma política obrigatória não pode se conectar. Aceitação é decisão do protocolo e do cliente.

O tempo também separa publicação e aceitação

TTL do TLSA, validade da RRSIG, idade do cache e ordem da implantação limitam a observação. A RFC 7671 alerta que associações antigas em cache podem falhar após mudança inesperada no certificado ou na cadeia. Uma assinatura longa também estende o período de reprodução de dados DNS antigos ainda válidos.

A renovação deve coordenar associações antigas e novas, publicação autoritativa, secundários, caches de validadores, implantação e reversão. Ver o novo registro em um servidor autoritativo não prova qual vínculo os clientes reais enxergam.