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

[Espinoza Sanchez, Luis Diego]

Mis ¢2
1 - Creo que la seguridad basada en defensa por capas, no ha pasado de moda, así como las organizaciones tienen un firewall, también aseguran los servidores en si mismos y las aplicaciones, así como todo lo relacionado con el acceso lógico y físico, aunque exista firewall.  En este caso, DNSSEC lo pueden ver como una capa mas de seguridad. En Costa Rica lo implementamos con el banco mas importante y ahora es parte de sus protocolos de seguridad, que por cierto algunas cosas son mas complejas que DNSSEC en un esquema de seguridad de una pagina transnacional de un banco.

2 - Complejidad: Si, al arranque, una vez automatizado con el resto de los procesos de gestion de un ccTLD se vuelve rutinario y un elemento mas a auditar.

saludos,

> On Jan 26, 2016, at 3:20 PM, Iván Arce <ivan.w.arce en gmail.com> wrote:
> 
> Hola
> 
> 2016-01-26 10:06 GMT-03:00 Nicolas Antoniello <nantoniello en gmail.com <mailto:nantoniello en gmail.com>>:
> Hola Ivan,
> 
> Entiendo tus argumentos y comparto gran parte de ellos. De todas formas creo que no hay cosas "inevitables" en esto al punto de entregarnos a que son así y chau... Las mismas personas (por lo que contas) cambian de lado y de punto de vista varias veces a medida que van repensando las cosas (y supongo que los intereses también).
> 
> Bueno, en eso disiento. Yo si creo que hay cosas que una vez que adquieren masa crítica se tornan inevitables. por ejemplo, en mi opinión, IPv6 es una de ellas. PAa bien o para mal, DNSSEC -20 años después de su creación- está cerca de ese punto. Yo lo considero un caso de estudio emblemático del mal funcionamiento de los mecanismos de gobernanza técnica de la Internet.
> 
> 
> Supongo que hay espacio para mejorar DNSSEC, TLS o lo que sea y debemos seguir insistiendo para ello.
> Por eso me resisto a descartar las cosas solo porque alguien ya lo discutió 100 veces antes o porque alguien dice que no sirve (luego que si y luego que no...).
> 
> No es mas positivo tomar de lo que hay hoy, lo rescatable y lo que realmente sirve y tratar de combinarlo o complementarlo con otras ideas y mejorarlo?
> 
> No sé si es mas  positivo, con que combinarías o complementarias DNSSEC para que sea mejor?
> 
> 
> Planteo otra pregunta: seguro que nada de lo que compone DNSSEC no sirve? Tal vez hay cosas muy rescatables como el modelo de gestión de la firma de la raiz (que si, puede entrar en lo que sería una especie de entidad certificadora pero bastante descentralizada, al menos más que muchas otras).
> 
> 
> A que te referís específicamente?
> 
> 
> El algoritmo de seguridad (sea curvas o cual sea) seguramente se puede modificar una o 10 veces... Mañana, cuando ese tampoco sea lo suficientemente fuerte habrá que volver a cambiarlo y estaremos discutiéndolo nuevamente (eso si es medio inevitable).
> 
> Creo que la innovación y el avance se basa justamente en eso, avanzar sobre los aciertos pero también sobre los errores, y no sobre descartar apresuradamente opciones en pro de la que creemos hoy que es mejor. Si no, retrocedemos en lugar de avanzar.
> 
> No?
> 
> 
> No sé, esa es una pregunta abierta y general, diría que sobre filosofía de la tecnología. Creo que diverge del tema de discusión del thread. En mi opinión, innovación y avance no son sinónimos.
> 
> Según la RAE innovar es simplemente "crear o alterar algo, introduciendo novedades" . Partiendo de esa definición, la innovación no es intrínsecamente buena ni mala ni implica necesariamente un avance.
> 
> Por otro lado, hay cosas que llegado un punto son obsoletas o demostrablemente erradas o subóptimas a nivel de diseño o arquitectura y puede no existir ventaja ni avance alguno en intentar hacerle "mejoras incrementales", por ejemplo se  me ocurre que el stack TCP/IP no fue concebido como  una "mejora incremental" a SNA.
> 
> 
> saludos,
> -ivan
> 
> 
> _______________________________________________
> 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/d10c7ca5/attachment.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20160126/d10c7ca5/attachment.sig>