Re: [hybi] Extensibility mechanisms?

[Mike Belshe <[e-mail]>]

On Fri, Apr 16, 2010 at 1:13 PM, Ian Hickson <[e-mail]> wrote:

> On Fri, 16 Apr 2010, Greg Wilkins wrote:
> >
> > The whole point of having a standard like websocket, is so that the
> > network infrastructure can implement the RFC and then we have known
> > semantics over that connection that intermediaries can at least handle
> > correctly, but may also do clever stuff with.
>
> That wasn't even on my list of reasons for originally coming up with
> TCPConnection, let alone the main reason.
>
> The main reason for the Web Socket protocol is to have one protocol that
> the browsers can all implement in an interoperable fashion so that servers
> can implement things once and have them work with all browsers. In the
> ideal deployment the connection is wrapped in end-to-end TLS, so the
> intermediaries can't do anything with it. There were only two reasons for
> even allowing unencrypted Web Socket originally: requiring amateurs to
> figure out TLS seemed like too high a bar, and there is still some concern
> that when the connection is being used for entirely public information,
> the TLS connection overhead is too expensive to justify.
>

We've done extensive tests on TLS.  There are four latency issues:
  a) CPU on the handshake. TLS is now cheap on modern hardware, and it gets
cheaper every day.  I'm sure there are a few sites which might have some
trouble migrating to 100% TLS, but when designing for protocols of the
future, this is not an issue (Moore's law!).  Round trips are orders of
magnitude more expensive than the CPU overhead of the handshake.  We do need
to make sure TLS implementations pick up modern extensions like client-side
session tickets.
  b) CPU on bulk encryption.  Once you get beyond the handshake, you can
negotiate RC4; we've benchmarked it, and it is the same speed as using the
null-cipher.  Using other ciphers are sometimes expensive, each is
different.
  c) Handshake Round Trips.  The extra round trip for TLS is the worst part
of TLS from a latency perspective (100ms to resume a session).  But,
WebSockets has a handshake of its own which is also 100ms!  So, if you're
going to take a handshake, you may as well get crypto while you do it - *it's
free!*
  d) Bandwidth.  TLS does use 2-3% more bandwidth than non-TLS on typical
page loads.  This is largely weighted in the handshake overhead, so it gets
amortized if you use the websocket over time.

Another common argument is the "I don't want to buy a certificate" argument,
but there are now CAs offering free certs which are trusted in all browsers'
root-ca lists.

Mike



>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>