Re: Re[2]: SPDY = HTTP/2.0 or not ?

On Mon, Mar 26, 2012 at 10:56 AM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
> ------ Original Message ------
> From: "Mike Belshe" <mike@belshe.com>
> To: "Roy T. Fielding" <fielding@gbiv.com>
> Cc: "patrick mcmanus" <pmcmanus@mozilla.com>;"ietf-http-wg@w3.org" <
> ietf-http-wg@w3.org>
> Sent: 26/03/2012 9:34:38 p.m.
> Subject: Re: SPDY = HTTP/2.0 or not ?
>
>
>
> On Mon, Mar 26, 2012 at 10:10 AM, Roy T. Fielding < <fielding@gbiv.com>
> fielding@gbiv.com> wrote:
>
>>  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.gmail.com>
>> 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 ;-)
>> > 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.
>>
>
> There are two discussions here:
>    a) should http be secured (and what "secured" means)
>
> a-1.  Should it be mandatory or optional.
>
> my vote: optional.
>
>
>      b) whether SSL is the right choice
>
> From a practical point of view, there aren't a lot of alternatives to SSL
> on the table right now.  Most people do agree that SSL does a reasonable
> job of preventing eavesdropping.
>
>
> I can see a lot of resistance from customers told they now need to buy and
> maintain a certificate from a CA just to run a webserver.
>

This is just not true.  Its free to get and has been for a while.


>
> Sure they can run a self-signed cert, but that doesn't fulfil the goal of
> giving the user security.
>
> There are so many devices running an HTTP server now which don't have the
> option to put in a cert.  E.g. web admin on my ADSL modem.
>

Well, your existing device doesn't support HTTP/2.0 either.  So maybe we
shouldn't build HTTP/2.0? :-)

Seems like a chicken and egg problem.



>
> It just makes no sense to say that it should be mandatory.
>
>
>
>> 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.
>>
>
> I don't know of any examples where users want unsecured products or
> protocols, actually.  We can't solve all security issues of course, but
> that doesn't mean we should leave it wide open either.  And we can solve
> much of the eavesdropping problem right now.  So the question is really -
> why wouldn't we?
>
>
> my biggest concern is the mandatory nature of SSL/TLS in the proposal.
>

Let's be clear - the current SPDY draft does not require SSL.



>
> We will get access to the payload.
>
> If it is allowed it in the protocol, we can do it well.
>
> Otherwise we will do it badly.  Which do you prefer?  We _will_ do it.
>

No disagreement here.



>
> Because customers insist we do.
>

We need to differentiate corporate and consumer requirements here.
 Consumers are not asking you to do this.  Private networks and
corporations are.  Both are legitimate.

Mike



> Adrien
>
>
>
>>
>> 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.
>>
>
> Protocols will only succeed if they provide real value.  There is a
> subjective question of whether security and privacy is part of the value or
> not.
>
> Mike
>
>
>
>>
>> ....Roy
>>
>>
>>
>