¿Alguien informado puede dar una respuesta extensa sobre las diferencias y ventajas/desventajas de ambos enfoques?
No soy un experto en DNS, ni un programador. Tengo un conocimiento básico decente de DNS y suficiente conocimiento para entender cómo funcionan cosas como el error Kaminsky. Por lo que tengo entendido, DNSCurve tiene un cifrado más seguro, es mucho más sencillo de configurar y es una solución completamente mejor.
DNSSEC es innecesariamente complicado y utiliza cifrado rompible; sin embargo, proporciona seguridad de extremo a extremo, algo que DNSCurve no ofrece. Sin embargo, muchos de los artículos que he leído parecen indicar que la seguridad de extremo a extremo es de poca utilidad o no hace ninguna diferencia.
Entonces ¿cuál es la verdad? ¿Cuál es la mejor solución o cuáles son las desventajas/ventajas de cada una?
editar:
Agradecería que alguien pudiera explicar qué se gana al cifrar el contenido del mensaje, cuando el objetivo es la autenticación en lugar de la confidencialidad.
La prueba de que las claves son claves RSA de 1024 bits esaquí.
Respuesta1
DNSCurve proporciona cifrado real a los paquetes DNS, aunque sólo salto a salto, y específicamente en el salto entre el servidor recursivo y el servidor autoritativo.
Cuando se utiliza en esa ruta, puede proporcionar autenticación de los datos de la zona. Sin embargo, ningún cliente situado más abajo no puede beneficiarse de esta autenticación porque la seguridad es sólo "salto a salto". Un solucionador malicioso que se encuentre en medio de la ruta de resolución aún puede proporcionar datos falsos.
DNSSEC, por otro lado, proporciona una firma criptográfica verificable de extremo a extremo que demuestra que los datos recibidos son los mismos que los del servidor autorizado. DNSSEC utiliza técnicas criptográficas, pero en realidad no cifra ningún tráfico DNS.
El uso de algoritmos de cifrado de curva elíptica por parte de DNSCurve permite utilizar claves mucho más pequeñas que con RSA para lograr el mismo nivel de solidez criptográfica. Sin embargo, hay propuestas para incluir algoritmos similares en la lista supuesta de DNSSEC.
DNSSEC está estandarizado por el IETF (RFC 4034 y RFC 4035, actualizado por RFC 5155) y se implementa en varias implementaciones de servidores de nombres muy populares, incluidos BIND (por supuesto) y NSD/Unbound. PowerDNS tendrá soporte DNSSEC muy pronto.
Es cierto que DNSSEC es complicado, pero se están realizando esfuerzos para simplificarlo (ver, por ejemplo,http://opendnssec.org/) y el despliegue aumenta todo el tiempo. Varios TLD (.se, .br, .org, .gov, etc.) ya están firmados con DNSSEC y se ha anunciado que la zona raíz estará firmada con DNSSEC a finales de año.
DNSCurve es bastante interesante, pero debido a la forma independiente en la que se ha desarrollado, tiene muy pocas posibilidades de ver una implementación significativa. En mi humilde opinión tieneceroposibilidad de implementarse alguna vez en los servidores raíz.
Por cierto, su afirmación sobre DNSSEC que utiliza "cifrado rompible" parece completamente infundada. ¿Sobre qué base dices eso?
Las claves de firma de zona suelen tener (pero no necesariamente) 1024 bits de longitud. Estas claves normalmente se renuevan aproximadamente cada mes, y las mejores estimaciones actuales son que tomaría al menos un par de años parafuerza brutauna clave de 1024 bits.
En este momento, un ataque de fuerza bruta contra RSA de 1024 bits requeriría aproximadamente dos años en unos pocos millones de núcleos de computación con muchas decenas de gigabytes de memoria por procesador o placa base.
que no es exactamente la típica botnet. Del mismo periódico:
A continuación, considerando el hardware de propósito especial, el enfoque más optimista sugiere que el tamizado de un módulo RSA de 1024 bits se puede realizar en un año por aproximadamente 10.000.000 de dólares estadounidenses, más un costo único de desarrollo de aproximadamente 20.000.000 de dólares estadounidenses, y con un tiempo y costo comparables. para la matriz. En nuestra opinión, el escepticismo (común) que suscitan tales diseños no viene al caso. Estas cifras no deben interpretarse como límites superiores, es decir, "Tenga cuidado, el RSA de 1024 bits se puede romper en dos años por unos veinte millones de dólares (suponiendo un desarrollo libre)", sino como límites inferiores, es decir, "No hay razón para preocuparse". demasiado: incluso en condiciones de ataque muy favorables, factorizar un módulo RSA de 1024 bits todavía requiere enormes recursos”. Por lo tanto, las estimaciones no deben interpretarse como amenazadoras sino como inspiradoras de confianza.
O de un niño de un añoArtículo de PCPro:
Para poner esto en perspectiva, para descifrar una clave RSA de 1.024 bits, Kaspersky estima que se necesitarían unos 15 millones de computadoras funcionando a pleno rendimiento durante un año para tener éxito.
Francamente, ¡nadie va a poner tanto esfuerzo en descifrar el ZSK de un dominio!
Además, la verdadera seguridad está en las claves de firma de claves, que suelen tener al menos 2048 bits y, a menudo, más (4096 bits). La cantidad de tiempo que lleva descifrar una clave RSA aumenta exponencialmente con la longitud de la clave, no de forma lineal.
Respuesta2
Acomentar en LWNreclamos
DNSCurve protege el conducto, no el mensaje. No se puede utilizar para proteger contra cachés maliciosos y no es un equivalente funcional de DNSSEC.
y enlaces a undiscusión en francés.
Respuesta3
Es importante comprender que la "confianza" y no el "cifrado" es la clave de la seguridad. Puedes tener una conversación "segura" con alguien usando "cifrado", pero ¿de qué te sirve si la persona al otro lado de la línea no es quien crees que es?
La principal diferencia entre DNSSec y DNSCurve es que DNSSec firma todo, existe una cadena de confianza clara desde la raíz hasta los registros de host proporcionados por los servidores DNS de cada operador.
DNSCurve NO firma nada, no existe ninguna cadena de confianza. El enfoque de DNSCurve se limita a evitar el ajuste pasivo o ciego de las respuestas DNS.
Todo se reduce a lo práctico... Existen enormes desafíos operativos con DNSSec: ¿cómo se puede crear en la práctica un ancla de confianza del tamaño del planeta? Cuando se firman millones y millones de dominios, ¿qué mecanismos se utilizan para infundir confianza en que el material de clave necesario para falsificar cualquier firma no cae en las manos equivocadas o no se utiliza incorrectamente? La confianza a gran escala es muy difícil de lograr y mantener desde una perspectiva operativa.
DNSCurve ni siquiera lo intenta.
Ahora que he respondido la pregunta básica, aquí está mi opinión sobre cuál es realmente el problema a resolver y cuál de las dos tecnologías se adapta mejor.
Internet es inherentemente tanto un conducto de tonterías como de debates y esclarecimientos destacados. En mi opinión, una Internet totalmente digna de confianza no es un objetivo razonable ni alcanzable y, si así fuera, probablemente habría implicaciones negativas en términos de libertades y discursos y acciones anónimos.
En mi opinión, todo lo que se necesita es una solución DNS que esté alel menostan fiable como el transporte subyacente. Debe evitar prácticamente el envenenamiento de los registros DNS por parte de atacantes que inyectan ciegamente mensajes falsos o rastrean pasivamente solicitudes y falsifican respuestas UDP. NO necesita garantizar seguridad más allá de eso. De esta manera, Internet continúa enrutando paquetes y brindando servicios DNS de manera confiable pero no necesariamente segura.
En mi opinión, DNSSec y sus anclajes de confianza global son una tarea tonta que se centra casi por completo en resolver un problema que no existe. (Todos los sistemas de cifrado de extremo a extremo que se pueden utilizar a través de Internet ya tienen sus propios métodos para verificar la identidad)
DNSSec es lento, costoso y retrasará significativamente los problemas claros y presentes con DNS que, como el cambio a IPv6, deberían haberse resuelto ayer.
Lo que hace DNSCurve es proteger la red para que el servicio de nombres esté enel menosTan confiable como el transporte subyacente de paquetes a través de la red, pero no más. En mi opinión, resuelve exactamente el problema que realmente se enfrenta en el mundo real. DNSCurve previene MITM pasivo pero prácticamente no protege contra MITM activo sin el almacenamiento en caché de firmas de "acto de fe" estilo ssh.
Hacer el papel de los defensores del diablo el despliegue a gran escala de DNSSec puede tener implicaciones potencialmente positivas. La infraestructura PKI puede reemplazar las CA del servidor seguro SSL y proporcionar cierto vínculo de confianza para IPSec y otras conversaciones cifradas entre pares.
Respuesta4
Llegué a la conclusión de que DNSCurve es una mejor opción.
Porque:
DNSSEC utiliza claves RSA de 1024 bits para la firma, que ya en 2003 las grandes redes de bots consideraban irrompibles. El caso sigue siendo cierto hoy.
Para que se implemente correctamente, es necesario reescribir mucho código.
Los servidores raíz no firmarán la base de datos completa y no ofrecerán protección completa.
Es posible realizar ataques de repetición hasta 30 días después de que expire un dominio.
Para lograr la seguridad es necesario exponer todos los nombres de dominio.
DNSCurve no tiene estos problemas y permite la autenticación, disponibilidad y confidencialidad (como no tener que exponer nombres) de una manera que DNSSEC no tiene. Además, no requiere modificaciones de código, sólo software adicional.
También tiene protección contra paquetes falsificados, algo que DNSSEC no tiene, así como protección contra ataques de repetición, debido al uso de nonces. DNSCurve puede estar sujeto a un ataque MITM que DNSSec no, pero tengo entendido que si DNSCurve se implementara hasta la raíz, este no sería el caso.