Re: Moving forward on improving HTTP's security

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
>
>

Received on Thursday, 14 November 2013 07:08:14 UTC