ECDSA: A peça que faltava do DNSSEC

A Cloudflare é o maior provedor de DNS gerenciado no mundo . O que realmente não queremos é transformar nossos servidores DNSSEC em um vetor de amplificação para ataques de negação de serviço distribuída (DDoS). Toda vez que você solicita um registro de um servidor DNSSEC, ele também retorna a assinatura associada a esse registro, bem como a chave pública usada para verificar essa assinatura. Isso é possivelmente muita informação.

Tornar o tamanho da resposta para consultas DNSSEC o menor possível é um requisito importante para evitar o abuso de nossa infraestrutura de DNS por possíveis invasores. O pequeno tamanho das chaves e assinaturas de ECDSA ajuda bastante nesse sentido.

Alcançar a segurança de 128 bits com o ECDSA requer uma chave de 256 bits, enquanto uma chave RSA comparável seria de 3072 bits. Isso é um fator de amplificação de 12x apenas das chaves. Você pode ler mais sobre por que as chaves de criptografia têm tamanhos diferentes neste post do blog.

Mas, a maioria das chaves RSA não são de 3072 bits, então um fator de amplificação de 12x pode não ser o valor mais realista. Vamos dar uma olhada no pior cenário do mundo real para amplificação de DDoS, que é uma resposta negativa (registro NSEC). Para um domínio por trás da Cloudflare (que usa assinaturas de ECDSA e mentiras brancas de DNSSEC), uma resposta DNSSEC típica é de 377 bytes. Compare isso com 1075 bytes para um domínio que não usa ECDSA ou mentiras brancas de DNSSEC.

Quando você considera o fato de que todas as outras implementações de DNSSEC, em larga escala, dependem de assinaturas RSA, não é atraente para um invasor aproveitar nossa infraestrutura de DNSSEC como um vetor de DDoS.

O ECDSA não está isento de compensações. De acordo com Roland van Rijswijk-Deij et al, apenas 80% dos resolvedores são compatíveis com a validação do ECDSA. Esse número está crescendo, mas significa que, se mudarmos toda a internet DNSSEC para o ECDSA agora, a validação do DNSSEC falharia para milhões de usuários da internet todos os dias e voltaria a retornar registros de DNS não verificados.

Além disso, enquanto a criação de assinatura do ECDSA é mais rápida que a do RSA, a validação de assinatura é realmente muito mais lenta. Roland van Rijswijk-Deij et al. mostrou que, mesmo com as otimizações do ECDSA que contribuímos para o OpenSSL, o ECDSA ainda é 6,6 vezes mais lento que o RSA de 1024 bits (que é o algoritmo mais comum usado para chaves de assinatura de zona). Este é um problema sério, porque a sobrecarga de resolvedores de DNS pode potencialmente desacelerar toda a internet.

Há uma ressalva muito importante em toda essa discussão do Algoritmo 13: apenas 1,5% das propriedades da web são compatíveis com DNSSEC em qualquer capacidade. Nem todos os registradores são compatíveis com DNSSEC e adicionar compatibilidade não é algo simples. Eles precisam permitir que seus usuários carreguem registros DS, que, por sua vez, precisam ser carregados no registro pelo registrador. Estamos trabalhando para tornar esse processo automatizado para que o registrante nem precise fazer o upload do registro DS, mas isto ainda exige a intervenção do registrador.

A boa notícia é que estamos na direção certa. Nos últimos 12 meses, o DNSSEC em geral teve um bom crescimento. E, nas três semanas entre o nosso DNSSEC beta público e nosso anúncio do DNSSEC Universal, Hover, OVH, Metaname, Internet.bs e o registro .NZ adicionaram compatibilidade com o Algoritmo 13.

Acreditamos que o DNSSEC é uma tecnologia essencial para a web moderna e que o ECDSA torna a adoção global do DNSSEC uma possibilidade real. Esperamos continuar vendo a compatibilidade com o Algoritmo 13 de registradores e registros, grandes e pequenos.