[hybi] On TLS-only Approaches

[Eric Rescorla <ekr at rtfm.com>]

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