Re: Draft Minutes of 8 Dec 2011 Teleconference

On Sat, 10 Dec 2011, Mike Belshe wrote:

> Hi, folks -
>
> I had a couple of comments to add.  I hope these are useful.
>
> See below:
>
> On Fri, Dec 9, 2011 at 3:33 AM, Daniel Appelquist <dan@bluevia.com> wrote:
>
>>   Yves: some background - the first thing is about the use of TLS?
>>   there are many people that are for it - firesheep is a good example
>>   of dangers of putting everything in the clear. There are technical
>>   issues though - intermediaries can't work because it can't be
>>   cached?
>
> This actually isn't true.  The chrome implementation of SPDY supports
> proxies with hierarchical caching today.
>
> Generally, there has been no solution for SSL based hierarchical caching
> through proxies.  This isn't a problem caused or introduced by SPDY.  Its a
> problem due to encrypting the stream end-to-end.

Yes, it was a general point about the use of TLS (so end-to-end encryption)

> However, we did build this into Chrome with SPDY, and it is deployed today.
> You can do SPDY to your proxy, and provide hierarchical caching on your
> proxy.   Of course, for end-to-end secure configurations (like to your
> bank), you still can't cache at the proxy.  But this the desired behavior -
> and exactly what we have with SSL today.
>
> See also:  http://dev.chromium.org/spdy/spdy-proxy-examples
>
> Since proxies never before have supported SSL, it is important to start
> differentiating two different types of proxies:
>   * Transparent proxies
>   * Explicit proxies
>
> Transparent proxies, in my opinion and in the opinion of many, are quite
> problematic.  Allowing transparent proxies into the system allows someone
> to tamper with the data stream in ways which neither the user, nor the
> origin server intended or authorized.  This type of behavior has been
> documented repeatedly.
>
> Explicit proxies are proxies that the browser knows about and has the
> opportunity to reject.  There is nothing inherent to SSL or SPDY which
> prevents use of explicit proxies.  They've never been implemented in
> browsers before, but as mentioned above, there are existing implementations..
>
> Finally, while I am pointing out that this has been done and works today,
> I'm still advocating that the entire world move to SSL for all content (see
> below).   If we do this latter step, the proxy work is kinda wasted.

Yes, transparent proxies can at best act as man-in-the-middle which is 
problematic for any kind of secure connection.

In the case of SPDY (when TLS is used in general) for the connection to 
the proxy, and you are proxying an https URI, you end up ciphering twice 
which is not needed and not optimal.
There are also issues with the use of CONNECT in proxies (usually 
mitigated by forbidding them or restricting to port 80 or 443).
(So hop-by-hop security needs more work :) )

[..]
>>   Noah: I said we should be hesitant about encrypting things that
>>   don't need to be encrypting. What I'm hearing is that more on the
>>   Web has a need to be encrypted then I'm thinking. So the
>>   constitution of the US is public but the fact that I'm reading it is
>>   private... But in that case, we end up encrypting the text of the
>>   constitution possibly unnecessariliy....
>>
>
> You're nailing it here.  The world has changed since 15 years ago in a
> couple of dramatic ways:
>
>   a) Its increasingly clear that the users of the internet don't know what
> it means to be secured, and they can't differentiate secure vs unsecure on
> their own.
>
>   b) The use of cookies over HTTP is downright dangerous (witness
> Firesheep)
>
>   b) Privacy attacks are going through the roof.  We read about them every
> day.

Well, privacy attacks are form different sources, you can have 
privacy-invasive site (and web-apps) that are using secure transports. 
Privacy is not equivalent to unsnoopable (see also API minimisation)

> I believe the only solution is for the protocol experts to take a
> leadership role and make sure we're on path to have users and websites
> protected always.
>
> But, if we really think we want to maintain an unsecured protocol, how
> about if we work toward a world where we flip the default?  By default, the
> protocol is secure.   If they want to opt out, power users can do so.  It's
> like "safety first".

And we should be careful about not giving a false sense of safety to 
people as well :) (see air bags and seat belts).

>>   everything - the impact of intermediaries, etc?
>>
>
> I hear these concerns repeatedly, but I have yet to see them substantiated.
> First, lets break down the SSL performance issues:
>   a) Impact of the SSL handshake (round trips, cert validation, etc)
>   b) Cost of bulk encryption
>   c) Server CPU impact
>   d) Bad SSL implementations
>
> (a) is a problem.  The introduction of False Start takes out a round trip,
> which makes it a lot better.  Browsers have also been horrifically bad at
> caching OCSP responses and adopting things like session tickets.  OCSP
> stapling is new work, but needs to handle multi-level certificate chains
> better.
>
> I can go on for days about this topic :-)
>
> SPDY mitigates most of this by just using fewer connections.  Once your
> connection is established, you don't need to handshake anymore.

