Re: Moving forward on improving HTTP's security

Ignoring improving aggregate security for a second (it would be beyond
foolish to do so longer than this paragraph), everyone seems to be
forgetting how poorly non http/1.1 actually works out there on the wild
wild internet.

10-20% failure rates are simply unacceptable for both site operators and
client writers.

-=R
 On Nov 13, 2013 9:09 PM, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:

> If I Rob this correctly, this may mean that a future version of IE will
> implement HTTP 2.0 without encryption for http: URIs.
>
> Next let's say that Apache 3.0 implements HTTP 2.0 which can be configured
> to run without encryption (after all, Apache is used in internal contexts,
> too).
>
> What's the chance of this *not* leaking out into the open internet and
> forcing other browser vendors to also allow HTTP 2.0 for http: URIs without
> encryption? After all, experience has shown that users quickly abandon a
> browser that doesn't work for some websites, and that browser vendors know
> about this and try to avoid it.
>
> Just some thoughts.
>
> Regards,    Martin.
>
> [Not a hacker,..., but just a maintainer of some small web sites with not
> enough time to set up certificates and TLS (similar to Karl).]
>
> On 2013/11/14 3:36, Rob Trace wrote:
>
>> We are one browser vendor who is in support of HTTP 2.0 for HTTP://URIs.  The same is true for our web server.  I also believe that we should
>> strongly encourage the use of TLS with HTTP, but not at the expense of
>> creating a standard that is as broadly applicable as HTTP 1.1.
>>
>>
>>
>> I think this statement correctly captures the proposal:
>>
>>
>>
>>  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.
>>>
>>
>>
>>
>> This is essentially what the document states today and this would fulfill
>> the requirements from the charter.
>>
>> -Rob
>>
>> From: Michael Sweet [mailto:msweet@apple.com]
>> Sent: Wednesday, November 13, 2013 10:27 AM
>> To: Mike Belshe
>> Cc: Tao Effect; Tim Bray; James M Snell; Mark Nottingham; HTTP Working
>> Group
>> Subject: Re: Moving forward on improving HTTP's security
>>
>> Honestly if there is no unencrypted path then you are just updating
>> HTTPS, not HTTP/1.1.
>>
>>
>> On Nov 13, 2013, at 1:14 PM, Mike Belshe<mike@belshe.com<mailto:
>> mike@belshe.com>>  wrote:
>>
>>
>> Agree with Tim; I am also in support of 100% TLS all the time.
>>
>> I would like us to do both Mark's proposals:
>>     (A)  opportunistic upgrade of http to SSL
>> and
>>     (C) HTTP/2.0 is TLS all the time.
>>
>> Mike
>>
>>
>> On Wed, Nov 13, 2013 at 9:46 AM, Tao Effect<contact@taoeffect.com<mailto:
>> contact@taoeffect.com>>  wrote:
>> On Nov 13, 2013, at 12:31 PM, Tim Bray<tbray@textuality.com<mailto:
>> tbray@textuality.com>>  wrote:
>> Let's not let the perfect be the enemy of the good.
>>
>> FWIW, here's one voice in support of HTTP/2==TLS.
>>
>> Not much content there supporting your vote. :-(
>>
>> A vote doesn't count (in my book at least), if it doesn't have strong
>> rationale before it.
>>
>> To me this also comes across as security theater (what a wonderful
>> expression).
>>
>> Let's get this clear:
>>
>> 1. Perfection is not being requested. Just something other than "abysmal".
>>
>> 2. TLS that depends on CAs is not by any means "good". It is bad. 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.
>>
>> - Greg
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing
>> with the NSA.
>>
>> On Nov 13, 2013, at 12:31 PM, Tim Bray<tbray@textuality.com<mailto:
>> tbray@textuality.com>>  wrote:
>>
>>
>> On Wed, Nov 13, 2013 at 9:22 AM, James M Snell<jasnell@gmail.com<mailto:
>> jasnell@gmail.com>>  wrote:
>> To be honest, much of this comes across to me as knee-jerk security
>> theater. Sure, using TLS is a good thing, but by itself it doesn't
>> come even remotely close to dealing with the range of fundamental
>> security and privacy issues that have come to light over the past few
>> months. If not handled properly, it could definitely give a false
>> sense of security.
>>
>> Let's not let the perfect be the enemy of the good.
>>
>> FWIW, here's one voice in support of HTTP/2==TLS.  And another saying
>> let's not give up on opportunistic encryption.
>>
>>
>>
>>
>>
>>
>> On Wed, Nov 13, 2013 at 2:01 AM, Mark Nottingham<mnot@mnot.net<mailto:
>> mnot@mnot.net>>  wrote:
>> [snip]
>>
>>>
>>> The most relevant proposals were:
>>>
>>>  FWIW, I intend to make another proposal once (a) the base http/2
>> protocol is complete and (b) protocol extensions have been dealt with
>> properly.
>>
>> [snip]
>>
>>>
>>> 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.
>>>
>>>  -1. HTTP/2 should not be limited to TLS only. If someone wishes to
>> craft text that strongly encourages use of TLS in specific
>> applications of HTTP/2, then that would be fine. But the protocol
>> itself should not require it.
>>
>>  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.
>>>
>>>  FWIW, I have to concur with the others on this thread, Mark. The
>> language you're using here makes it sound like the decision has
>> already been made.
>>
>>  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.
>>>
>>>  Again, -1 to making this a normative requirement. Our task ought to be
>> ensuring that people who bother to read the specification are fully
>> informed of the choices they are making, and not to make those choices
>> for them. Yes, I get it, some security is better than no security, but
>> adding constraints that only partially address the problem, just
>> because it makes us feel good or because it looks better from a PR
>> perspective, is not the right approach.
>>
>> What I think would be helpful is taking some time to draw up a
>> description of:
>>
>>    1. The specific types of threats to HTTP/1.1 and HTTP/2 we feel are
>> significant.
>>    2. The specific types of threats we collectively feel ought to be
>> addressed by HTTP/2, and the ones we feel are beyond our scope
>>    3. A broader list of options for how those threats can be mitigated
>>
>> In other words, an I-D describing the relevant threat model.
>>
>> Once we have that, we can make a more informed collective decision.
>>
>> - James
>>
>>  This is by no means the end of our security-related work. For example:
>>>
>>> * 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.
>>>
>>> * As discussed in the perpass BoF, strengthening how we use TLS (e.g.,
>>> for Perfect Forward Security) is on the table.
>>>
>>> * 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).
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>
>>
>>
>