Subject: [hybi] On TLS-only Approaches

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Aug 2010 12:45:58 -0700

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

---

From: Roberto Peon <[email-masked]>
Date: Sun, 22 Aug 2010 12:49:41 -0700

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 <[email-masked]> wrote:

> there is a performance penalty for TLS. Even if you don't find the
> arguments that
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: John Tamplin <[email-masked]>
Date: Sun, 22 Aug 2010 16:10:26 -0400

> to do if we simply assume TLS all the time.

We have people complaining about the complexity of doing an extra comparison
to interpret the length of a frame -- it seems to me that requiring a TLS
implementation is unacceptable.  Think about all the small embedded devices
which run a web server on very underpowered machines -- should they all be
required to implement TLS?

I think there is room for multiple connection establishment / handshake /
outer framing schemes, and I am fine with TLS being one of them, but I don't
think it can be required.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Adam Barth <[email-masked]>
Date: Sun, 22 Aug 2010 13:44:33 -0700

> perform MITM monitoring/censoring.

Hum...  I'm not sure we should kowtow to proponents of censorship.

> still monitor, if perhaps not censor, but you're asking for trouble there.

See below.

> required to implement TLS?

At the least, we'll probably want to offer a version that doesn't
check the server's certificate so folks can use the protocol without
paying for a CA-validated certificate.  If embedded performance today
is important, we can certainly consider offering a simple ciphersuite
with this version (e.g., RC4).

Adam

---

From: John Tamplin <[email-masked]>
Date: Sun, 22 Aug 2010 16:52:05 -0400

> Hum...  I'm not sure we should kowtow to proponents of censorship.

The alternative is they will simply block something they can't inspect,
which doesn't help much either.

---

From: Adam Barth <[email-masked]>
Date: Sun, 22 Aug 2010 15:05:12 -0700

> which doesn't help much either.

Even if half the world's networks are totalitarian censors, you'll
still get a higher connection rate with the TLS-based handshake.  Put
another way, the broken intermediaries in the world are much more
effective at blocking the non-TLS-based handshake than censors ever
will be at blocking the TLS-based handshake.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Aug 2010 08:06:28 +1000

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
> HTTP approaches. This argues that people who want to be successful will choose
> (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
> 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

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

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 22 Aug 2010 20:38:49 -0700

I agree with these sentiments. If the non-TLS approach is not practically deployable on the Internet (and it appears it's not), then including the non-TLS solution just needlessly increases attack surface.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 22 Aug 2010 20:47:40 -0700

On Aug 22, 2010, at 1:10 PM, John Tamplin wrote:

> 
> We have people complaining about the complexity of doing an extra comparison to interpret the length of a frame -- it seems to me that requiring a TLS implementation is unacceptable.  Think about all the small embedded devices which run a web server on very underpowered machines -- should they all be required to implement TLS? 

1) Would such devices be likely to offer WebSocket services? That doesn't seem likely to me, given my knowledge of the typical uses for this sort of thing (embedded Web-based configuration interface).

2) Even the very underpowered hardware in embedded devices is rapidly getting more powerful. I don't think TLS is unreasonable in terms of computational cost for future embedded services.

3) I would guess the challenge for embedded devices that *do* want to provide WebSocket services is that they can't practically ship with a valid certificate. To address this without creating security holes, we would likely need two URI schemes (ws: and wss:) with two different NPN protocol identifiers. ws: would not require a valid cert, wss: would. The reason two different NPN protocol identifiers are required is to prevent man-in-the-middle attacks against wss: services accessed using ws: by making it impossible to access them via ws:.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 22 Aug 2010 21:03:46 -0700

> 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 blo…

Do we have any past success stories along these lines? i.e. a new protocol using a new port is developed, clients and servers start using it despite the high rate of failure, and subsequently administrators change their firewalls so that it commonly works. 

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

OK, let's try a game theoretic model. Here are some assumptions about the three players:

