Re: Moving forward on improving HTTP's security

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