O DNSSEC é um assunto complicado e a disponibilidade de vários algoritmos de segurança padrão para assinatura de registros de DNS definidos pela IANA torna as coisas ainda mais confusas. O Algoritmo 13 é uma variante do Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA). Embora atualmente utilizado por menos de 0,01% dos domínios, gostaríamos de argumentar que o ECDSA nos ajudou a eliminar as duas últimas barreiras para a adoção generalizada do DNSSEC: enumeração de zonas e ampliação de DDoS.
Após ler este artigo, você será capaz de:
Copiar o link do artigo
O DNSSEC é um assunto complicado e a disponibilidade de vários algoritmos de segurança padrão para assinatura de registros de DNS definidos pela IANA torna as coisas ainda mais confusas. O Algoritmo 13 é uma variante do Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA). Embora atualmente utilizado por menos de 0,01% dos domínios, gostaríamos de argumentar que o ECDSA nos ajudou a eliminar as duas últimas barreiras para a adoção generalizada do DNSSEC: enumeração de zonas e ampliação de DDoS.
A enumeração de zona é evitada pela assinatura ao vivo e isso só é computacionalmente eficiente com a geração rápida de assinatura do ECDSA. As curvas elípticas também produzem chaves e assinaturas significativamente menores do que suas contrapartes RSA, o que significa que as respostas às consultas DNS são menores. Isso reduz bastante o fator de amplificação de ataques DDoS baseados em DNS.
O DNSSEC introduz a negação de existência autenticada por meio de registros NSEC e NSEC3. No entanto, conforme discutimos em Complexidades e considerações sobre o DNSSEC, tanto o NSEC quanto o NSEC3 permitem que os invasores percorram a zona. A solução é uma técnica inteligente chamada “DNSSEC white lies” (descrita nas RFCs 4470 e 4471), mas só pode ser implementada se os registros de DNSSEC forem assinados dinamicamente.
O RSA é o algoritmo de assinatura mais difundido do DNSSEC, em parte porque é o único algoritmo necessário definido pelo protocolo. Infelizmente, a assinatura ao vivo com o RSA é proibitivamente cara.
Os ganhos de desempenho do ECDSA são consideráveis. É computacionalmente dez vezes menos caro gerar uma assinatura ECDSA do que uma assinatura RSA comparável. Isto torna a assinatura (e as DNSSEC white lies) ao vivo viável, mesmo em escala.
Durante nosso DNSSEC beta (com menos de mil domínios assinados), a Cloudflare tem respondido dezenas de milhares de consultas de DNSSEC por segundo. Isso resulta em mais de 1 bilhão de consultas por dia, e assinamos todos os registros RRSIG necessários dinamicamente. Ter um algoritmo de assinatura dez vezes mais rápido que o RSA faz uma grande diferença quando se trata de carregar em nossos servidores DNSSEC.
Quando começamos a trabalhar com o ECDSA, a implementação OpenSSL que usávamos era em Go. Considerando todas as assinaturas que estamos fazendo, otimizar a geração de assinaturas era uma prioridade séria. Então, reescrevemos a implementação do ECDSA em montagem de baixo nível e agora está mais de vinte vezes mais rápido do que em Go. Esse é um código aberto e chegará ao Go 1.7 para que toda a comunidade de criptografia possa aproveitar nossas otimizações. Saiba mais
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 doze vezes apenas das chaves. Você pode ler mais sobre por que as chaves criptográficas têm tamanhos diferentes nesse post do blog.
Mas, a maioria das chaves RSA não são de 3072 bits, então um fator de amplificação de doze vezes 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 DNSSEC white lies), uma resposta DNSSEC típica é de 377 bytes. Compare isso com 1075 bytes para um domínio que não usa ECDSA ou DNSSEC white lies.
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 resolve grandes problemas no DNSSEC, mas é pouco aproveitado pela comunidade global do DNSSEC. Demos uma breve olhada na adoção do ECDSA na zona raiz de DNS e no top um milhão da Alexa.
Primeiro, examinamos a zona raiz de DNS para ver quais algoritmos DNSSEC os domínios de nível superior estão usando. A tabela a seguir mostra os algoritmos de segurança especificados pelos registros DS no arquivo da zona raiz:
curl -s http://www.internic.net/domain/root.zone | awk '$4 == "DS" { print $6}' | sort -n | uniq -c
Realizamos uma análise semelhante para o top um milhão da Alexa, o que nos dá uma boa seção transversal do tráfego global da internet:
| Algoritmo | Número de registros DS assinados |
|---|---|
| 1 (RSA/MD5) | 1 |
| 3 (DSA/SHA1) | 10 |
| 5 (RSA/SHA-1) | 3322 |
| 7 (RSASHA1-NSEC3-SHA1) | 5083 |
| 8 (RSA/SHA-256) | 7003 |
| 10 (RSA/SHA-512) | 201 |
| 13 (Curva ECDSA P-256 com SHA-256) | 23 |
A revelação mais impressionante é que apenas 15.643 dos 1 milhão de sites são habilitados para DNSSEC em qualquer capacidade. Desses 1,5%, apenas 23 zonas, são assinadas com o Algoritmo 13. E mais da metade dessas zonas de Algoritmo 13 estão por trás da rede da Cloudflare. Isso significa que há menos de uma dúzia de zonas no top um milhão da Alexa usando ECDSA fora da Cloudflare. Isso apoia as descobertas de Roland van Rijswijk-Deij et al de que 99,99% dos domínios assinados em .com, .net e .org usam RSA.
Então, por que o uso do Algoritmo 13 é tão baixo, já que ele resolve problemas tão importantes no DNSSEC? Bem, o RSA foi introduzido com o DNSSEC desde o início do protocolo. O ECDSA é um novo algoritmo criptográfico e os resolvedores, registradores e registros ainda estão se atualizando.
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 possivelmente desacelerar toda a internet.
Há uma ressalva muito importante em toda essa discussão do Algoritmo 13: apenas 1,5% dos ativos 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 façam upload de 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 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 doze 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 Universal DNSSEC, 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.