=> The goal for browser vendors (Player B) is to provide features that Web services developers want to use.
   => Corollary: Browser vendors are unlikely to ship features that cannot or will not be used by Web service providers.

=> The goal for those deploying Web services (Player S) is to provide the benefit to their users - preferably greater benefit to a greater number of users.
   => Corollary: Deployers of Web services are often unwilling to use any feature that lacks very wide reach to their audience, or is otherwise unreliable.

=> The goal for network administrators (Player N) is to protect their organization from unknown threats while at the same time enabling their users to access sufficiently important services.
   => Corollary: Most network administrators will not allow access to additional services

Player B to move first. Player S to move second. I claim the optimal move is to enable deployment over existing unblocked ports (which in practice means 80 or 443). Can you give a game theoretic argument for why "use a new port" is a better move? I think you have shown that it might not be a complete failure, but I don't see how it improves outcomes for Player S or Player B. It may be worse for Player N, but it's not his move. With high probability, he won't respond with "block all port 443 traffic".

Regards,
Maciej

---

From: John Tamplin <[email-masked]>
Date: Mon, 23 Aug 2010 00:05:22 -0400

On Sun, Aug 22, 2010 at 11:47 PM, Maciej Stachowiak <[email-masked]> wrote:

> 1) Would such devices be likely to offer WebSocket services? That doesn't
> seem likely to me, given my knowledge of the typical uses for this sort of
> thing (embedded Web-based configuration interface).
>

They currently offer AJAX web pages, so I would not be surprised if they
would.

> 2) Even the very underpowered hardware in embedded devices is rapidly
> getting more powerful. I don't think TLS is unreasonable in terms of
> computational cost for future embedded services.
>

I am thinking code size is a problem, especially if you mandate any
base cipher set, as well as the computation required for low-end devices to
run RSA.

> 3) I would guess the challenge for embedded devices that *do* want to
> provide WebSocket services is that they can't practically ship with a valid
> certificate. To address this without creating security holes, we would
> likely need two URI schemes (ws: and wss:) with two different NPN protocol
> identifiers. ws: would not require a valid cert, wss: would. The reason two
> different NPN protocol identifiers are required is to prevent
> man-in-the-middle attacks against wss: services accessed using ws: by making
> it impossible to access them via ws:.
>

Another related question:  as I understand it, TLS has some fairly
significant per-message overhead, on the order of 5 bytes per record, plus
the overhead for the encryption algorithm.  For AES128 CBC with SHA1, you
have a 20 byte hash plus padding up to 16 byte multiples, so that means
small frames will be enormously inefficient under TLS.  For example, we have
just been arguing for a handful of bytes in the framing, and this would
immediately use a minimum of 25 extra bytes per frame.   By the time you
count uncompressed TCP/IP headers and WS framing, we have used more than
half of the bytes in a low-power FACH frame for mobile devices (depending on
the carrier configuration about 128-256 bytes).

Unless there is some lower overhead option, it doesn't seem like that can be
mandated for all WebSocket connections.

---

From: Adam Barth <[email-masked]>
Date: Sun, 22 Aug 2010 21:06:14 -0700

> it impossible to access them via ws:.

Yeah, I agree that we'll probably still want two security levels, one
that resists active network attackers and one that doesn't.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sun, 22 Aug 2010 21:13:13 -0700

> mandated for all WebSocket connections.

I should probably let EKR respond here, but I'll ask anyway.  What
does the message overhead look like for the null cipher spec?  We
don't necessarily need to use a non-null cipher spec for ws even if we
use a TLS handshake (of course, we need a reasonable cipher spec for
wss).

Adam

---

From: John Tamplin <[email-masked]>
Date: Mon, 23 Aug 2010 00:30:06 -0400

