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

[Programa STIC]

Bue, pensé que no iba a escribir más sobre este asunto pero, nuevamente,
caí en la trampa...

Ese post de Vixie es del 2015 y hace referencia al ataque de poisoning
de Kaminsky del 2008 que "demostraba que el ataque es trivial"... en
realidad, como ya mencioné y como Paul Vixie sabe, eso se demostró en
1996-7.

De hecho, en realidad YA SE CONOCIA antes (1995) para los ataques on-path

https://www.cs.columbia.edu/~smb/papers/dnshack.pdf

y el mismo Vixie lo habia documentado:

https://www.usenix.org/legacy/publications/library/proceedings/security95/full_papers/vixie.pdf


El paper de Vixie dice que "query Id prediction" no se puede resolver y
2 años mas tarde se negó a implementar la solución que le propusimos
para randomizar el query ID (OpenBSD randomizaba tambien el source port
_en el kernel_ ). Una década mas tarde terminó implementado esa misma
solución y además randomizando el source port en user space, a un costo
mucho mayor y de manera totalmente intrusiva para el resto de las
aplicaciones y los firewalls del perímetro.

Es interesante la respuesta de Nick Weaver al mail que citás:

https://www.ietf.org/mail-archive/web/dnsop/current/msg13714.html

"Between actually adding in a bit more entropy in the request through
0x20 and port randomization, and more importantly cleaning up the glue
policy for recursive resolvers (which Unbound did), you close the door
on off-path attackers: both making races harder AND eliminating the
"race until win" property.

In fact, several have viewed the glue policy cleanup which gets to the
root cause of the Kaminski problem as detrimental specifically because
of the desire to force DNSSEC adoption."

La idea de que Vixie, y lo que otros denominaron públicamente el "DNSSEC
Cartel", quería impulsar a toda costa el despliegue de DNSSEC, parecería
que es compartida por varias expertos de protocolos de red y académicos,
además de por algunos practicantes de la seguridad informática.

En realidad, existía una solución aún mejor (yo creo que la de 0x20 era
una bandera falsa) que en los 90s fue descartada de manera sumaria y
casi sin discusión: Un mecanismo de challenge/response entre los
servidores implementado como un query adicional. En aquella época BIND
no soportaba multiples queries en un mismo request DNS y entonces la
solución no era viable porque requería re-despliegue de una nueva
version de DNS y presentaba problemas de interoperabilidad (claro, a
diferencia de DNSSEC....). La idea es 10 años previa a la propuesta de
0x20 y agregaba un nivel variable de entropía, en todos los casos mayor
al de randomizar el source port, que en el caso de BIND terminó siendo
de solo 11 bits como máximo.

Me vuela la cabeza que estas discusiones SIGAN existiendo e involucren a
los mismos interlocutores

https://www.ietf.org/mail-archive/web/dnsop/current/msg13673.html

saludos,

-ivan




El 25/1/16 a las 17:23, Fernando Gont escribió:
> FWIW, esto es aparentemente de Paul Vixie a una lista de IETF:
> 
>     "so we'll keep pushing the crap system we have, uphill all the way,
>      noone loving it, and almost everyone in fact hating it. we've now
>      spent more calendar- and person-years on DNSSEC than was spent on
>      the entire IPv4 protocol suite (including DNS itself) as of 1996
>      when the DNSSEC effort began. ugly, ugly, ugly."
> 
> Fuente: <https://www.ietf.org/mail-archive/web/dnsop/current/msg13711.html>
> 
> 
> (El participante con sentido exquisito del humor hubiera borrado
> "DNSSEC", y luego puesto un multiple choice de protocolos posibles).
> 
> 
> P.S.: En lo personal, soy esceptico a la conclusión de las discusiones
> sobre estos temas. Haciendo una analogia, lo malo no es que la gente
> coma hamburguesas, sino que se coman un BigMac y crean que se estan
> comiendo un asado...
> 
> Fernando
> 
> 
> 
> 
> On 01/25/2016 04:46 PM, Nicolas Antoniello wrote:
>> Hay veces que leemos artículos tan útiles como un limpiaparabrisas en un
>> submarino!
>>
>>
>> En primer lugar, el párrafo inicial del artículo:
>>
>> "All secure crypto on the Internet assumes that the DNS lookup from
>> names to IP addresses are insecure. Securing those DNS lookups therefore
>> enables no meaningful security. DNSSEC does make some attacks against
>> insecure sites harder. But it doesn’t make those attacks /infeasible/,
>> so sites still need to adopt secure transports like TLS. With TLS
>> properly configured, DNSSEC adds nothing."
>>
>> Sinceramente arrancar con un axioma y basar lo que sigue sobre el no
>> parece una estrategia honesta... que sentido tiene comparar un mecanismo
>> diseñado para asegurar la "confianza" en la traslación de un nombre a
>> una dirección, con uno diseñado para asegurar un canal en el sentido de
>> confidencialidad?
>>
>> Y luego, puede que muchas de las cosas que se digan den para discusión o
>> debate y seguramente dan para mejorar... pero el objetivo del artículo
>> parece ser lo que dice al final: "no soportes DNSSEC" y "soporta lo que
>> nosotros estamos proponiendo"... que dicho sea de paso, ni se menciona
>> en el artículo.
>> Decir que no andes en tal o cual auto porque es malo y que es mejor
>> andar en uno que es bueno (pero no mencionarlo) es por definición inútil
>> y no práctico.
>>
>> Saludos,
>> Nico
>>
>>
>>
>>
>> 2016-01-15 15:29 GMT-03:00 Fernando Gont <fgont en si6networks.com
>> <mailto:fgont en si6networks.com>>:
>>
>>     On 01/15/2016 03:09 PM, Fernando Gont 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").
>>
>>     Material adicional: <https://ianix.com/pub/dnssec-outages.html>
>>
>>     Saludos cordiales,
>>     --
>>     Fernando Gont
>>     SI6 Networks
>>     e-mail: fgont en si6networks.com <mailto:fgont en si6networks.com>
>>     PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>>     _______________________________________________
>>     LACNOG mailing list
>>     LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>     https://mail.lacnic.net/mailman/listinfo/lacnog
>>     Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
>>
>>
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
> 
> 


-- 
Programa de Seguridad en TIC
Fundación Dr. Manuel Sadosky
Av. Córdoba 744 Piso 5 Oficina I
TE/FAX: 4328-5164