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