> use a TLS handshake (of course, we need a reasonable cipher spec for

It looks to me, according to openssl ciphers, the only NULL cipher supported
is AECDH-NULL-SHA which still does SHA1 for integrity protection, so I
assume it would have the same overhead.  RFC4346 seems to indicate a
TLS_NULL_WITH_NULL_NULL CipherSuite option which would have a 0-byte MAC, so
presumably you would only pay the 5-byte record overhead and there would be
no padding.  That is more reasonable, but still seems large considering we
have been arguing over a few bytes in the framing.

---

From: Adam Barth <[email-masked]>
Date: Sun, 22 Aug 2010 21:35:01 -0700

> have been arguing over a few bytes in the framing.

It's unclear to me whether those arguments have been reasonable, but
that's another discussion.  :)

I suppose another direction to explore is whether we can use the TLS
handshake and then drop the tunnel afterwards in the ws case.  Some of
our resident TLS experts might know.  I'd have to study the protocol
to see how that might work.

Adam

---

From: Mike Belshe <[email-masked]>
Date: Sun, 22 Aug 2010 21:31:22 -0700

> to do if we simply assume TLS all the time.

Eric -

I also like the TLS-based approach.  You've summed up the deployment
benefits well.

The "obvious benefits of encryption" should not be overlooked.  From the
end-user perspective, encryption is *always* better than no-encryption.  The
deployment benefits just make it more compelling.  Given the rise of
viruses, worms, and organized computer crime, we really shouldn't be
thinking about encryption as optional.

Mike

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Aug 2010 14:39:37 +1000

> Do we have any past success stories along these lines? i.e. a new protocol using a new port is developed, clients and servers start using it despite the high rate of failure, and subsequently admin…

HTTP
SIP
ssh
various forms of VPNs

See also the contents of /etc/services on most Unix-like systems.

> Player B to move first. Player S to move second. I claim the optimal move is to enable deployment over existing unblocked ports (which in practice means 80 or 443). Can you give a game theoretic ar…

Why do you need to use TLS over port 443, if this is just about making the protocol more widely adoptable?

Also, if it's as bleak as you paint it, how do you expect *any* of the new HTML5 features to get adoption? Never mind the network administrators -- if "those deploying Web services" are so conservative, why would they use the video tag, etc?

The answer to that (mostly) rhetorical question is the same as it is here; it's a gradual process; some Web sites will be more on the bleeding edge and either a) require their users to use relatively new browsers / "open" networks, or b) undertake fallback strategies for old browsers / closed ports. More conservative sites will follow later. 

AIUI in the various tests that have been undertaken, more than half of browsers *can* access services on new ports. Compared to deployed support for, say, the video tag, that's a great starting point. 

Finally, network administrators won't (often) block all port 443 traffic, but using it like this will encourage a market for devices that can intercept SSL/TLS. E.g.,
  http://www.bluecoat.com/node/2644
  https://www.microsoft.com/forefront/threat-management-gateway/en/us/features.aspx
  http://wiki.squid-cache.org/Features/SslBump
  http://www.collectivesoftware.com/Products/ClearTunnel

Cheers,

---

From: "Shelby Moore" <[email-masked]>
Date: Mon, 23 Aug 2010 09:21:07 -0400

>> Do we have any past success stories along these lines? i.e. a new
>> protocol using a new port is developed, clients and servers start using
>> it despite the high rate of failure, and subsequently administrators
>> change their firewalls so that it commonly works.
>
> HTTP
> SIP
> ssh
> various forms of VPNs
>

I read in this thread mostly bottom-up arguments about technology and very
little top-down game theory about what really matters.

Ultimately, success of anything depends on whether people need it, crave
it, want it, drool over it, and if there exists no other readily available
alternative which has less inertia against it.

We geeks need to remember that ultimately it is not about web services
developers, nor principles of technological perfection, it is about end
users:

http://www.ietf.org/mail-archive/web/hybi/current/msg03548.html

Tangential to my point above, if we want to enable the killer-application,
why are we refusing to enable 99% of the internet to use WebSockets:

http://www.ietf.org/mail-archive/web/hybi/current/msg03549.html

<truth-rant>And I am talking about the permutations of interconnections
that exist now, but are being wasted by we geeks who think we know
better.</truth-rant>

I see no reason that we can not support WebSockets over HTTP, HTTPS (TLS),
and also have a new port for WebSockets.

Why should we pick the winners and losers?  Let the market place decide. 
The more options we offer the market place, then the better chance we have
that our orthogonal effort on the WebSocket frames won't be wasted (i.e.
not maximized).

