Question DNSCurve vs DNSSEC


Une personne informée peut-elle donner une longue réponse sur les différences et les avantages / inconvénients des deux approches?

Je ne suis pas un expert du DNS, pas un programmeur. J'ai une bonne compréhension de base du DNS et suffisamment de connaissances pour comprendre comment fonctionnent des problèmes comme le bogue kaminsky. D'après ce que j'ai compris, DNSCurve dispose d'un cryptage renforcé, d'une configuration beaucoup plus simple et d'une solution tout à fait supérieure.

DNSSEC est inutilement compliqué et utilise un cryptage cassable. Cependant, il fournit une sécurité de bout en bout, ce que DNSCurve ne fait pas. Cependant, beaucoup d'articles que j'ai lus semblent indiquer que la sécurité de bout en bout est de peu d'utilité ou ne fait aucune différence.

Alors qu'est-ce qui est vrai? Quelle est la meilleure solution ou quels sont les inconvénients / avantages de chacun?

modifier:

J'apprécierais que quelqu'un puisse expliquer ce que l'on gagne en cryptant le contenu du message, lorsque l'objectif est l'authentification plutôt que la confidentialité.

La preuve que les clés sont des clés RSA 1024 bits est ici.


6
2017-07-14 22:58


origine


Donc, vous ne pensez pas que les clés RSA 1024 bits seront cassables si la tâche est définie sur un réseau distribué? - Bill Gray
En voici quelques-uns, espérons-le, pour ne pas expliquer les diapositives biaisées.cr.yp.to/talks/2009.03.21/slides.pdf - Bill Gray
et une citation pertinente de Paul Vixie: 'dnscurve résout un problème que je n’ai pas et qui ne résout pas le problème qui m’arrive à me faire chier toutes les heures de la journée. techniquement, cela ressemble à du bon travail, mais cela reste un inadapté de 95% pour ce dont j'ai réellement besoin de la "sécurité du DNS". " lists.dns-oarc.net/pipermail/dns-operations/2009-July/… - Alnitak
Ouais ... les gens en désaccord ne sont pas la preuve de beaucoup. Je vais devoir considérer DNSCurve comme le gagnant pour le moment, car il présente plus d'avantages que d'inconvénients par rapport à DNSSEC, les inconvénients étant sans importance. - Bill Gray
@bill - ce réglage de 1024 bits dans les diapositives ISC est un Exemple. - Alnitak


Réponses:


DNSCurve fournit un cryptage réel aux paquets DNS, mais uniquement sur une base sauts, et spécifiquement sur le saut entre le serveur récursif et le serveur faisant autorité.

Lorsqu'il est utilisé sur ce chemin, il peut fournir une authentification des données de zone. Toutefois, aucun client situé plus en aval ne peut bénéficier de cette authentification car la sécurité n’est que «saut par saut». Un résolveur malveillant assis au milieu du chemin de résolution peut toujours fournir de fausses données.

DNSSEC, d’autre part, fournit une signature cryptographique vérifiable de bout en bout qui prouve que les données reçues sont les mêmes que celles du serveur faisant autorité. DNSSEC utilise des techniques cryptographiques, mais ne chiffre en réalité aucun trafic DNS.

L'utilisation par DNSCurve d'algorithmes de chiffrement à courbe elliptique permet d'utiliser des clés beaucoup plus petites qu'avec RSA pour atteindre le même niveau de cryptographie. Cependant, il est proposé d'inclure des algorithmes similaires dans la liste supposée par DNSSEC.

DNSSEC est normalisé par l'IETF (RFC 4034 et RFC 4035, mis à jour par RFC 5155) et implémenté dans plusieurs implémentations très répandues de serveurs de noms, y compris BIND (bien sûr) et NSD / Unbound. PowerDNS aura le support DNSSEC très bientôt.

