[lacnog] Fwd: [ PFIR ] No, I Don't Trust You! -- One of the Most Alarming Internet Proposals I've Ever Seen

Vie Feb 28 21:03:04 BRT 2014

On Fri, Feb 28, 2014 at 10:52 AM, Carlos Martinez
<carlosmarcelomartinez en gmail.com> wrote:
> Lo respondi en Chapter-Delegates, es una contribución individual , no es wg
> draft, y el tema esta sacado de proporción por gente que ni entiende como
> funciona la ietf.
>
> IDs locos se mandan o todo el tiempo, como el de los chinos que querían
> partir el root del DNS.
>
> La fortaleza de los procesos de estándar abiertos no es evitar que la gente
> tenga malas ideas, sino asegurar que esas malas ideas ni van a llegar a
> nada.

Carlos, excelente definición, está como para ponerla como cita inicial
de todos los RFCs.

>
> S2
>
> Carlos
>
> On Feb 28, 2014 1:40 PM, "Christian O'Flaherty"
> <christian.oflaherty en gmail.com> wrote:
>>
>>
>>>
>>> Compas, esto me pareció preocupante. ?Que opinan?
>>>
>>
>> Creo que el artículo es un poco exagerado... Actualmente es solo un draft
>> enviado (como tantos que se reciben en el IETF todo el tiempo).
>> Es una propuesta muy reciente e incipiente que propone un mecanismo para
>> incluir proxies en conexiones "seguras", incluyendo algún tipo de
>> notificación al usuario. Yo no creo que progrese... Quién va a aceptar eso
>> cuando está haciendo una transacción de banco?
>>
>> Christian
>>
>>>
>>> []s fraternos
>>>
>>> --c.a.
>>>
>>> -------- Original Message --------
>>> Subject: [ PFIR ]  No, I Don't Trust You! -- One of the Most Alarming
>>> Internet Proposals I've Ever Seen
>>> Date: Sat, 22 Feb 2014 21:05:38 -0800
>>> From: PFIR (People For Internet Responsibility) Announcement List
>>> <pfir en pfir.org>
>>> Reply-To: PFIR (People For Internet Responsibility) Announcement List
>>> <pfir en pfir.org>
>>> To: pfir-list en pfir.org
>>>
>>>
>>>             No, I Don't Trust You! -- One of the Most Alarming
>>>                     Internet Proposals I've Ever Seen
>>>
>>>                http://lauren.vortex.com/archive/001076.html
>>>
>>>
>>> If you care about Internet security, especially what we call
>>> "end-to-end" security free from easy snooping by ISPs, carriers, or
>>> other intermediaries, heads up! You'll want to pay attention to this.
>>>
>>> You'd think that with so many concerns these days about whether the
>>> likes of AT&T, Verizon, and other telecom companies can be trusted not
>>> to turn our data over to third parties whom we haven't authorized,
>>> that a plan to formalize a mechanism for ISP and other
>>> "man-in-the-middle" snooping would be laughed off the Net.
>>>
>>> But apparently the authors of IETF (Internet Engineering Task Force)
>>> Internet-Draft "Explicit Trusted Proxy in HTTP/2.0" (14 Feb 2014)
>>> haven't gotten the message ( http://j.mp/1fkCtnb [IETF] ).
>>>
>>> What they propose for the new HTTP/2.0 protocol is nothing short of
>>> officially sanctioned snooping.
>>>
>>> Of course, they don't phrase it exactly that way.
>>>
>>> You see, one of the "problems" with SSL/TLS connections
>>> (e.g. https:) -- from the standpoint of the dominant carriers anyway --
>>> is that the connections are, well, fairly secure from snooping in transit
>>> (assuming your implementation is correct ... right?)
>>>
>>> But some carriers would really like to be able to see that data in the
>>> clear -- unencrypted. This would allow them to do fancy caching
>>> (essentially, saving copies of data at intermediate points) and
>>> introduce other "efficiencies" that they can't do when your data is
>>> encrypted from your client to the desired servers (or from servers to
>>> client).
>>>
>>> When data is unencrypted, "proxy servers" are a routine mechanism for
>>> caching and passing on such data. But conventional proxy servers won't
>>> work with data that has been encrypted end-to-end, say with SSL.
>>>
>>> So this dandy proposal offers a dandy solution: "Trusted proxies" --
>>> or, to be more straightforward in the terminology, "man-in-the-middle
>>> attack" proxies. Oh what fun.
>>>
>>> The technical details get very complicated very quickly, but what it
>>> all amounts to is simple enough. The proposal expects Internet users
>>> to provide "informed consent" that they "trust" intermediate sites
>>> (e.g. Verizon, AT&T, etc.) to decode their encrypted data, process it
>>> in some manner for "presumably" innocent purposes, re-encrypt it, then
>>> pass the re-encrypted data along to its original destination.
>>>
>>> Chomping at the bit to sign up for this baby? No? Good for you!
>>>
>>> Ironically, in the early days of cell phone data, when full capability
>>> mobile browsers weren't yet available, it was common practice to
>>> "proxy" so-called "secure" connections in this manner. A great deal of
>>> effort went into closing this security hole by enabling true
>>> end-to-end mobile crypto.
>>>
>>> Now it appears to be full steam ahead back to even worse bad old days!
>>>
>>> Of course, the authors of this proposal are not oblivious to the fact
>>> that there might be a bit of resistance to this "Trust us" concept.
>>> So, for example, the proposal includes the assumption of mechanisms
>>> for users to opt-in or opt-out of these "trusted proxy" schemes.
>>>
>>> But it's easy to be extremely dubious about what this would mean in
>>> the real world. Can we really be assured that a carrier going through
>>> all the trouble of setting up these proxies would always be willing to
>>> serve users who refuse to agree to the proxies being used, and allow
>>> those users to completely bypass the proxies? Count me as skeptical.
>>>
>>> And the assumption that users can even be expected to make truly
>>> informed decisions about this seems highly problematic from the
>>> git-go. We might be forgiven for suspecting that the carriers are
>>> banking on the vast majority of users simply accepting the
>>> "Trust us -- we're your friendly man-in-the-middle" default, and not even
>>> thinking about the reality that their data is being decrypted in
>>> transit by third parties.
>>>
>>> In fact, the fallacies deeply entrenched in this proposal are
>>> encapsulated within a paragraph tucked in near the draft's end:
>>>
>>> "Users should be made aware that, different than end-to-end HTTPS, the
>>> achievable security level is now also dependent on the security
>>> features/capabilities of the proxy as to what cipher suites it
>>> supports, which root CA certificates it trusts, how it checks
>>> certificate revocation status, etc.  Users should also be made aware
>>> that the proxy has visibility to the actual content they exchange with
>>> Web servers, including personal and sensitive information."
>>>
>>> Who are they kidding? It's been a long enough slog just to get to the
>>> point where significant numbers of users check for basic SSL status
>>> before conducting sensitive transactions. Now they're supposed to
>>> become security/certificate experts as well?
>>>
>>> Insanity.
>>>
>>> I'm sorry gang, no matter how much lipstick you smear on this
>>> particular pig -- it's still a pig.
>>>
>>> The concept of "trusted proxies" as proposed is inherently
>>> untrustworthy, especially in this post-Snowden era.
>>>
>>> And that's a fact that you really can trust.
>>>
>>> --Lauren--
>>> I'm a consultant to Google. My postings are speaking only for myself,
>>> not for them.
>>>  - - -
>>> Lauren Weinstein (lauren en vortex.com): http://www.vortex.com/lauren
>>> Co-Founder: People For Internet Responsibility:
>>> http://www.pfir.org/pfir-info
>>> Founder:
>>>  - Network Neutrality Squad: http://www.nnsquad.org
>>>  - PRIVACY Forum: http://www.vortex.com/privacy-info
>>> Member: ACM Committee on Computers and Public Policy
>>> Lauren's Blog: http://lauren.vortex.com
>>> Google+: http://google.com/+LaurenWeinstein
>>> Twitter: http://twitter.com/laurenweinstein
>>> Tel: +1 (818) 225-2800 / Skype: vortex.com
>>> _______________________________________________
>>> pfir mailing list
>>> http://lists.pfir.org/mailman/listinfo/pfir
>>>
>>>
>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
>>
>>
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
>>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
>