[LACNIC/Seguridad] [lacnog] Thomas Ptacek: Against DNSSEC

Mar Ene 26 03:31:10 BRST 2016

Hola,

Mi opinión contraria a DNSSEC data de fines de los 1990s, coincido 100% con
lo publicado por Thomas.

Debo aclarar que conozco a Thomas Ptacek desde mediados de los 1990s y que
trabajamos juntos, primero en Secure Networks Inc. (SNI), una empresa de
canadiense que desarrollaba software de seguridad informática, y
posteriormente en McAfee cuando adquirió a SNI. A mediados de los 2000,
Thomas que para esa época ya era un reconocido experto en la materia, fundó
Matasano, una consultora de seguridad informática que en cierta medida fue
competidora de la empresa en la que yo trabajé entre el 1996 y 2011. En el
interin, trabajó 4 años en Arbor Networks, empresa especializadas en
tecnología de mitigación de ataques de denegación de servicio y análisis de
tráfico de red.

Hago esta aclaración introductoria para afirmar que en mi opinión no hay
absolutamente ninguna posibilidad de que Ptacek "confunda" o "no entienda"
de lo que está hablando. Sé, por experiencia propia  que tiene experiencia
directa con DNS y DNSSEC y amplísima experiencia auditando y evaluando la
seguridad de infinidad de sistemas, particularmente de implementaciones de
cripto.

En lo que a mí respecta, tuve experiencia práctica auditando DNS,
encontrando problemas e interactuando con los fabricantes para implementar
soluciones. p.e., la identificación de la vulnerabilidad en el protocolo de
DNS que posibilita el primer ataque práctico de "polución de cache" por
parte de un atacante que no controle un servidor ni esté en el camino
topológico por el que viajan los paquetes de resolución de nombres de
dominios (off path):

 http://www.openbsd.org/advisories/res_random.txt

Traigo esto a colación no (solo) para indicar que tengo algo de
conocimiento del asunto sino principalmente para mencionar que ya en
aquella época los autores del paquete de software de DNS mas usado del
mundo tenían una posición tomada respecto a cómo solucionar *cualquier*
problema de DNS: Repetían ad infinitum "DNSSEC lo resuelve, arreglar o
parchar el protocolo de DNS no tiene sentido..." y de hecho rehusaron
implementar la propuesta de solución para DNS que les presentamos en aquel
momento, pero terminaron haciendolo (y peor) una década mas tarde.

En mi opinión, fue esa posición extrema, persistente y obcecada la que
trabajó en detrimento de la implementación de soluciones prácticas
puntuales para los problemas de seguridad que fueron descubriendose y los
métodos de ataque que fueron perfeccionandose durante la década siguiente y
que culminaron con el ataque super publicitado de Dan Kaminsky en 2008 que
dió paso a la campaña mas fuerte de despliegue de DNSSEC por parte de
varios fabricantes y del gobierno de EEUU.

Mi experiencia personal desde 1996 hasta hoy me convenció que el impulso al
despliegue de DNSSEC es mas un asunto político y de negocios que resultado
de una evaluación criteriosa de la mejor solución técnica posible para
solucionar los problemas conocidos de DNS.  Hasta donde yo conozco, toda
propuesta de alternativa a DNSSEC fue objeto de ataque sistemático y de
campaña en contra, en algunos casos con argumentos falaces, conductas poco
transparentes y hasta ataques personales. A fin de substanciar mis dichos
me tomé 5 minutos para encontrar alguna evidencia pública de lo indicado en
el párrafo anterior:

https://mailarchive.ietf.org/arch/msg/dnsext/kj9fNruEaZ708o9wkNHD6QwF_SE

Hay también una larga cronología anterior de "disputas" con DJB  quien
siempre cuestionó DNSSEC y propuso soluciones alternativas (pe. DNSCurve).

https://cr.yp.to/djbdns/namedroppers.html

Dicho todo esto, hago comentarios sobre las objeciones al post de Carlos
Marcelo Martinez Cagnazzo:

