<div dir="ltr">Hola,<div><br></div><div>Mi opinión contraria a DNSSEC data de fines de los 1990s, coincido 100% con lo publicado por Thomas. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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):</div><div> </div><div> <a href="http://www.openbsd.org/advisories/res_random.txt" target="_blank">http://www.openbsd.org/advisories/res_random.txt</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div><a href="https://mailarchive.ietf.org/arch/msg/dnsext/kj9fNruEaZ708o9wkNHD6QwF_SE">https://mailarchive.ietf.org/arch/msg/dnsext/kj9fNruEaZ708o9wkNHD6QwF_SE</a><br></div><div><br></div><div>Hay también una larga cronología anterior de "disputas" con DJB  quien siempre cuestionó DNSSEC y propuso soluciones alternativas (pe. DNSCurve).<br></div><div><br></div><div><a href="https://cr.yp.to/djbdns/namedroppers.html">https://cr.yp.to/djbdns/namedroppers.html</a><br></div><div><br></div><div>Dicho todo esto, hago comentarios sobre las objeciones al post de Carlos Marcelo Martinez Cagnazzo:</div><div><br></div><div>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 (<a href="http://secspider.verisignlabs.com/stats.html" target="_blank">http://secspider.verisignlabs.com/stats.html</a>)</div><div><br></div><div>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)</div><div><br></div><div><a href="https://mailarchive.ietf.org/arch/msg/dnsext/MEck_zAUixH0g2Jhu_QOKdVANbI">https://mailarchive.ietf.org/arch/msg/dnsext/MEck_zAUixH0g2Jhu_QOKdVANbI</a><br></div><div><br></div><div>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:</div><div><br></div><div><a href="http://marc.info/?l=namedroppers&m=99635022704707&w=2">http://marc.info/?l=namedroppers&m=99635022704707&w=2</a><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div><a href="https://www.cloudflare.com/dnssec/how-dnssec-works/">https://www.cloudflare.com/dnssec/how-dnssec-works/</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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. </div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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:  <a href="https://dnscurve.org/in-benefits.html">https://dnscurve.org/in-benefits.html</a></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">saludos,</div><div class="gmail_extra">-ivan</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-15 15:42 GMT-03:00 Carlos Marcelo Martinez Cagnazzo <span dir="ltr"><<a href="mailto:carlosm3011@gmail.com" target="_blank">carlosm3011@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><span>No me acuerdo si fue acá o en otras listas, pero ha generado mucha controversia y discusión este artículo.</span><div><span><br></span></div><div><span>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</span>’.<div><span><br></span></div><div>Pero lo mejor de todo y de colección para mi es… “<i>DNSSEC is a government controlled PKI</i>”, 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,</div><div><br></div><div>s2</div><div><br></div><div>-Carlos</div><div><br><br><div><div>via <a href="https://cloudmagic.com/k/d/mailapp?ct=dx&cv=7.4.173&pv=10.11.1&source=email_footer_2" target="_blank">CloudMagic for Mac</a></div></div><br><div><div><span>On Fri, Jan 15, 2016 at 3:09 PM, Fernando Gont <<a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a>> wrote:<br></span><div style="overflow:visible"><blockquote style="margin:0px;border-left-color:rgb(214,214,214);border-left-width:1px;border-left-style:solid;padding-left:10px"><span>Estimados,<br><br>FYI: <<a href="http://sockpuppet.org/blog/2015/01/15/against-dnssec/" target="_blank">http://sockpuppet.org/blog/2015/01/15/against-dnssec/</a>><br><br>Estaria bueno escuchar la opinión de Uds. sobre el blog-post en<br>cuestión. (De hacerlo, please citar/quotear el texto original, o<br>discutir puntos especificos, para que sea una discusión con "substancia").<br><br>Saludos cordiales,<br>-- <br>Fernando Gont<br>SI6 Networks<br>e-mail: <a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a><br>PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492<br><br><br><br><br>_______________________________________________<br></span>LACNOG mailing list<br><a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br><a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br></blockquote></div></div></div></div></div></div><br>_______________________________________________<br>
Seguridad mailing list<br>
<a href="mailto:Seguridad@lacnic.net" target="_blank">Seguridad@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/seguridad" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/seguridad</a><br>
<br></blockquote></div><br></div></div>