>>   => Corollary: Browser vendors are unlikely to ship features that
>> cannot or will not be used by Web service providers.
>>
>> => The goal for those deploying Web services (Player S) is to provide
>> the benefit to their users - preferably greater benefit to a greater
>> number of users.
>>   => Corollary: Deployers of Web services are often unwilling to use any
>> feature that lacks very wide reach to their audience, or is otherwise
>> unreliable.
>>
>> => The goal for network administrators (Player N) is to protect their
>> organization from unknown threats while at the same time enabling their
>> users to access sufficiently important services.
>> Player B to move first. Player S to move second. I claim the optimal
>> move is to enable deployment over existing unblocked ports (which in
>> practice means 80 or 443). Can you give a game theoretic argument for
>> why "use a new port" is a better move? I think you have shown that it
>> might not be a complete failure, but I don't see how it improves
>> outcomes for Player S or Player B. It may be worse for Player N, but
>> it's not his move. With high probability, he won't respond with "block
>> all port 443 traffic".
>
>
> Also, if it's as bleak as you paint it, how do you expect *any* of the new
> HTML5 features to get adoption? Never mind the network administrators --
> if "those deploying Web services" are so conservative, why would they use
> the video tag, etc?
>
> The answer to that (mostly) rhetorical question is the same as it is here;
> it's a gradual process; some Web sites will be more on the bleeding edge
> and either a) require their users to use relatively new browsers / "open"
> networks, or b) undertake fallback strategies for old browsers / closed
> ports. More conservative sites will follow later.
>
> AIUI in the various tests that have been undertaken, more than half of
> browsers *can* access services on new ports. Compared to deployed support
> for, say, the video tag, that's a great starting point.
>
> Finally, network administrators won't (often) block all port 443 traffic,
> but using it like this will encourage a market for devices that can
> intercept SSL/TLS. E.g.,

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Aug 2010 07:13:36 -0700

I think people are

> use a TLS handshake (of course, we need a reasonable cipher spec for
Choosing a message sort of arbitrarily to reply to here:

(1) I think Adam/Maciej are right that it would be desirable to offer a "use
TLS but don't
     expect the certificate to be OK" version.

(2) The host costs of TLS are generally pretty low.  In terms of code size,
< 100k is common.
     For instance, yaSSL claims 30-100k:
http://www.yassl.com/yaSSL/Products.html.
     I posted a link to AGL's writeup on the performance costs the other
day. I would note
     that it's been a long time since I've seen an embedded gizmo that did
HTTP but
     not HTTPS. Consider, for instance, that your average home wireless
gateway has a
     TLS stack for the management interface. I'd be interested in seeing
examples of
     embedded devices which are going to implement WS and do enough traffic
that
     TLS is going to be a big impact.

(3) The minimum wire overhead per TLS record (which of course may contain >1
WS
     frames if you buffer) is 5 bytes for the header. With the
truncated_hmac
     extension, you use a 10 byte MAC, getting the total down to 15 bytes.
TLS
     specifically forbids the negotiation of ciphers with neither
confidentiality nor
     integrity. I'm generally not real hot on the notion of negotiating TLS
and then
     "turning it off". At that point, why not just use RFC 2817 CONNECT and
send
     HTTP over it.

-Ekr

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 24 Aug 2010 00:18:04 +0200 (CEST)

On Mon, 23 Aug 2010, Mark Nottingham wrote:

> 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.

I find Mark's reasoning here very convincing. After all, its "just" TCP to a 
new port we're talking about...

I'm suddenly more open to actually switch to a non-HTTP-upgrade route.

-- 

  / daniel.haxx.se