Subject: [hybi] Flexibility should be a design consideration

From: Bruce Atherton <[email-masked]>
Date: Wed, 22 Dec 2010 18:02:04 -0800

I am mightily troubled by some of the conversations recently around 
masking. There are two topics that have me worried: whether masking is a 
scalability issue because it is client -> server, and whether masking 
should be allowed to be optional or replaceable with a new masking 
scheme. What worries me is the attitude I am seeing that unless someone 
can imagine a scenario that is usable right now today, all consideration 
of it should be stomped out of the specification.

Flexibility should be a design goal. Not the most important one, of 
course, but an important one none-the-less. Security should not be 
sacrificed for flexibility, but it is should be a little more important 
than simplicity. By that I mean that if getting flexibility in the 
specification requires a slight increase in complexity it is worth it, 
but for a lot of complexity it probably is not.

What do web portals look like in a world with web sockets? I don't know. 
What do mashups look like? I don't know. Servers interacting with other 
servers through REST APIs when the target server uses websockets as 
well? I don't know. Will websockets be applied to other problem domains, 
for example communicating between nodes in a cluster? I don't know. What 
kind of limitations will devices that run websockets have, including 
browsers, 10 years from now. I don't know. Will there be better options 
for masking in that time? I don't know. Will there be appliances that 
aggregate websockets? I don't know.

Neither, I suspect, do you. Making predictions is hard, especially about 
the future.

But just because we have a failure of imagination about how websockets 
may be used, doors are being shut. Because we have a fixed notion about 
what constitutes a "client", doors are being shut. There seems to be a 
will to bake the masking method directly into the specification, which 
is only going to cause problems for people who have different 
requirements than the current batch of web browser developers. Operating 
in an environment where you need more security than the default masking 
offers? Too bad for you. Are you in a trusted environment where 
scalability is the single most important issue? No websockets for you. 
Different problems require different tradeoffs, and the intent seems to 
be to handcuff the user of the specification so there are no options 
whatsoever. Having been on the receiving end of specifications like 
that, I can tell you that your users will not thank you for it.

A claim has been made that it is simpler to require only allowing a 
single masking option, but I think that is demonstrably false. Let us 
say that every web browser uses the same masking strategy. Then servers 
that only intend to interact with web browsers have to implement only 
that strategy. Since extensions are already planned for the protocol, 
there is no cost involved in specifying that strategy as the default. It 
is only if it turns out to be useful to have more than one strategy that 
clients will appear for it and servers will support it, in which case 
the fact that the design allows for that case is only a good thing.

So what I see is that a modification to the protocol that makes it more 
flexible with no discernible cost, not even in complexity, is being 
turned down because flexibility is not being recognized as an important 
design consideration when creating a protocol that will hopefully stand 
the test of time. I ask you to reconsider that position, and to try to 
keep an open mind about making this protocol as useful as possible for 
innovators. To me, one aspect of a well designed protocol is that it 
ends up being used in situations that surprise its designers.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 23 Dec 2010 11:39:20 +0100

Bruce

I couldn't agree more.

I think one of the issues of this WG is that the various
constituencies are not very accepting of the use-cases and concerns of
other constituencies.     It is never going to be possible to find the
one true solution that is going to satisfy all constituencies, so
instead perhaps we can use a bit of flexibility so that all parties
can look at the protocol and think - "I can use this", even if their
usages vary somewhat from others.

The main thing is that if at all possible, any concerns that relate to
only 1 constituency should not impose undue burdens on the others (no
taxation without representation!).   So if mobile clients and/or data
centres want to have no masking overheads, this should not force the
browsers to have to support that mode if they feel that it is insecure
for them.   Conversely, the security concerns of browsers are not
applicable to all clients nor all environments, so the burden should
not be imposed on non browser based usages, unless they are
communicated directly with browsers.

Having a base protocol that is flexible will allow it to adapt to many
circumstances.   But the capability of flexibility does not mean that
any constituency must expose that flexibility to their users.
Flexibility may be restricted by specific deployments (eg in a
browser).

cheers

---

From: John Tamplin <[email-masked]>
Date: Thu, 23 Dec 2010 10:16:52 -0500

On Wed, Dec 22, 2010 at 9:02 PM, Bruce Atherton <[email-masked]> wrote:

