Alguém informado pode dar uma resposta longa sobre as diferenças e vantagens/desvantagens de ambas as abordagens?
Não sou um especialista em DNS, nem um programador. Tenho um conhecimento básico decente de DNS e conhecimento suficiente para entender como funcionam coisas como o bug kaminsky. Pelo que entendi, o DNSCurve tem criptografia mais forte, é muito mais simples de configurar e é uma solução totalmente melhor.
O DNSSEC é desnecessariamente complicado e usa criptografia quebrável, mas fornece segurança de ponta a ponta, algo que o DNSCurve não oferece. No entanto, muitos dos artigos que li parecem indicar que a segurança ponta a ponta é de pouca utilidade ou não faz diferença.
Então, o que é verdade? Qual é a melhor solução ou quais são as desvantagens/vantagens de cada uma?
editar:
Eu apreciaria se alguém pudesse explicar o que se ganha criptografando o conteúdo da mensagem, quando o objetivo é a autenticação e não a confidencialidade.
A prova de que as chaves são chaves RSA de 1024 bits éaqui.
Responder1
DNSCurve fornece criptografia real para pacotes DNS, embora apenas salto a salto, e especificamente no salto entre o servidor recursivo e o servidor autoritativo.
Quando usado nesse caminho, pode fornecer autenticação dos dados da zona. No entanto, qualquer cliente mais a jusante não pode beneficiar desta autenticação porque a segurança é apenas "hop-by-hop". Um resolvedor malicioso localizado no meio do caminho de resolução ainda pode fornecer dados falsos.
O DNSSEC, por outro lado, fornece uma assinatura criptográfica verificável de ponta a ponta que prova que os dados recebidos são os mesmos do servidor oficial. O DNSSEC usa técnicas criptográficas, mas na verdade não criptografa nenhum tráfego DNS.
O uso de algoritmos de criptografia de curva elíptica pelo DNSCurve permite o uso de chaves muito menores do que com RSA para atingir o mesmo nível de força criptográfica. Contudo existem propostas para incluir algoritmos semelhantes na lista suposta pelo DNSSEC.
DNSSEC é padronizado pela IETF (RFC 4034 e RFC 4035, atualizado pela RFC 5155) e implementado em várias implementações de servidores de nomes muito populares, incluindo BIND (é claro) e NSD/Unbound. PowerDNS terá suporte DNSSEC muito em breve.
O DNSSEC é reconhecidamente complicado, mas estão em curso esforços para simplificá-lo (ver, por exemplo,http://opendnssec.org/) e a implantação está aumentando o tempo todo. Vários TLDs (.se, .br, .org, .gov, etc) já estão assinados com DNSSEC e foi anunciado que a zona raiz será assinada por DNSSEC até o final do ano.
O DNSCurve é bastante interessante, mas devido à forma independente como foi desenvolvido, tem muito poucas chances de ver qualquer implantação significativa. IMHO temzerochance de serem implantados nos servidores raiz.
A propósito, sua afirmação sobre DNSSEC usando "criptografia quebrável" parece ser completamente infundada. Com base em que você diz isso?
As chaves de assinatura de zona geralmente têm (mas não necessariamente) 1.024 bits. Essas chaves normalmente são lançadas a cada mês ou mais, e as melhores estimativas atuais são de que levaria pelo menos alguns anos paraforça brutauma chave de 1024 bits.
Neste momento, um ataque de força bruta contra RSA de 1024 bits exigiria cerca de dois anos em alguns milhões de núcleos de computação com muitas dezenas de gigabytes de memória por processador ou placa-mãe
que não é exatamente um botnet típico. Do mesmo artigo:
Em seguida, considerando o hardware para fins especiais, a abordagem mais otimista sugere que a peneiração para um módulo RSA de 1024 bits pode ser feita em um ano por cerca de US$ 10.000.000, mais um custo único de desenvolvimento de cerca de US$ 20.000.000, e com tempo e custo comparáveis. para a matriz. Em nossa opinião, o ceticismo (comum) enfrentado por tais projetos não vem ao caso. Esses números não devem ser interpretados como limites superiores, ou seja, “Tenha cuidado, o RSA de 1024 bits pode ser quebrado em dois anos por cerca de vinte milhões de dólares (assumindo o desenvolvimento livre)”, mas como limites inferiores, ou seja, “Não há razão para se preocupar”. demais: mesmo sob condições de ataque muito favoráveis, fatorar um módulo RSA de 1024 bits ainda requer enormes recursos.” As estimativas não devem, portanto, ser interpretadas como ameaçadoras, mas como inspiradoras de confiança.
Ou a partir de um ano de idadeArtigo PCPro:
Para colocar isso em perspectiva, para quebrar uma chave RSA de 1.024 bits, a Kaspersky estima que seriam necessários cerca de 15 milhões de computadores funcionando a todo vapor durante um ano para ter sucesso.
Francamente, ninguém vai se esforçar tanto para quebrar o ZSK de um domínio!
Além disso, a verdadeira segurança está nas chaves de assinatura, que geralmente têm pelo menos 2.048 bits e geralmente mais longas (4.096 bits). O tempo necessário para quebrar uma chave RSA aumenta exponencialmente com o comprimento da chave, e não linearmente.
Responder2
Acomente sobre LWNreivindicações
DNSCurve protege o canal, não a mensagem. Ele não pode ser usado para proteção contra caches maliciosos e não é um equivalente funcional do DNSSEC.
e links para umdiscussão em francês.
Responder3
É importante entender que “confiança” e não “criptografia” é a chave para a segurança. Você pode ter uma conversa "segura" com alguém usando "criptografia", mas de que adianta se a pessoa do outro lado não é quem você pensa que é?
A principal diferença entre DNSSec e DNSCurve é que o DNSSec assina tudo, há uma cadeia de confiança clara desde a raiz até os registros de host fornecidos pelos servidores DNS de cada operadora.
DNSCurve NÃO assina nada, não existe nenhuma cadeia de confiança. O foco do DNSCurve é restrito à prevenção do posicionamento passivo ou cego das respostas DNS.
Tudo se resume à praticidade... Existem enormes desafios operacionais com o DNSSec - como criar na prática uma âncora de confiança do tamanho do planeta? Quando milhões e milhões de domínios estão sendo assinados, que mecanismos são usados para inspirar confiança de que o material de codificação necessário para falsificar qualquer assinatura não caia em mãos erradas ou não seja usado indevidamente? A confiança em grande escala é muito difícil de ser obtida e mantida do ponto de vista operacional.
DNSCurve nem tenta.
Agora, tendo respondido à questão básica, aqui está minha opinião sobre qual é realmente o problema a ser resolvido e qual das duas tecnologias se adapta melhor.
A Internet é inerentemente tanto um canal de bobagens quanto de discussões e esclarecimentos importantes. Na minha opinião, uma Internet totalmente confiável não é um objetivo razoável ou alcançável e, se assim fosse, provavelmente haveria implicações negativas em termos de liberdades e discursos e ações anônimos.
Na minha opinião, tudo o que é necessário é uma solução DNS que esteja emao menostão confiável quanto o transporte subjacente. Ele precisa praticamente impedir o envenenamento de registros DNS por invasores que injetam cegamente mensagens falsas ou detectam passivamente solicitações e forjam respostas UDP. NÃO precisa garantir segurança acima e além disso. Dessa forma, a Internet continua a rotear pacotes e a fornecer serviços DNS de maneira confiável, mas não necessariamente segura.
O DNSSec e suas âncoras de confiança global, na minha opinião, é uma tarefa tola que se concentra quase inteiramente na resolução de um problema que não existe. (Todos os sistemas de criptografia de ponta que podem ser usados na Internet já possuem seus próprios métodos para verificar a identidade)
O DNSSec é lento, caro e atrasará significativamente os problemas claros e atuais do DNS que, como a mudança para o IPv6, deveriam ter sido resolvidos ontem.
O que o DNSCurve faz é proteger a rede para que o serviço de nomenclatura esteja emao menostão confiável quanto o transporte subjacente de pacotes pela rede, mas não mais. Na minha opinião, resolve exatamente o problema que realmente está sendo enfrentado no mundo real. DNSCurve evita MITM passivo, mas praticamente não protege contra MITM ativo sem cache de assinatura "salto de fé" no estilo ssh.
Fazer o papel de defensor do diabo, a implantação em larga escala do DNSSec pode ter implicações potencialmente positivas. A infraestrutura PKI pode substituir as CAs de servidor seguro SSL e fornecer alguma ligação confiável para IPSec e outras conversas criptografadas entre pares.
Responder4
Cheguei à conclusão de que DNSCurve é a melhor opção.
Porque:
DNSSEC usa chaves RSA de 1024 bits para assinatura, que já eram consideradas inquebráveis em 2003 por grandes redes, botnets. O caso ainda é verdade hoje.
Para ser implementado corretamente, muito código precisa ser reescrito.
Os servidores raiz não assinarão o banco de dados completo, não oferecendo proteção total.
São possíveis ataques de repetição até 30 dias após a expiração de um domínio.
Para obter segurança é necessário expor todos os nomes de domínio.
O DNSCurve não tem esses problemas e permite autenticação, disponibilidade e confidencialidade (como não ter que expor nomes) de uma forma que o DNSSEC não faz. Além disso, não requer modificações de código, apenas software adicional.
Também possui proteção contra pacotes forjados, o que o DNSSEC não possui, bem como proteção contra ataques de repetição, devido ao uso de nonces. O DNSCurve pode estar sujeito a um ataque MITM que o DNSSec não está, mas entendo que se o DNSCurve fosse implementado até a raiz, esse não seria o caso.