[LAC-TF] Revisión de IETF I-D: draft-ietf-6man-stable-privacy-addresses-00.txt

[Arturo Servin]

	El punto es que creemos en dos formas de hacer las cosas. Podemos estar en un loop infinito tratando de convencer al otro de porque sus argumentos son correctos o no.

	Hay puntos en los cuales creo que tienes razón, otros en los que creo que no y por más que haga yo (y tu de tu lado) no nos vamos a convencer.

Saludos,
as

On 21 May 2012, at 14:44, Fernando Gont wrote:

> On 05/21/2012 09:07 AM, Arturo Servin wrote:
>> En pocas palabras no creo que después de hacer una análisis de riesgo
>> sea conveniente cambiar un estándar sin probar la alternativa (en ese
>> caso en específico).
> 
> Si tomas esa postura, entonces directamente deberias deshabilitar IPv6
> en todos los clientes, ya que lo cierto es que hoy en dia IPv6 no te
> aporta nada por sobre IPv4. -- y las implementaciones de IPv6 tienen un
> nivel de madurez similar al que tenian las implementaciones de IPv4 en
> los '90.... con el agregado que es muchisimo mas complejo.
> 
> Asimismo: que es, especificamente, lo que crees que habria que probar de
> la propuesta en cuestión, y que es lo que crees que podría fallar?
> 
> 
>>> On 05/20/2012 11:17 AM, Arturo Servin wrote: [....]
>>>> Al menos el 40% de los dispositivos finales en el Internet
>>>> soportan IPv6 (Vista, Win7, OSx, Linux, y hasta XP -que no se si
>>>> entren en la estadistica- ).
>>> 
>>> *Soportan*, no *usan*. Justamente este detalle hace que sea 
>>> particularmente interesante hacer los cambios *ahora*.
>> 
>> No importa si lo usan o no, los tienes que cambiar.
> 
> Exacto. Dado que hoy en dia no se depende de manera critica de IPv6, y
> que esto es algo por mejorar, es el momento de hacerlo. Incluso si se
> implementara mal, hoy no habria impacto alguno. O preferis hacerlo en 15
> años, cuando realmente se dependa de IPv6?
> 
> 
>>> * Lo que yo quiero es cambiar el *standard* -- léase, la
>>> recomendación de lo que los stacks deben hacer. Esto no
>>> necesariamente debe afectar a stacks existentes (lease, productos
>>> que ya se encuentren vendidos/desplegados), sino principalmente a
>>> productos que se fabriquen/vendan de aca en adelante.
>> 
>> No si deprecias el estandar anterior, porque entonces fuerzas a los
>> otros productos a hacer el update o quedarse fuera del estándar. 
> 
> Nadie tiene porque ser compliant con una estandar que se creó despues de
> la propia implementación. De hecho, en tales casos, el dispositivo ya
> fue comprado, asi que... cual es el problema?
> 
> 
>> Si
>> lo que quieres es lo anterior, creando uno nuevo sin depreciar el
>> anterior me parece que es el balance justo.
> 
> Lo que me interesa es que la recomendacion sea generar direcciones no
> previsibles. -- no necesariamente "deprecatear" las direcciones
> actuales. Dicho mas propiamente, algo tipo "IPv6 implementations SHOULD
> [implementar draft-ietf-6man-stable-privacy-addresses]...".
> 
> 
> 
>>> * Por otro lado, lo que está mal, está mal. :-) Incluso si vos me 
>>> dijeras "el 80% de los sistemas hace X cosa", mi lectura
>>> simplemente seria "que pena que el 80% de los sistemas hagan las
>>> cosas mal" :-). Un monton de gente o dispositivos haciendo algo mal
>>> no hacen que ese "algo" pase a ser bueno.
>> 
>> Hay niveles de mal. IMHO no esta tan mal. Al final sigue siendo mejor
>> 2^24 que 2^8, 
> 
> Si.. Y ser tuerto es "mejor" que ser ciego :-) Pero yo siempre optaria
> por tener los dos ojos, en la emdida de lo posible...
> 
> 
>> y además esta el argumento si el scanning realmente
>> sirve de algo.
> 
> Esto es un argumento tipico de vendor, para no hacer nada. Para atacar
> un sistema, primero tenes que saber que existe. Entonces, salvo que
> sepas previamente de la existencia del sistema, el escaneo es mas que
> escencial.
> 
> 
> 
>>> * Tus numeros de "11 dias" (que no coinciden con los mios), asumen
>>> que el atacante está realizando el escaneo desde un unico sistema.
>>> Hoy en dia, no es para nada inusual que el atacante controle varios
>>> sistemas. De cualquier modo, el bottom-line es que pasamos de
>>> considerar algo inviable (500,000 años), a discutir sobre si el
>>> ataque dura 10 dias, o unas pocas horas. Mi presentación en LACSEC,
>>> mas que intentar arrojar un valor numérico respecto a cuanto puede
>>> tardar un ataque de escaneo, apuntó a señalar que los mismos son
>>> *viables*.
>> 
>> Es lo bueno de los números, uno los maquilla dependiendo a donde
>> quieres llegar. 
> 
> A mi no me interesa el numero, sino el orden de magnitud. 4 horas, 1
> dia, 10 dias o un mes, me da lo mismo.
> 
> El punto es que lo de los 500,000 años fue una expresion de deseo (o
> abuso de canabis :-) ). Y de errar para algun lado, es preferir errar
> del lado seguro.
> 
> 
>> La viabilidad puede estar, no lo dudo. Lo que discuto es querer
>> cambiar un estandar por algo que "puede ser" viable. El costo al
>> final del cambio es muy alto comparado con el riesgo (que creo es
>> bajo).
> 
> Cual es el costo? Que el vendor haga lo que tiene que hacer? Que la IETF
> mantenga las especificaciones como debe? O cual?
> 
> 
>>> * Ṕor otro lado, las propiedades del algoritmo especificado en 
>>> draft-ietf-6man-stable-privacy-addresses-00 dependen basicamente de
>>> las propiedades de la funcion criptografica F(). Funciones tales
>>> como MD5 y SHA han sido estudiadas, analizadas, y probadas con mas
>>> detenimiento y detalle que casi cualquier aspecto del protocolo
>>> IPv6.
>> 
>> Claro, el estandar no asegura como lo vas a implementar. Ya veo al
>> fabricante X usando una clave "default", una función mal programada,
>> o una generación mala de números aleatorias.
> 
> La especificacion dice que las claves se deben generar de manera
> aleatoria, y hasta se provee una referencia que explica bien claro "que
> se quiere decir con 'aleatorio'".
> 
> Si, esta claro que muchos vendors hacen muchas idioteces. Pero yo
> escribo drafts que apuntan a gente con un minimo de coherencia técnica.
> Si tengo que asumir que el tipo que va a leer mi trabajo es un idiota
> que no entiende que si la clave es conocida, el mecanismo muere,
> entonces en vez de enviar mis publicaciones a la IETF, las enviaria a
> algun simposio de psicologia.
> 
> Y no, no es que crea que nadie vaya a caer en la idiotez de claves por
> default, y esas cosas (de hecho, ni bien publicamos RFC 6528, tuve
> justamente una charla con un vendor sobre *exactamente* este tema)....
> Pero si vamos a condicionar el avance en un área en base a las idioteces
> que gente que deberia estar bien capacitada puede hacer, estamos perdidos.
> 
> 
> 
>> Con el resultado que
>> ahora en lugar de 2^24 va a ser trivial saber la dirección.
>> 
>> Otro punto a favor de esperar a ver como resulta, y entonces cambiar
>> el estándar.
> 
> Y en ese punto, el argumento sería que "IPv6 esta ampliamente
> desplegado... por lo cual es peligroso hacer cambios de ese estilo".
> 
> 
> 
>>> * Por ultimo, nadie hizo objeción alguna a las propiedades
>>> *técnicas* de lo propuesto en
>>> draft-ietf-6man-stable-privacy-addresses-00 (ni siquiera quienes de
>>> algun modo se opusieron al update formal de otros estandares, por
>>> motivos *politicos*).
>> 
>> Si, la solución es buena. El problema si lo hay, no va a ser el
>> algoritmo, sino la forma de implementarlo.
> 
> Bueno, pero eso no puede ser un argumento para no hacer lo que se debe
> hacer...
> 
> Tal vez podria agregar una seccion titulada "Idiocy considerations"? :-)
> 
> 
> 
>> Tampoco mucho hubo mucha objeción a favor de no depreciar el
>> estándar.
> 
> La gente con al que yo recuerdo haber hablado, apoyaba la idea de
> recomendar este approach. Pero con este I-D ya tuve varias batallas, y
> honestamente no me iba a poner a pelear yo solo esta otra.
> 
> 
> 
>>> Lo que personalmente me parece curioso (aunque honestamente no me 
>>> sorprende) es que ante indicadores concretos sobre la viabilidad
>>> de determinados ataques, y una propuesta bien concreta (simple, y 
>>> entendible) para solucionarlos, la comunidad opte por objeciones 
>>> politicas ante un problema técnico.
>> 
>> De regreso, la viabilidad aunque posible creo que es baja comparada
>> con el costo.
> 
> Si un tipo hace cosas tales como poner una clave por defecto en el
> algoritmo, el tipo es un idiota, y no hay remedio a eso.
> 
> 
> 
>> Si haces un análisis de riesgo e incluyes factores como la
>> posibilidad del ataque, el resultado del ataque, costo de cambio de
>> estándar, etc. te vas a dar cuenta que hacerlo poco a poco tiene mas
>> sentido.
> 
> Que resultado da tu analisis de riesgo cuando evaluas tener IPv6
> habilitado por defecto en un sistema operativo de proposito general?
> 
> Cual es la magnitud del mismo en comparación con el riesgo de
> implementar mi propuesta?
> 
> 
>>> Dios dirá como evoluciona la cosa por parte de los fabricantes.
>>> Pero me atrevo a decir que en materia de herramientas de escaneo
>>> tendremos avances este año -- tanto propios, como de otros miembros
>>> de la comunidad.
>> 
>> No creo que sea Dios. Va a ser una decisión de negocio como siempre.
> 
> Dios esta por sobre todos nosotros ;-)
> 
> 
> 
>> En cuanto tengas las herramientas, hagas real la viabilidad y le
>> aumentes el riesgo al problema el estándar va a caminar por si mismo,
>> eso tenlo por seguro. Pero al día de hoy no.
> 
> Ese es el problema. Es muy triste que hacer las cosas de manera
> colaborativa requiera x2 de esfuerzo.
> 
> Un abrazo,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont at si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
>