Resumo

  • Uma cadeia TLSA válida e compatível com o certificado pode estabelecer ExtSupportLifetime para um nome SNI e uma porta. O TTL limita a evidência atual; o pin mantém a obrigação de fornecer evidência atualizada.
  • Negação autenticada do TLSA, prova de delegação insegura ou uma transição DANE validada com duração zero podem apagar o pin. Ausência da extensão, quando ela ainda é exigida, não prova inexistência e pode obrigar o cliente a abortar.

A dependência circular do primeiro contato

Para autenticar um resolvedor DNS-over-TLS com DANE, o cliente precisa consultar o TLSA daquele serviço e validar sua cadeia DNSSEC. Só que o canal natural para fazer essa consulta é o próprio resolvedor que ainda está sendo autenticado. O dnssec_chain experimental do RFC 9102 resolve o transporte dessa evidência: o servidor inclui no handshake TLS o conjunto de registros e assinaturas necessário para chegar a um trust anchor DNSSEC configurado no cliente.

O servidor também envia ExtSupportLifetime, um inteiro de 16 bits em horas. A cadeia descreve a situação presente; a duração descreve por quanto tempo o servidor, ou o cluster sob o mesmo nome, compromete-se a continuar oferecendo a extensão. Colocar os dois no mesmo pacote não transforma suas validades em uma só.

Shumon Huque assina o RFC 9102 com Viktor Dukhovni, Willem Toorop, Paul Wouters e Melinda Shore; o texto atribui a ideia original a Adam Langley. O perfil da IETF e a biografia pública de Huque registram atuação em infraestrutura DNS, redes e protocolos de segurança, hoje na Salesforce e anteriormente na Verisign e na Universidade da Pensilvânia. É uma atribuição de contribuição, não de propriedade individual sobre DANE, DNSSEC, TLS ou o experimento.

O pin precisa de uma origem forte

O cliente só pode usar uma duração diferente de zero depois de validar a cadeia TLSA, confirmar que ela corresponde à certificate chain apresentada e concluir a autenticação DANE. Ver um campo, aceitar o certificado por PKIX ou receber RRs sem verificar assinaturas não cria o compromisso. Esse requisito impede que uma mensagem falsa imponha estado persistente ao cliente.

O escopo é o par nome-porta. A porta vem na solicitação e o nome é o SNI enviado pelo cliente. Para construir a cadeia embutida, o servidor não expande o CNAME desse SNI. Logo, o pin não se aplica automaticamente a todos os serviços de um IP, a outras portas ou aos demais clientes de uma hospedagem compartilhada.

O cliente pode reduzir o prazo anunciado a um limite local. O RFC cita o risco teórico de um servidor comprometido publicar o máximo de sete anos. Um teto evita dependência excessiva, mas um teto curto demais também reduz o período em que omissões serão detectadas. O compromisso efetivo nasce da proposta do servidor sob a política do cliente.

Frescor e disponibilidade usam relógios diferentes

Um TLSA já validado pode permanecer no cache até o TTL recebido. Enquanto estiver fresco, o cliente pode reutilizá-lo e não solicitar a extensão em toda conexão. Depois do TTL, os mesmos bytes não servem como prova atual, ainda que faltem meses para o pin expirar. Nesse momento, uma nova cadeia precisa chegar pela extensão ou por outro meio DNSSEC válido.

TTL e validade do RRSIG governam o relógio curto do conteúdo. ExtSupportLifetime governa o relógio longo do canal. O RFC declara que o segundo não é limitado pelos prazos do primeiro. Isso não estende uma assinatura: obriga o servidor a reconstruir e renovar a cadeia durante o período de suporte.

Sessões retomadas exigem leitura própria. Nelas não há dnssec_chain; em TLS 1.3 também não há o novo envio da mensagem Certificate que carregaria a extensão. Uma métrica que interpreta toda falta como downgrade gera falso positivo. O recibo precisa dizer se o handshake foi completo ou retomado, qual TLSA ainda estava no cache e quais eram os dois vencimentos.

Uma resposta negativa ainda é uma resposta

Se o TLSA for removido, o servidor pode entregar a cadeia NSEC ou NSEC3 que autentica sua inexistência para o nome e a porta pedidos. Uma negação validada apaga o pin. Uma prova de delegação insegura também pode apagá-lo. A política local decide então se PKIX basta ou se a conexão termina.

Silêncio não tem esse poder. Com o pin vigente e sem TLSA fresco, o cliente deve exigir uma extensão contendo TLSA válido ou prova de inexistência válida. Se ela não vier, o cliente precisa interromper ou adiar a comunicação até conseguir evidência fora de banda. Sem sucesso, aborta o TLS. Do contrário, um servidor adversário com certificado aceito por PKIX poderia esconder a camada DANE e provocar downgrade.

Por isso, exigir a extensão não significa exigir TLSA, DANE ou DNSSEC eternamente. O operador da zona pode retirar TLSA ou DS. Durante o pin, permanece apenas a obrigação de revelar o novo estado de forma autenticada. Uma afirmação positiva pode virar negação; não pode virar ausência sem explicação.

Para desligar, primeiro é preciso dizer zero

A desativação começa com ExtSupportLifetime zero em um handshake autenticado por DANE. Depois, o serviço espera todos os prazos não nulos emitidos anteriormente chegarem ao fim. Só então a extensão pode desaparecer. TLSA e DNSSEC podem ser removidos antes, desde que a negação correspondente continue disponível para clientes com pins antigos.

Em hospedagem, a linha do tempo atravessa contratos. O dono do domínio administra DNS e quer liberdade para migrar; o provedor pode controlar certificados, endpoints TLS e a construção da cadeia. O RFC recomenda duração não nula apenas por acordo mútuo. Todos os nós do cluster precisam conhecer e honrar o maior compromisso ainda possível.

A cadeia entregue pelo servidor também não escolhe a própria raiz de confiança. O cliente parte de um trust anchor DNSSEC previamente configurado, acompanha rollover e mantém horário suficientemente correto para verificar RRSIG. O transporte se torna interno ao handshake; a autoridade final continua externa.

O RFC 9102 é Experimental porque o pin levantou dúvidas de implantabilidade no grupo TLS. O documento pretende estudar essas complicações em uso real. As fontes públicas aqui examinadas não medem adoção atual. Elas permitem, porém, uma conclusão precisa: prova positiva, negação autenticada e falta de resposta pertencem a caminhos de decisão diferentes.

Fontes