> scalability issue because it is client -> server, and whether masking should
> be allowed to be optional or replaceable with a new masking scheme. What
> worries me is the attitude I am seeing that unless someone can imagine a
> scenario that is usable right now today, all consideration of it should be
> stomped out of the specification.
>

We have the ability to negotiate extensions during the handshake, and those
extensions could change the framing, including the presence or type of
masking.

> Flexibility should be a design goal. Not the most important one, of course,
> but an important one none-the-less. Security should not be sacrificed for
> flexibility, but it is should be a little more important than simplicity. By
> that I mean that if getting flexibility in the specification requires a
> slight increase in complexity it is worth it, but for a lot of complexity it
> probably is not.
>

What flexibility do you think should be present that is not available by the
extension mechanism?

> But just because we have a failure of imagination about how websockets may
> be used, doors are being shut. Because we have a fixed notion about what
> constitutes a "client", doors are being shut. There seems to be a will to
> bake the masking method directly into the specification, which is only going
> to cause problems for people who have different requirements than the
> current batch of web browser developers. Operating in an environment where
> you need more security than the default masking offers? Too bad for you. Are
> you in a trusted environment where scalability is the single most important
> issue? No websockets for you. Different problems require different
> tradeoffs, and the intent seems to be to handcuff the user of the
> specification so there are no options whatsoever. Having been on the
> receiving end of specifications like that, I can tell you that your users
> will not thank you for it.
>

Again, an extension can be defined to change it.  Masking is not intended to
provide any security at all -- only preventing attacker-controlled bytes
from confusing transparent intermediaries.  If you do want security, there
is WSS, which is over SSL.

If you are in an environment where you control both ends of the connection
yet want to use WebSockets, you an define and use a private-use extension
and do what you want with it.  Or you can use whatever makes sense within
your private network -- for example, Google will terminate WebSockets at the
frontends, and use something different internally that better matches our
existing infrastructure.

> A claim has been made that it is simpler to require only allowing a single
> masking option, but I think that is demonstrably false. Let us say that
> every web browser uses the same masking strategy. Then servers that only
> intend to interact with web browsers have to implement only that strategy.
> Since extensions are already planned for the protocol, there is no cost
> involved in specifying that strategy as the default. It is only if it turns
> out to be useful to have more than one strategy that clients will appear for
> it and servers will support it, in which case the fact that the design
> allows for that case is only a good thing.
>

What you want is what is being proposed.  The XOR C->S masking is the
default.  If an extension is negotiated that defines something else, then
that happens instead.

> flexible with no discernible cost, not even in complexity, is being turned
> down because flexibility is not being recognized as an important design
> consideration when creating a protocol that will hopefully stand the test of
> time. I ask you to reconsider that position, and to try to keep an open mind
> about making this protocol as useful as possible for innovators. To me, one
> aspect of a well designed protocol is that it ends up being used in
> situations that surprise its designers.
>

What suggested modification has been turned down?

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

---

From: Bruce Atherton <[email-masked]>
Date: Thu, 23 Dec 2010 19:23:10 -0800

> extensions could change the framing, including the presence or type of

Huh? When Greg suggested treating masking as an extension, the general 
reaction was "I don't see the point." As a result, the straw poll 
suggested that masking be mandatory. When you and Willy suggested there 
could be a "don't mask" extension, that was met without outright rejection.

> What flexibility do you think should be present that is not available by the

I think we are talking past each other. I think the extension mechanism 
is great. What worries me is the attitude we are seeing where, unless a 
suggested enhancement matches with the needs someone has right now, it 
is rejected out of hand. There are far too many "I don't see the point" 
messages. Unless there is a cogent argument against a  change, the fact 
that someone doesn't see a benefit should not be allowed to trump the 
fact that others do.

If someone don't see the point of some change that offers a bit of 
flexibility, but it wouldn't cost anything to allow it, then allow it. 
Nobody is omniscient, and the feature you allow may just end up 
revolutionizing the world.

> is WSS, which is over SSL.

Why? Why can't I have a highly secure low impact masking rather than 
paying the price of full blown SSL? Why does it harm you to let me have 
the ability to make my own tradeoffs when I am operating completely 
within my own controlled environment?