Efectivamente, DNSSEC *puede* user curvas elípticas pero en su
especificación original no podia hacerlo y no estaba siquiera contemplado.
El argumento de Thomas es que en cuanto a los aspectos criptográficos, el
diseño de DNSSEC es anticuado, obsoleto y poco recomendable. Mas allá de
que *pueda* usarse ECC, la realidad es que en la práctica su uso es
virtualmente inexistente, tal como se puede ver en la estadísticas de
despliegue del sitio secspider de Verisign (
http://secspider.verisignlabs.com/stats.html)

Es cierto, cifrar consultas nunca fue objetivo de diseño de DNSSEC, la
confidencialidad no esta contemplada por el protocolo. La disponibilidad
tampoco está contemplada, y si lo estuviera, el resultado sería bastante
malo porque DNSSEC facilita, mas que dificulta, los ataques contra las
disponibilidad. Queda solo la integridad como requerimiento estricto de
seguridad  que se dice atender. De hecho, Paul Vixie, uno de los creadores
de DNSSEC y su máximo impulsor, ya en 2008 indicaba que su intención era
solo de considerar soluciones que provean integridad end-to-end (cosa que
en la práctica DNSSEC no hace)

https://mailarchive.ietf.org/arch/msg/dnsext/MEck_zAUixH0g2Jhu_QOKdVANbI

Vemos ahí el origen de la crítica de Thomas Ptacek y de muchos otros.
DNSSEC no quiere resolver  problemas de seguridad que podría atacar y no
resuelve bien lo que dice querer resolver, p.e. qué pasa entre la
biblioteca de resolución y el resolver, como se comportan cuando falla la
validación?  De hecho, él cita explícitamente este post de John Gilmore que
habla del asunto:

http://marc.info/?l=namedroppers&m=99635022704707&w=2

En definitiva (como se puede apreciar en el mensaje del 2008 que cite más
arriba) la problemática que se busca atacar ya está contemplada actualmente
por soluciones en otras capas. La conclusión de Ptacek es que DNSSEC es
innecesario y además costoso de implementar, no vale la pena. En ningún
momento dice "como no resuelve todo entonces no sirve para nada", de hecho
en su primer punto dice claramente que hace mas difíciles cierto tipo de
ataques.

Lo que SI dice Ptacek es que DNSSEC es un esquema de PKI global controlado
por el gobierno. Cuando habla de "el gobierno" creo se refiere
específicamente al gobierno de EEUU, que en teoría tiene y ejerce autoridad
política sobre la zona raiz (root zone) pero que con el sistema de DNS no
tiene un mecanismo técnico que permita hacer enforcement de esa autoridad.
DNSSEC provee ese mecanismo, dado que impone una estructura jerárquica (de
la root zone, a los RIRs, a los TLD y a los nameservers de cada dominio)
 en la que se establece una cadena de confianza encadenada
criptográficamente y anclada en la raíz.

La explicación de como se establece esta cadena de confianza no esta en el
post de Ptacek pero se explica claramente, además de en los RFC
correspondientes, en este post de de la gente CloudFlare

https://www.cloudflare.com/dnssec/how-dnssec-works/

El argumento de Ptacek en este caso es no solo que el modelo PKI de los
noventa, incluso en su caso mas exitoso (SSL/TLS con certificados X.509),
ya a dado amplias muestras de su vulnerabilidad, sino que además en el caso
específico de DNSSEC va en contra de principios "filosóficos" de diseño de
la Internet (control descentralizado, el principio end-to-end) y de diseño
seguro.

No me queda claro en que punto es  que Thomas confunde gTLD y ccTLDs y
asume que la administración de los segundos esta en manos de un gobierno,
lo que entiendo es que se refiere a el control sobre la firma criptográfica
de las delegaciones y la posibilidad de que quien lo ejerce pueda
invalidarlas arbitrariamente.

Con respecto a las alternativas propuestas, Ptacek propone simplemente no
desplegar DNSSEC e indica que los problemas que intenta resolver ya son
atendidos por otros mecanismos en otras capas de la pila. Quien, en su
momento, si propuso una alternativa es Daniel J. Bernstein:
https://dnscurve.org/in-benefits.html

saludos,
-ivan

2016-01-15 15:42 GMT-03:00 Carlos Marcelo Martinez Cagnazzo <
carlosm3011 en gmail.com>:

> No me acuerdo si fue acá o en otras listas, pero ha generado mucha
> controversia y discusión este artículo.
>
> A mi juicio, el artículo contiene una cantidad de errores muy importantes
>  (DNSSEC *si* puede usar algoritmos de curvas elípticas, busquen en Google
> las presentaciones de Geoff Huston y de la gente de CloudFlare al respecto;
> cifrar las consultas nunca fue un objetivo de diseño de DNSSEC, para eso
> hay otros trabajos en el IETF), y algunos puntos en los que francamente
> parece que el autor nos estuviera tomando el pelo, como el de ‘como no
> me protege de todo, entonces no sirve para nada’.
>
> Pero lo mejor de todo y de colección para mi es… “*DNSSEC is a government
> controlled PKI*”, donde confunde gravemente los conceptos de gTLD, ccTLD
> y asume que la administración de los ccTLD está en todas partes y
> automáticamente, en manos de un gobierno,
>
> s2
>
> -Carlos
>
>
> via CloudMagic for Mac
> <https://cloudmagic.com/k/d/mailapp?ct=dx&cv=7.4.173&pv=10.11.1&source=email_footer_2>
>
> On Fri, Jan 15, 2016 at 3:09 PM, Fernando Gont <fgont en si6networks.com>
> wrote:
>
> Estimados,
>
> FYI: <http://sockpuppet.org/blog/2015/01/15/against-dnssec/>
>
> Estaria bueno escuchar la opinión de Uds. sobre el blog-post en
> cuestión. (De hacerlo, please citar/quotear el texto original, o
> discutir puntos especificos, para que sea una discusión con "substancia").
>
> Saludos cordiales,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont en si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20160126/f8954a74/attachment.html>