Re: Moving forward on improving HTTP's security

Hi Julian,

On Wed, Nov 13, 2013 at 03:11:18PM +0100, Julian Reschke wrote:
> On 2013-11-13 14:54, Willy Tarreau wrote:
> >On Wed, Nov 13, 2013 at 08:21:17AM -0500, Michael Sweet wrote:
> >>I also believe that HTTP/1.x has been so successful because of its ease 
> >>(and
> >>freedom) of implementation. But IMHO restricting its use to https:// will
> >>only limit its use/deployment to sites/providers that can afford to 
> >>deploy it
> >>and prevent HTTP/2.0 from replacing HTTP/1.1 in the long run.
> >
> >That's a good point. I'd say I know some people who push *terabits* of pink
> >pixels over the net and who had never heard about HTTP/2 nor SPDY before I
> >talked to them about it and who still don't see the value there. Just like
> >they do zero TLS and do not expect to ever use it. So there's a use for
> >everything.
> >...
> We need so understand that there are two almost orthogonal 
> considerations for "HTTP":
> (a) whether somebody gets the wire-format related improvements (header 
> compression, push, multiplexing)
> (b) whether communication will be in the clear (1), encrypted but not 
> authenticated (2), encrypted and authenticated (3)
> Looking at our charter (<>):
> >It is expected that HTTP/2.0 will:
> >* Substantially and measurably improve end-user perceived latency in most
> >cases, over HTTP/1.1 using TCP.
> >* Address the "head of line blocking" problem in HTTP.
> >* Not require multiple connections to a server to enable parallelism, thus
> >improving its use of TCP, especially regarding congestion control.
> >* Retain the semantics of HTTP/1.1, leveraging existing documentation (see
> >above), including (but not limited to) HTTP methods, status codes, URIs, 
> >and
> >here appropriate, header fields.
> > ...
> if we don't define HTTP/2.0 for "http:" URIs, we'll be missing one 
> of the goals in our charter.

I whole heartly agree and that was my point in my conclusion. We need to
*define* it for everything and see how users *adopt* it. I'm convinced
that there will be a lot of valid usages for the cleartext version,
starting with application developers for whom it's always a mess to have
to request a certificate or to analyse a capture to see their headers,
and continuing with CDNs which are absolutely required these days if we
don't want to break the whole internet.

Best regards,

Received on Wednesday, 13 November 2013 14:20:14 UTC