[hybi] On TLS-only Approaches

[Eric Rescorla <[e-mail]>]

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