Certes, DNSSEC est compliqué mais des efforts sont en cours pour simplifier cela (voir par exemple http://opendnssec.org/) et le déploiement augmente tout le temps. Plusieurs TLD (.se, .br, .org, .gov, etc.) sont déjà signés avec DNSSEC et il a été annoncé que la zone racine serait signée DNSSEC d'ici la fin de l'année.

DNSCurve est assez intéressant, mais en raison de la manière indépendante dont il a été développé, il a très peu de chance de voir un déploiement significatif. IMHO il a zéro chance d'être jamais déployé sur les serveurs racine.

BTW votre affirmation sur DNSSEC en utilisant "cryptage cassable" semble être complètement infondée. Sur quelle base dites-vous cela?

Les clés de signature de zone ont généralement (mais pas nécessairement) une longueur de 1024 bits. Ces clés sont généralement utilisées tous les mois environ, et les meilleures estimations actuelles indiquent qu'il faudrait au moins deux ans pour Force brute une clé de 1024 bits.

À ce stade, attaque par force brute contre RSA 1024 bits   nécessiterait environ deux ans sur quelques millions de cœurs de calcul avec plusieurs dizaines de gigaoctets   de mémoire par processeur ou carte mère

ce qui n'est pas exactement votre botnet typique. Du même papier:

Considérant ensuite le matériel spécialisé, l’approche la plus optimiste suggère que le tamisage   pour un module RSA 1024 bits peut être effectué en un an pour environ 10 000 000 USD, plus un traitement ponctuel.   coût de développement d’environ 20 000 000 USD, avec un temps et un coût comparables pour le   matrice. À notre avis, le scepticisme (commun) rencontré par de telles conceptions est hors de propos.   Ces chiffres ne doivent pas être interprétés comme des limites supérieures, c’est-à-dire «Soyez prudent, la RSA 1024 bits peut   être brisé en deux ans pour environ vingt millions de dollars (en supposant un développement libre) ", mais comme   Limites inférieures, c.-à-d. «Aucune raison de trop vous inquiéter: même dans des conditions d'attaque très favorables, la factorisation d'un module RSA à 1024 bits nécessite toujours des ressources énormes». Les estimations ne doivent donc pas être lues comme menaçantes, mais inspirent la confiance.

Ou à partir d'un an Article PCPro:

Pour mettre cela en perspective, Kaspersky estime qu'il faudrait environ 15 millions d'ordinateurs en panne pendant un an pour réussir.

Franchement, personne ne déploiera autant d'efforts pour démanteler le ZSK d'un domaine!

De plus, la clé de la sécurité réside dans les clés de signature, qui sont généralement au moins 2048 bits et souvent plus longues (4096 bits). Le temps nécessaire pour déchiffrer une clé RSA augmente de manière exponentielle avec la longueur de la clé, et non de manière linéaire.


14
2017-07-15 13:06



+1 DNSSEC est une vraie alternative, DNSCurve n'est pas ... - Antoine Benkemoun
Intéressant. Une chose est que nous n'avons pas besoin de respecter une exigence de confidentialité pour les paquets DNS, mais uniquement l'authentification. DNSCurve semble être la meilleure alternative, objectivement pour des raisons techniques. Les clés RSA utilisées par DNSSEC ne prendraient pas trop de temps à rompre avec un botnet - Bill Gray
@ Bill Grey: n'hésitez pas à essayer. Fournissez un pointeur sur un rapport décrivant une attaque par force brute réussie contre RSA, puis lisez la taille des clés impliquées. - bortzmeyer
@bortzmeyer: clés RSA 1024 bits. Botnets. Penses-y. - Bill Gray
en fait, la plupart des gens envisagent de faire pivoter les clés sans se soucier "au cas où". Et dès qu'ils le font, tout le processus de craquage doit recommencer à zéro. - Alnitak


UNE commenter LWN réclamations

DNSCurve sécurise le conduit, pas le message. Il ne peut pas être utilisé pour se protéger contre les caches malveillants et n’est pas un équivalent fonctionnel de DNSSEC.

et des liens vers un discussion en français.


4
2017-07-15 15:49



C’est pourquoi DNScurve n’est pas un concurrent de DNSsec, mais bien d’autres protocoles de sécurité de canaux comme IPsec, TSIG, les cookies DNS, etc. Si vous déployez DNScurve, vous devez toujours déployer DNSsec par la suite, pour obtenir une sécurité de bout en bout. - bortzmeyer


Il est important de comprendre que la "confiance" plutôt que le "cryptage" est la clé de la sécurité. Vous pouvez avoir une conversation "sécurisée" avec une personne utilisant le "cryptage", mais à quoi sert-il si la personne à l'autre bout du fil n'est pas ce que vous pensez être?

La principale différence entre DNSSec et DNSCurve réside dans le fait que DNSSec signe tout, il existe une chaîne de confiance claire allant de la racine aux enregistrements d'hôte fournis par les serveurs DNS de chaque opérateur.

DNSCurve ne signe rien car il n’existe aucune chaîne de confiance. DNSCurve se concentre sur la prévention de l’intimidation passive ou aveugle des réponses DNS.

Cela se résume à l'aspect pratique… DNSSec pose d'énormes problèmes opérationnels. Comment pouvez-vous pratiquement créer un point d'ancrage de confiance de la taille de la planète? Lorsque des millions et des millions de domaines sont en cours de signature, quels mécanismes sont utilisés pour instiller la confiance que le matériel de saisie nécessaire pour contrefaire une signature ne tombe pas entre de mauvaises mains ou n'est pas utilisé de manière incorrecte? La confiance à grande échelle est très difficile du point de vue opérationnel à maintenir et à maintenir.

DNSCurve n'essaye même pas.

Maintenant que j'ai répondu à la question de base, voici quelle est la nature du problème à résoudre et laquelle des deux technologies convient le mieux.

Internet est intrinsèquement autant une condition de non-sens que de discussion et d’illumination saillantes. À mon avis, un Internet pleinement digne de confiance n’est pas un objectif raisonnable ou réalisable; s’il devenait ainsi, il y aurait probablement des implications négatives en termes de libertés et de discours et d’actions anomiques.

À mon avis, tout ce qu’il faut, c’est une solution DNS à moins aussi fiable que le transport sous-jacent. Il doit empêcher pratiquement les attaques d’empoisonnement des enregistrements DNS par des attaquants qui injectent aveuglément de faux messages ou reniflent passivement des requêtes et forgent des réponses UDP. Il n'a PAS besoin de garantir la sécurité au-delà de cela. De cette manière, Internet continue de router les paquets et de fournir des services DNS de manière fiable mais pas nécessairement sécurisée.

À mon avis, DNSSec et ses points d'ancrage de confiance globaux sont une folie qui se concentre presque entièrement sur la résolution d'un problème qui n'existe pas. (Tous les systèmes de chiffrement d'extrémité pouvant être utilisés sur Internet disposent déjà de leurs propres méthodes de vérification de l'identité.)

DNSSec est lent, coûteux et retardera considérablement les problèmes clairs et actuels avec DNS qui, comme le passage à IPv6, auraient dû être résolus hier.

DNSCurve protège le réseau de manière à ce que le service de nommage soit disponible. moins aussi fiable que le transport sous-jacent de paquets sur le réseau, mais pas plus. À mon avis, cela résout le problème exact auquel le monde réel est confronté. DNSCurve empêche MITM passif, mais ne protège pratiquement pas contre MITM actif sans la mise en cache de signatures de style ssh.

Les démons préconisent que le déploiement à grande échelle de DNSSec puisse avoir des conséquences positives. L'infustructure PKI peut remplacer les autorités de certification du serveur sécurisé SSL et fournir une liaison de confiance pour IPSec et d'autres conversations chiffrées entre homologues.


1
2018-03-26 22:36





Honnêtement? Ni l'un ni l'autre n'est assez bon. DNSSEC s'effondre sous son propre poids: c'est trop compliqué, plein de trous et ne fonctionnera probablement jamais correctement. DNSCurve fait bien ce qu’il fait, mais ne va pas assez loin. Il est plus facile de patcher sur un serveur DNS, mais vu la manière dont il a été écrit et promu, son utilisation ne sera probablement jamais généralisée.

Je préférerais déployer DNSCurve plutôt que DNSSEC sur mon propre serveur DNS (récursif), mais uniquement parce que DNSCurve est plus explicite sur ce qu’il peut et ne peut pas faire, et ne fournit pas un faux sentiment de sécurité comme DNSSEC peut - beaucoup de les gens intelligents pensent que DNSSEC est assez bon, et c’est ne pas.

Mon impression est qu'il y a encore beaucoup à faire dans les guerres de la sécurité DNS, et nous verrons probablement une troisième option émerger. Espérons que cela sera construit sur DNSCurve, car je pense que DNSCurve est extrêmement bien conçu pour sécuriser le conduit de manière compatible avec les versions antérieures.


-1
2017-07-27 00:40



le conduit a déjà une protection (TSIG), bien que fournissant une vérification et non une confidentialité. - Alnitak
Autant que je sache, TSIG ne sécurise que les mises à jour DNS, pas les requêtes. - kquinn
Non, TSIG peut également être utilisé pour les requêtes, bien que ce ne soit pas une configuration courante. - Alnitak


Je suis arrivé à la conclusion que DNSCurve est une meilleure option.

Parce que:

DNSSEC utilise des clés RSA 1024 bits pour la signature, qui étaient déjà considérées comme incassables en 2003 par les grands réseaux de réseaux de zombies. Le cas est toujours vrai aujourd'hui.

Pour être correctement implémenté, beaucoup de code doit être réécrit.

Les serveurs racine ne signeront pas l'intégralité de la base de données, n'offrant pas une protection complète.

Des attaques de relecture jusqu'à 30 jours après l'expiration d'un domaine sont possibles.

Afin d'assurer la sécurité, il est nécessaire d'exposer tous les noms de domaine.

DNSCurve ne rencontre pas ces problèmes et permet l'authentification, la disponibilité et la confidentialité (par exemple, en évitant de révéler des noms) de la même manière que DNSSEC. De plus, il ne nécessite aucune modification de code, mais uniquement un logiciel supplémentaire.

Il dispose également d'une protection contre les paquets falsifiés, ce que ne fait pas DNSSEC, ainsi que d'une protection contre les attaques par rejeu, en raison de l'utilisation de nonces. DNSCurve peut être soumis à une attaque MITM, contrairement à DNSSec, mais si je comprends bien, si DNSCurve était implémenté à la racine, ce ne serait pas le cas.


-9
2017-07-26 16:51



J'ai ajouté un -1 aussi, car il y a beaucoup d'erreurs telles que "DNSSEC utilise des clés RSA 1024 bits" ou "beaucoup de code doit être réécrit" ou "Les serveurs racine ne signeront pas l'intégralité de la base de données" (la racine n'est pas signée, cette phrase signifie que vous connaissez mieux l'avenir de la signature racine que ses opérateurs), etc. - bortzmeyer
Voulez-vous sauvegarder vos déclarations? Les informations ci-dessus sont disponibles partout en ligne. DNSSEC utilise des clés RSA 124 bits, pourquoi contestez-vous cela? Ce n’est pas parce que vous n’êtes pas au courant que l’information est erronée. - Bill Gray
@bill - Votre propre analyse est complètement imparfaite. DNSSEC peut utiliser n'importe quelle longueur de clé. Aucun système ne peut signer la "base de données complète" car, par définition, il s'agit d'une base de données distribuée. DNSCurve fait ne pas "signer la base de données", il ne fait que chiffrer les paquets. - Alnitak