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


------ 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> 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>
> >> , 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.
  
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.
  
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.
  
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.
  
Because customers insist we do.
  
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