Re: Moving forward on improving HTTP's security

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