Re: [hybi] On TLS-only Approaches

[Mark Nottingham <[e-mail]>]

The reason that the figures for non-TLS WebSockets are so low is that -- shock -- no one's really using WebSockets yet.

If we're successful -- i.e., if we standardise and ship in all major browsers -- a new protocol on a new port, that changes the environment substantially. 

To wit, firewall administrators will either already be aware of WebSockets, or will become aware of it when they get complaints from their users. They will then choose to either allow it, or to block it purposefully. 

As soon as GMail / Yahoo / Amazon / whatever puts up a "you have to hit this button / can't see pretty eye candy because your network doesn't support WebSockets", it creates a massive amount of pressure on them. This is NOT the same problem as getting users to upgrade browsers; we're talking about a much smaller, more IT-educated, and professional (i.e., paid to do this) group of people. Deployment won't happen overnight, but it won't be as slow as most expect.

And, after that, if it isn't allowed in a substantial number of networks, maybe this tells us something about designing and deploying a semantically opaque TCP-like protocol that runs from remotely obtained code on desktop machines. WS is *much* more broadly capable than just letting servers send async events to HTTP clients (as it was originally sold). 

Regards,

P.S. A general observation - I find it really remarkable that so many talented engineers are able to ignore the fundamentals of game theory.


On 23/08/2010, at 5:45 AM, Eric Rescorla wrote:

> I'd like to take a brief detour from the topic of framing and (re)discuss the topic of whether
> we want to require TLS only. Aside from the obvious security advantages, it appears
> that TLS-based approaches are likely to be a lot more successful. Adam Langley
> reports (http://www.ietf.org/mail-archive/web/tls/current/msg05593.html) that their
> tests show 95% success with TLS-only approaches as compared to 67% with
> HTTP approaches. This argues that people who want to be successful will choose
> to run WebSockets over TLS.
> 
> OK, you say, so what's the harm in specifying HTTP and HTTPS versions. I see
> two arguments against this:
> 
> (1) It just increases the attack surface.
> (2) It means that we're forced to design things into this protocol that we could get
> from TLS.
> 
> Exhibit A for the second argument is of course NPN or something like it. Currently,
> we're forced to design a handshake that ensures that the client and server are
> both speaking Websockets; this is necessarily a bit hacky and likely to either 
> make the proxy problem worse (encryption) or cost us a round trip (MAC handshake).
> By contrast, if we're really using TLS, then we can just build this mechanism into
> TLS without paying any penalty.
> 
> I just want to get ahead of one possible objection to this line of reasoning: that
> there is a performance penalty for TLS. Even if you don't find the arguments that
> TLS perf isn't an issue convincing (http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html),
> and FWIW I do, if, as I argue, you're going to pay that cost anyway, then our
> goal should be to minimize the cost of the combined system, and that is easiest
> to do if we simply assume TLS all the time.
> 
> -Ekr
> 
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi


--
Mark Nottingham     http://www.mnot.net/