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

Vie Feb 28 12:52:11 BRT 2014

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.

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
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20140228/9e165198/attachment.html>