The issue isn't security anyway. It is about allowing options for the 
user wherever it is sensible so long as it doesn't cause other problems. 
Maybe I want to use a new masking that is developed 5 years from now 
because it is much more efficient. Maybe I want to use one that is far 
easier on the battery for the websocket client in my credit card. Maybe 
some other reason I can't even imagine now. What business is it of 
yours? There is no downside to allowing users to have control of the 
masking strategy so long as the default one is the only one that clients 
and servers are required by the specification to provide and all web 
browsers use that one.

I realize that you are saying you think those options are already 
available through extensions, but that isn't what I am seeing happening 
on this mailing list. If the specification ends up declaring a single 
masking strategy as mandatory in all situations, then websocket-aware 
equipment will create all kinds of problems for anyone that tries to 
create a websockets client and server with a No-Masking extension.

> frontends, and use something different internally that better matches our

Not everyone has the luxury of controlling their environment to that 
extent. I sell into premises controlled by my customers, not me.

> default.  If an extension is negotiated that defines something else, then

I hope that is true, but it isn't what I see happening. I find lines 
like "I could not live with optional masking" somewhat discouraging.

Here is the kind of hell I foresee for myself because of arbitrary 
restrictions like this. Please please please don't anyone argue about 
the specific example. I can come up with dozens more, and even if I 
couldn't that wouldn't invalidate the argument, it would just indicate I 
am not sufficiently imaginative.

10 years from now I am working for a company that wants to take web 
applications running on a number of servers on their protected internal 
network and offer a portal service to their employees. The portal needs 
to handle 1000 concurrent sessions and provides panes from 6 
applications on average, each of which uses 1 websocket channel per 
session. This server thus has to act as a websocket client for 6000 
concurrent channels that it aggregates into 1000.

The mandatory masking reduces throughput by n. Thus, hardware costs are 
multiplied by at least n and perhaps more. Eventually the costs are high 
enough that I am ordered to write a new websocket-like protocol that 
doesn't have the burden of the utterly useless masking, useless because 
all the servers are running in a trusted environment. I write a NoMask 
extension and patch all my websocket libraries on all the servers to 
allow this variation (hopefully I have been smart enough to stick to 
open source). I also make a note to myself to remember to reapply the 
patch if any of my libraries get upgraded. Then I start working through 
all the bugs that flow in when websocket-aware equipment either rejects 
connections outright, allows it through but exhibits unexpected 
behaviour like logging failures due to malformed websocket frames, or 
works as expected until some unimaginable edge case causes an 
incomprehensible situation to develop. As I am working through these 
bugs trying to hack my way through the infrastructure, I am cursing each 
and every member of the hybi specification team for making my life so 
miserable for no reason whatsoever.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 24 Dec 2010 08:56:57 +0100

On 24 December 2010 04:23, Bruce Atherton <[email-masked]> wrote:
> network and offer a portal service to their employees. The portal needs to
> handle 1000 concurrent sessions and provides panes from 6 applications on
> average, each of which uses 1 websocket channel per session. This server
> thus has to act as a websocket client for 6000 concurrent channels that it
> aggregates into 1000.

It is worse than that!    Unfortunately for you, the Big Barracuda WS
routing box bought by your IT department, like many others,
implemented mandatory masking.  As as result, this nobled the
extension mechanism and prevented the development of any MUX
extensions.   So you actually have 6000 concurrent connections and no
aggregation.

---

From: John Tamplin <[email-masked]>
Date: Fri, 24 Dec 2010 09:05:12 -0500

> extensions.   So you actually have 6000 concurrent connections and no

Masking has nothing to do with this problem -- even if there were no
masking, any hardware appliance is not going to know about a MUX
extension created after it was.  The only answer is that it would have
to be upgraded to support new extensions, and the incentive for doing
so has to be the new capabilities offered by the extension.  In this
case, I would think a WS frontend box would be highly interested in
supporting MUX once that extension is standardized.

---

From: John Tamplin <[email-masked]>
Date: Fri, 24 Dec 2010 09:18:21 -0500

On Thu, Dec 23, 2010 at 10:23 PM, Bruce Atherton <[email-masked]> wrote:
> reaction was "I don't see the point." As a result, the straw poll suggested
> that masking be mandatory. When you and Willy suggested there could be a
> "don't mask" extension, that was met without outright rejection.

