<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">If you haven't heard, the IETF is trying to move forward with "HTTP 2.0", which is, from what I can tell, simply "HTTPS all the time".<div><br></div><div>We know HTTPS is broken and that it gives people a false sense of security, leading them to share material that they otherwise might not share, with potentially life threatening consequences.</div><div><br></div><div>If you'd like to weigh in on this matter, you are welcome to subscribe and share your point of view before they do something rash and unreasonable.</div><div><br></div><div>To subscribe, send an email (subject: "Subscribe") to: <a href="mailto:ietf-http-wg-request@w3.org">ietf-http-wg-request@w3.org</a><br><div><br class="webkit-block-placeholder"></div><div>Part of an exchange about this topic below is forwarded below:</div><div>
<br>--<br>Please do not email me anything that you are not comfortable also sharing with the NSA.<br>

</div>

<div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Resent-From: </b></span><span style="font-family:'Helvetica';"><a href="mailto:ietf-http-wg@w3.org">ietf-http-wg@w3.org</a><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica';">Tao Effect <<a href="mailto:contact@taoeffect.com">contact@taoeffect.com</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica';"><b>Re: Moving forward on improving HTTP's security</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica';">November 13, 2013 at 1:27:38 PM EST<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica';">Mike Belshe <<a href="mailto:mike@belshe.com">mike@belshe.com</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Cc: </b></span><span style="font-family:'Helvetica';">Tim Bray <<a href="mailto:tbray@textuality.com">tbray@textuality.com</a>>, James M Snell <<a href="mailto:jasnell@gmail.com">jasnell@gmail.com</a>>, Mark Nottingham <<a href="mailto:mnot@mnot.net">mnot@mnot.net</a>>, HTTP Working Group <<a href="mailto:ietf-http-wg@w3.org">ietf-http-wg@w3.org</a>><br></span></div><br><div><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><blockquote type="cite"><div dir="ltr">Agree with Tim; I am also in support of 100% TLS all the time.</div></blockquote><div><br></div><div>Here are some nice quotes from the EFF about the system you are supporting (without any explanation):</div><div><br></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><i>As we learned from the <a href="https://www.eff.org/observatory">SSL Observatory</a> project, there are <a href="https://www.eff.org/files/colour_map_of_CAs.pdf">600+ Certificate Authorities</a> that your browser will trust; the attacker only needs to find one of those 600 that she is capable of breaking into. This has <a href="https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https">been</a> <a href="https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-against-google">happening</a> with <a href="https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack">catastrophic results</a>.</i></blockquote></div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><i>Certificate-based attacks are a concern all over the world, <a href="https://twitter.com/#%21/csoghoian/status/111416087979114497">including in the U.S.</a>, since governments everywhere are eagerly adopting spying technology to eavesdrop on the public. Vendors of this technology <a href="http://files.cloudprivacy.net/ssl-mitm.pdf">seem to suggest the attacks can be done routinely</a>. </i></blockquote><div><div><br></div><div>In many cases, people's lives are literally ended (or destroyed) because of this system.</div><div><br></div><div>I do not support such a system, and am very suspicious of folks voicing their support without a word of explanation.</div><div><br></div><div>I am reminded of how easy it is for a malicious entity to infiltrate a group and manipulate their opinion through sock-puppets. Not to say that you are one, but it's something that I'm reminded of each time I come across these types of situations.</div><div><br></div><div>Let's not have another NSA/NIST situation here.</div><div><br></div><div>Links:</div><div><br></div><div><a href="https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https">https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https</a></div><div><a href="https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack">https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack</a><br><div><br class="webkit-block-placeholder"></div><div>Cheers,</div><div>Greg</div><div>
<br>--<br>Please do not email me anything that you are not comfortable also sharing with the NSA.<br>

</div>
<br><div><div>On Nov 13, 2013, at 1:14 PM, Mike Belshe <<a href="mailto:mike@belshe.com">mike@belshe.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Agree with Tim; I am also in support of 100% TLS all the time.<div><br></div><div>I would like us to do both Mark's proposals:</div><div>   (A)  opportunistic upgrade of http to SSL</div><div>and</div><div>

   (C) HTTP/2.0 is TLS all the time.</div><div><br></div><div><div>Mike</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 9:46 AM, Tao Effect <span dir="ltr"><<a href="mailto:contact@taoeffect.com" target="_blank">contact@taoeffect.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im">On Nov 13, 2013, at 12:31 PM, Tim Bray <<a href="mailto:tbray@textuality.com" target="_blank">tbray@textuality.com</a>> wrote:<blockquote type="cite">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Let’s not let the perfect be the enemy of the good.</div><div><br></div><div>FWIW, here’s one voice in support of HTTP/2==TLS.</div></div></div></div></blockquote>
