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

RE: SPDY = HTTP/2.0 or not ?

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Mon, 26 Mar 2012 21:35:11 +0000
To: "Roy T. Fielding" <fielding@gbiv.com>, patrick mcmanus <pmcmanus@mozilla.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <3605BA99C081B54EA9B65B3E33316AF7199207CE@CH1PRD0310MB392.namprd03.prod.outlook.com>
FWIW, I completely agree with this -- another set of scenarios include the many connected devices large and small that come with an HTTP server baked in. It would be infeasible or undesired to require SSL for many of these devices. 


-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: Monday, March 26, 2012 1:10 AM
To: patrick mcmanus
Cc: ietf-http-wg@w3.org
Subject: Re: SPDY = HTTP/2.0 or not ?

On Mar 26, 2012, at 9:44 AM, patrick mcmanus wrote:

> On 3/26/2012 7:56 AM, Poul-Henning Kamp wrote:
>> In 
>> message<CAAbTgTu7qbPiREWRRqFddgoko0FCt0jmxR=NP1gqsiARCwscew@mail.gmai
>> l.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 ;-)
> Existence proofs: google does all of their logged in user search over SSL, Twitter encourages SSL by default, Facebook is widely used that way. It pretty clearly can be done at scale. Its not free, but its worth it.
> More importantly - no user wants to use an insecure protocol - ever. Web protocol design should serve them first. They have an unmet expectation of privacy and security that we should meet by making the application protocol secure all the time; the mixed- content vulnerabilities of HTTP/1 make that clear to me.

I've never considered SSL to be a means of securing the protocol.
It does a decent job of hiding the exchange of data from passive observers, but the way that typical user agents handle certificate management lacks what I would consider a secure protocol.

In any case, the notion that every user wants a secure protocol is irrelevant.  There are many examples of HTTP use, in practice, for which SSL/TLS is neither desired nor appropriate.  Even simple things, like the exchange that Apple devices use to discover network access point logins, cannot work with an assumption of SSL/TLS.  Likewise, many uses of HTTP are in kiosks, public schools, libraries, and other areas for which your concern as a user is less important than the organization's responsibility to prevent misuse.

There are ways to have both a secure protocol and visibility for intermediaries, but we don't have to agree to any of these "requirements"
up front.  If the protocol proposals can't stand for themselves, then I have no need for a new protocol.

Received on Monday, 26 March 2012 21:36:12 UTC

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