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> 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> wrote:
> On Nov 13, 2013, at 12:31 PM, Tim Bray <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> wrote:
> 
>> On Wed, Nov 13, 2013 at 9:22 AM, James M Snell <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> 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