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


------ Original Message ------
From: "Mike Belshe" mike@belshe.com
> 
>  
> 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.
  
My point is that these types of deployment will exist in future, yet 
may not be capable of running SSL (or at least installing a cert) for a 
number of reasons (maybe not even technical, but more likely 
administrative).
  
If we want HTTP/1.1 to eventually disappear, we need to cater to these 
applications.
  
If we don't, then are we improving things?
  
>
> 
>  
> 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.
  
OK thanks.  I haven't read the recent drafts.  My understanding 
(obviously out of date) was that SSL was required to negotiate the 
support for SPDY by the server.
>
> 
>  
> 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.
  
the ones who pay us are the corporates.
  
Adrien
>
>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
 >  
 >  
>