W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: SPDY = HTTP/2.0 or not ?

From: Mike Belshe <mike@belshe.com>
Date: Mon, 26 Mar 2012 10:21:03 +0200
Message-ID: <CABaLYCvS7X_xqXh8EtO8aZ0XVjbj2vtffPAFGiT9r+3EWVEYXw@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Brian Pane <brianp@brianp.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Mar 26, 2012 at 7:56 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> In message <CAAbTgTu7qbPiREWRRqFddgoko0FCt0jmxR=
> NP1gqsiARCwscew@mail.gmail.com>
> , Brian Pane writes:
> >Nonetheless, I think it would be reasonable for HTTP/2.0 to require SSL.
> I think you need to talk to some people with big websites ;-)

We're at a crossroads here, which comes down to goals.

One one hand, we have the opportunity to help users have secure access to
the web, always.

On the other hand, we can continue to allow websites to be unsecured,
creating privacy and security risks for users.

I challenge you to find a single user on the web that wants an unsecured
Internet.  I don't think these users exist. Everyone wants privacy and
security; and most users don't realize they don't have it.  I know there
are websites which want to minimize their capital expenditure costs, even
if it puts their users at risk.  We could cater to the websites - or we
could cater to the users.

Which is more forward looking?  Which road do you want to take?

In all other products, security is not an option.  It's a requirement.
Users expect it and users need it.  How can anyone seriously argue to not
even try in our protocols?  If not now, when would you argue to start
trying?  Never?

Two last things.

First, whatever we define today takes years to deploy.  CPU costs continue
to go down at a remarkable rate.  Moore's law over the last decade has
definitely made SSL viable on cheap hardware like never before.   We should
be designing for going forward - where CPU costs continue to shrink.  If a
website is willing to put its users at risk (which is downright
irresponsible if you ask me), let them use HTTP/1.1.  The future should be

Second, SSL will remain substandard on performance until we make it a
requirement.  Its a self-fulfilling prophecy that SSL implementations are
slow as long as we don't try to take them seriously.


PS - if you don't believe me about the importance of security, look to all
the major content providers for social activity today.  Google and Twitter
are already 100% SSL.  Facebook and Microsoft are not far behind.  Users
need security and they need it now.  We should stop talking about it as
though its optional.

A better argument would be "is SSL the right way to secure the web?", and
 not,  "should we secure the web?".

> There are a large swath of the HTTP traffic that doesn't need and cannot
> afford the overhead of crypto and if you mandate that HTTP/2.0 use
> crypto, they will simply stay on HTTP/1.1 forever.
> If we act sensibly and make room for multiple transports, it is a non
> issue, because then you can have one transport with and one without
> crypto.
> Which is amazingly just like the situation today:  The servers which care
> about ident/auth/integ/priv/... run HTTPS, everybody else runs HTTP.
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 26 March 2012 08:21:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:01 UTC