Re: [hybi] On TLS-only Approaches

There are downsides from the pure TLS approach, which we've not yet figured
out how to overcome on the SPDY side.
It boils down to ensuring that schools and other institutions can *easily*
perform MITM monitoring/censoring.
We may already be facing these problems as we deploy a new protocol which
their proxies don't understand.

If we allowed/configured the NULL cipher for TLS, then MITM proxies could
still monitor, if perhaps not censor, but you're asking for trouble there.

-=R

On Sun, Aug 22, 2010 at 12:45 PM, Eric Rescorla <ekr@rtfm.com> 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
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>