Clearly today there is aversion to allowing masking to be disabled,
precisely because of the reason we are considering adding masking
anyway which is there are transparent intermediaries that could be
confused by attacker-controlled data.  If at some point there is no
longer a need for masking because those intermediaries no longer exist
in sufficient numbers to justify it, then I don't think there would be
problem getting consensus on an extension to remove the masking
requirement.

> The issue isn't security anyway. It is about allowing options for the user
> wherever it is sensible so long as it doesn't cause other problems. Maybe I
> want to use a new masking that is developed 5 years from now because it is
> much more efficient. Maybe I want to use one that is far easier on the
> battery for the websocket client in my credit card. Maybe some other reason
> I can't even imagine now. What business is it of yours? There is no downside
> to allowing users to have control of the masking strategy so long as the
> default one is the only one that clients and servers are required by the
> specification to provide and all web browsers use that one.
>
> I realize that you are saying you think those options are already available
> through extensions, but that isn't what I am seeing happening on this
> mailing list. If the specification ends up declaring a single masking
> strategy as mandatory in all situations, then websocket-aware equipment will
> create all kinds of problems for anyone that tries to create a websockets
> client and server with a No-Masking extension.

Even if the masking were defined as an extension, and you chose to
implement a different masking with a different extension, I don't see
how that changes intermediaries that need
to unmask the content.  If they don't know about your extension, they
won't be able to
do it.  That would be no different if the proposed masking was defined
as the standard
without an extension.  The only solution that avoids that problem is
to define the alternate
masking algorithm (which might be none) into the initial spec.

> I hope that is true, but it isn't what I see happening. I find lines like "I
> could not live with optional masking" somewhat discouraging.

As mentioned above, that is due to issues on today's internet.  If
tomorrow's internet is different regarding the reasons for having
masking, then I am confident those opinions will change with it.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 24 Dec 2010 09:40:05 -0500

On 12/24/10 2:56 AM, Greg Wilkins wrote:
> extension mechanism
-1

Undoing the masking to see the ws-frame does not prevent the deployment 
of extensions. I think you massively overstate your case.

---

From: Bruce Atherton <[email-masked]>
Date: Sun, 26 Dec 2010 13:29:37 -0800

On 24/12/2010 6:18 AM, John Tamplin wrote:
> On Thu, Dec 23, 2010 at 10:23 PM, Bruce Atherton<[email-masked]>  wrote:

Again, we seem to be talking at cross purposes. I am not talking about 
the open internet. I am talking about environments where a developer 
knows a lot more about their situation than anyone on this list does, 
and needs the tools to work with it.

The notion that somehow, just because the specification acknowledges 
that alternate masking strategies could be used, that insecure websocket 
servers are going to pop up all over the place strikes me as unlikely in 
the extreme, and the price you want that developer to pay for the 
extremely low risk is way too high.

I can best compare it to a hypothetical security expert on the original 
HTTP specification list insisting that the server ultimately serving up 
the resource can only receive exactly the URL requested by the client, 
because otherwise URLs may be rewritten all over the web 
higgledy-piggledy and users would never know what they were getting. 
Just because it is possible to rewrite URLs doesn't mean anybody is 
going to do so without a good reason. And it is difficult to know just 
how reduced the web would have been in capability if we hadn't had the 
tool of being able to modify URLs as needed.

I also think you highly underestimate how difficult it will be to expand 
upon a single mandatory masking from the protocol once it is published. 
Not just because of the difficulty in convincing people that  it is now 
safe to do so, but also because when people assume that there will be a 
single masking that is always present, it will inform decisions they 
make in other portions of the specification.

> masking algorithm (which might be none) into the initial spec.

I do not believe this to be true at all. Certainly a lot of equipment 
will only have the default masking. I wouldn't expect home routers, for 
example, to offer any options in masking when dealing with web sockets 
other than those required to support whatever web browsers used (which 
presumably will just be the default).

But in other environments where it is more likely that control of both 
the client and the server is available, if it turns out there is a need 
for other masking strategies, de facto standards for extensions will 
emerge. Perhaps appliances will allow enabling support for an AES-CTR 
masking extension as a configurable option rather than just the default 
XOR, or for a null masking extension.