<br></div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Not much content there supporting your vote. :-(</div><div><br></div><div>A vote doesn't count (in my book at least), if it doesn't have strong rationale before it.</div>
<div><br></div><div>To me this also comes across as security theater (what a wonderful expression).</div><div><br></div><div>Let's get this clear:</div><div><br></div><div>1. Perfection is not being requested. Just something other than "abysmal".</div>
<div><br></div><div>2. TLS that depends on CAs is not by any means "good". It is <b>bad.</b> Very bad. I would even support a viewpoint that says it's worse than HTTP because of the false sense of security that it gives people.</div>
<div><br></div><div>- Greg</div></div></div></div></div><div class="im"><div>
<br>--<br>Please do not email me anything that you are not comfortable also sharing with the NSA.<br>

</div>

<br></div><div><div class="h5"><div><div>On Nov 13, 2013, at 12:31 PM, Tim Bray <<a href="mailto:tbray@textuality.com" target="_blank">tbray@textuality.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">
On Wed, Nov 13, 2013 at 9:22 AM, James M Snell <span dir="ltr"><<a href="mailto:jasnell@gmail.com" target="_blank">jasnell@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">To be honest, much of this comes across to me as knee-jerk security<br>

theater. Sure, using TLS is a good thing, but by itself it doesn't<br>
come even remotely close to dealing with the range of fundamental<br>
security and privacy issues that have come to light over the past few<br>
months. If not handled properly, it could definitely give a false<br>
sense of security.<br></blockquote><div><br></div><div>Let’s not let the perfect be the enemy of the good.</div><div><br></div><div>FWIW, here’s one voice in support of HTTP/2==TLS.  And another saying let’s not give up on opportunistic encryption.</div>

<div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<div><br>
On Wed, Nov 13, 2013 at 2:01 AM, Mark Nottingham <<a href="mailto:mnot@mnot.net" target="_blank">mnot@mnot.net</a>> wrote:<br>
</div>[snip]<br>
<div>><br>
> The most relevant proposals were:<br>
><br>
<br>
</div>FWIW, I intend to make another proposal once (a) the base http/2<br>
protocol is complete and (b) protocol extensions have been dealt with<br>
properly.<br>
<br>
[snip]<br>
<div>><br>
> As a result, I believe the best way that we can meet the goal of increasing use of TLS on the Web is to encourage its use by only using HTTP/2.0 with https:// URIs.<br>
><br>
<br>
</div>-1. HTTP/2 should not be limited to TLS only. If someone wishes to<br>
craft text that strongly encourages use of TLS in specific<br>
applications of HTTP/2, then that would be fine. But the protocol<br>
itself should not require it.<br>
<div><br>
> This can be effected without any changes to our current document; browser vendors are not required to implement HTTP/2.0 for http:// URIs today. However, we will discuss formalising this with suitable requirements to encourage interoperability; suggestions for text are welcome.<br>


><br>
<br>
</div>FWIW, I have to concur with the others on this thread, Mark. The<br>
language you're using here makes it sound like the decision has<br>
already been made.<br>
<div><br>
> To be clear - we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for the common case -- browsing the open Web -- you'll need to use https:// URIs and if you want to use the newest version of HTTP.<br>


><br>
<br>
</div>Again, -1 to making this a normative requirement. Our task ought to be<br>
ensuring that people who bother to read the specification are fully<br>
informed of the choices they are making, and not to make those choices<br>
for them. Yes, I get it, some security is better than no security, but<br>
adding constraints that only partially address the problem, just<br>
because it makes us feel good or because it looks better from a PR<br>
perspective, is not the right approach.<br>
<br>
What I think would be helpful is taking some time to draw up a description of:<br>
<br>
  1. The specific types of threats to HTTP/1.1 and HTTP/2 we feel are<br>
significant.<br>
  2. The specific types of threats we collectively feel ought to be<br>
addressed by HTTP/2, and the ones we feel are beyond our scope<br>
  3. A broader list of options for how those threats can be mitigated<br>
<br>
In other words, an I-D describing the relevant threat model.<br>
<br>
Once we have that, we can make a more informed collective decision.<br>
<span><font color="#888888"><br>
- James<br>
</font></span><div><br>
> This is by no means the end of our security-related work. For example:<br>
><br>
> * Alternate approaches to proxy caching (such as peer-to-peer caching protocols) may be proposed here or elsewhere, since traditional proxy caching use cases will no longer be met when TLS is in wider use.<br>
><br>
> * As discussed in the perpass BoF, strengthening how we use TLS (e.g., for Perfect Forward Security) is on the table.<br>
><br>
> * A number of people expressed interest in refining and/or extending how proxies work in HTTP (both 1.0 and 2.0), as discussed in draft-nottingham-http-proxy-problem (among many other relevant drafts).<br>
><br>
> Furthermore, other security-related work in the IETF (see the perpass BoF) and elswhere (e.g., W3C) may affect HTTP. For example, a number of people have pointed out how weaknesses in PKIX affect the Web.<br>
><br>
> Your input, as always, is appreciated. I believe this approach is as close to consensus as we're going to get on this contentious subject right now. As HTTP/2 is deployed, we will evaluate adoption of the protocol and might revisit this decision if we identify ways to further improve security.<br>


><br>
><br>
<br>
</div></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div></body></html>