Well, if you have multiple TLS connection to the same site then yes, if 
you gather data from multiple sites, the problem is still there.

> Resources:
> http://www.belshe.com/2011/05/19/ssl-falsestart-performance-results/
> http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>
> (b) This is a pure myth.  The bulk-encryption cypher is just super cheap.
> I recommend use of RC4, which is literally just a few xors on your data
> stream.  The attached research shows that you can encrypt and decrypt 100KB
> of data in less than a 3rd of an average round trip (avg RTT is ~100ms)!!

Especially as there are specific cpu instructions to help on that front, 
however it can still be an issue for low-power devices.
(I saw that you adress that later, so yeah what is (or may be seen as) a 
performance issue now might not be anymore when it's deployed)
The main issue is still the certificates, but that's mostly out the scope 
of this work (it is in scope for discussing optimizations)

> Resources:
> http://www.ijcttjournal.org/volume-1/Issue-3/IJCTT-V1I3P107.pdf
>
> c) This is a potential issue, but in practice not often the problem.  It is
> true that SSL uses more CPU.  But its pretty small - when Google turned on
> SSL for all of GMail, how much did CPU increase?  1%.  On top of that, for
> modern websites, CPU often isn't the bottleneck anyway.  I haven't seen any
> recent research which indicates this is a problem.
>
> Resources:
> http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>
> d) SSL implementations are notoriously poor.  For the past 15 years very
> little optimization has been applied.  And in virtually every SSL stack
> I've looked at (including Google's servers, Android, and Chrome's client),
> there have been major, obvious implementation problems.  Troubling as well
> is that some browsers rely on the SSL stack which is embedded in the OS
> (e.g. IE, Safari).  This means that these browsers are at the mercy of the
> OS upgrade in order to get more modern SSL implementations.  (which is why
> SNI isn't ubiquitous- thanks WinXP)
>
> Resources:
> http://www.belshe.com/2010/12/17/performance-and-the-tls-record-size/
>
>
> One last plea to end the SSL performance complaint:
>
> It's going to take us ~2 yrs to standardize anything new.  Measuring
> performance with today's CPUs for a protocol that doesn't ship for 2 years
> is a bit behind the curve.  I've already demonstrated that every aspect of
> SSL performance is acceptable today on today's computers.  But if you're
> still not 100% convinced, remember that Moore's law dictates that we'll
> have 4x more CPU power for the buck than we have today when any next
> protocol ships.
>
> As a counter argument, I think the mobile arena is an interesting area of
> study.  The good news is that this is happening as we speak.  But by the
> time any new protocol ships, these mobile phones in our pockets will have
> quad cores.  I'm just not worried about it.  Reducing the number of
> round-trips is far more important.
>
>
>
>
>>   <noah> I don't think it's just encrytion vs. deployed
>>   infrastructure. I think it's "the benefits of encryption vs. the
>>   overhead of doing it, and the loss of flexible use of the encrypted
>>   information" I as pointing out http-ng as a caution sign - where not
>>   to go. I remember there being some serious problems trying to
>>   multiplex multiple connections over a single TCP connection. At the
>>   time it was unsolvable. maybe this isn't an issue for the use case
>>   for which SPDY was designed - all the threads coming from a single
>>   managed server. You might have a problem where the endpoints are on
>>   the other side of a gateway or a proxy - not so managed. Also I'm
>>   having trouble imagining a long tail where http 1.1 disappears. http
>>   1.1 and 1.0 seems to be in so many embedded devices and
>>   controllers?.
>>
>>   <noah> Why are we talking about HTTP 1.1 going away. I think SPDY,
>>   if it's a good think is like HTTP 1.0 to 1.1; everyone implements
>>   both, but the use of (something similar to) SPDY grows. given those
>>   two constrains - might be better as an upgrade option rather than a
>>   replacement.
>>
>
> I don't see SPDY as a replacement.  One of the best arguments for keeping
> HTTP is video streams.  SPDY does nothing to help video today.

Well, in some case, encrypting outgoing video streams is useful, but it's 
true that SPDY or any other protocol won't help once you have end-to-end 
encryption, which is already available.

> I hope these comments are helpful, and thank you all your hard work and for
> advancing the discussion about HTTP futures.

They are, thank you for the follow-up!

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 13 December 2011 15:33:21 UTC