If the specification rules that there can be only one-true-masking, the 
one-size-fits-all that the protocol specification team has decided that 
they know best will work for everyone, then those de facto standards 
will be prevented from existing.

---

From: Bruce Atherton <[email-masked]>
Date: Sun, 26 Dec 2010 13:44:03 -0800

On 24/12/2010 6:40 AM, Patrick McManus wrote:
>
> Undoing the masking to see the ws-frame does not prevent the 
> deployment of extensions. I think you massively overstate your case.
>

Leaving aside your specific argument, I thought I'd point out that it is 
not possible to overstate, understate, or exactly state the case. This 
story is made up. Web portals may not even exist. None of us know what 
that future environment is going to look like. The only one who does is 
that guy in the future. And all I am saying is that you need to show 
that guy some kindness by giving him or her as many tools as possible to 
deal with that environment.

It may turn out that alternate masking schemes are never necessary. If 
so, great. There will never be a need to use that flexibility, and all 
implementations will only ever use a single masking strategy. But the 
more tools you can offer future guy, the more likely it is that at least 
some of the tools will prove to be useful.

Remember, none of you know where you will be 10 years from now. Future 
guy just might be you.

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 27 Dec 2010 22:49:44 +0100

On 24 December 2010 15:18, John Tamplin <[email-masked]> wrote:

> confused by attacker-controlled data.

There is a big difference between allowing masking to be disabled and
having a design that will ensure that it will be forever impossible to
disable or change masking.

>If at some point there is no

But the problem will be that a whole new generation of intermediaries
will have been written that do smart stuff with WS frames.   Most of
these intermediaries don't do anything with the content of the frames,
but have been forced to implement a specific masking algorithm because
we decided to mask the framing.  Thus even though consensus is reached
that masking is not longer necessary, we are unable to turn if off
because of the deployed intermediaries that were written with non
optional masking of WS frames.

cheers

---

From: Patrick McManus <[email-masked]>
Date: Mon, 27 Dec 2010 17:16:06 -0500

The masking does effectively become part of the framing. I agree with 
that - but you are arguing that unmasking is such a big deal that it 
will prevent intermediaries from doing the unmask in order to access the 
old framing. It won't because xor is a trivial cost.

I believe that the masking is probably not required for my preferred 
design, but the cost of it is so reasonable that I am happy to 
compromise with the folks who have considered opinions that believe it 
should always be on. This is a very small price to pay to deploy this 
protocol - the difference in processing complexity between (loading into 
processor cache, making a decision based on some piece of framing) and 
(loading in processor cache, xor that cache, and making a decision based 
on some piece of framing) is probably not even measurable. Dragging the 
data out of RAM is certainly more taxing than the xor.

Similarly, we have included binary lengths in network byte order even 
though the majority of processors using them will need to swap the byte 
order. I think it would be better the other way, but doing it the 
traditional way is all OK by me because it just doesn't matter very 
much. Just as I can sleep ok at night knowing all those bswap operations 
are going on, some extra XORs won't keep me up either. I understand that 
we all have our different thresholds for acceptable extra complexity 
(e.g. I would have to do some real soul searching around mandatory TLS), 
but this is about as cheap as it gets.

It is time to move on.

On 12/27/10 4:49 PM, Greg Wilkins wrote:
> On 24 December 2010 15:18, John Tamplin<[email-masked]>  wrote:
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 28 Dec 2010 09:47:30 +0100

On 27 December 2010 23:16, Patrick McManus <[email-masked]> wrote:
> The masking does effectively become part of the framing.

So this is a thread about flexibility.  So if masking becomes part of
the framing, then it is clear that such a design has less flexibility.

The implementation of XOR will need to be built into the framing state
machine, otherwise framing boundaries can not be seen.   This gives us
asymmetric implementations of framing with inbound and outbound flows
having different state machines.

Nobody has given a technical reason to not just mask the payloads?
why not?    Is the only objection that this gives us the flexibility
to have optional or alternate masking?   that is a pretty poor reason.

regards

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Dec 2010 03:33:48 -0800

> to have optional or alternate masking?   that is a pretty poor reason.

Really? I thought at least one person mentioned that they were worried about
the attacker controlling extensions. Regardless, I think that's clearly a
technical
reason.

-Ekr