Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt

From: "Len Holgate" <[email-masked]>
Date: Thu, 1 Sep 2011 08:23:45 +0100

Nit picking, but...

 4.2.1 step 6 should probably say "value of 13".

 Why doesn't 5.1 use MUST and MUST NOT when talking about client to server
and server to client masking. Up until now I was under the impression that
the server COULD mask data if it really wanted to (hence the need for the
masking bit rather than simply assuming that client -> server == masked and
server -> client != masked. The text in 5.1 now seems to imply that the
server SHOULD NOT mask but it doesn't say so. I realise that client ->
server masking is required and is specified with MUST in another part of the
document but I think it should be made clear that a server CAN mask if it
really wants to so that we don't end up with client implementations that
don't expect to receive masked frames. One situation where I might wish to
mask a frame from server to client would be in a pong where there's no need
for me to unmask the data if I simply echo the ping directly back...

Apart from that I think this draft addresses all of the issues that I
considered important and I like the additional text that explains why the
spec is as it is.

The result is a much better document than I was expecting when I first
started to take an interest around the time that draft 8 came out. Well done
everyone.

Len
http://www.lenholgate.com
http://www.serverframework.com

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Sep 2011 11:02:00 -0600

<hat type='AD'/>

On 8/31/11 12:49 PM, Peter Saint-Andre wrote:
> On 8/31/11 12:42 PM, [email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the BiDirectional or
>> Server-Initiated HTTP Working Group of the IETF.
>> 
>> Title           : The WebSocket protocol Author(s)       : Ian
>> Fette Alexey Melnikov Filename        :
>> draft-ietf-hybi-thewebsocketprotocol-13.txt Pages           : 73 
>> Date            : 2011-08-31
> 
> First, a big thank-you to Ian and Alexey for submitting -13 so
> quickly!
> 
> As far as we know, this version addresses all of the feedback and
> open issues resulting from the Working Group Last Call, and is ready
> for presentation to the IESG. The chairs will update the "proto
> writeup" tomorrow morning (European time) and then I will issue the
> IESG ballot, for consideration on the IESG telechat next Thursday.

FYI, I have issued the IESG ballot. During IESG review, the document
editors and document shepherd (the WG chairs) will receive email
messages containing comments provided by IESG members. They will use
their best judgment about communicating those comments to the WG for
further discussion (sometimes the comments are about small issues that
can be fixed by the editors without consulting the WG, whereas sometimes
the comments raise more significant issues and thus might require WG input).

Let me know if you have any questions about next steps.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 2 Sep 2011 13:45:00 +0200

2011/8/31 Julian Reschke <[email-masked]>:
> I don't see my comment regarding extension-param syntax resolved...

Good point. Still "implied *LWS" ghost is present.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 02 Sep 2011 12:58:50 +0100

>Good point. Still "implied *LWS" ghost is present.
I've offered to upgrade ABNF to RFC 5234-style, but our chairs and AD 
thought it was a bit too risky at this point. Something to do for 
WebSockets 1.1.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 2 Sep 2011 14:06:58 +0200

2011/9/2 Alexey Melnikov <[email-masked]>:
> thought it was a bit too risky at this point. Something to do for WebSockets
> 1.1.

Could I know why it would be too risky? It changes nothing and makes
implementation easier as it doesn't require the developer to check
"what implied *LWS is in RFC 2616". Current text forces the
implementator looking for "implied *LWS" concept in RFC 2616.

Honestly I don't understand the rationale to keep it.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 02 Sep 2011 13:11:26 +0100

>Honestly I don't understand the rationale to keep it.
Experience shows that it is too easy to introduce an error in a rush.
I've done such conversions before. I've also made mistake in a rush. So 
I have some sympathy to the argument made.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 2 Sep 2011 14:44:34 +0200

2011/9/2 Alexey Melnikov <[email-masked]>:
> I've done such conversions before. I've also made mistake in a rush. So I
> have some sympathy to the argument made.

The draft says twice:

-----------------
4.3.  Collected ABNF for new header fields used in handshake

   Unlike other section of the document this section is using ABNF
   syntax/rules from Section 2.1 of [RFC2616], including "implied *LWS
   rule".
-------------------

-------------------
9.1.  Negotiating Extensions

   A client requests extensions by including a "Sec-WebSocket-
   Extensions" header field, which follows the normal rules for HTTP
   header fields (see [RFC2616] section 4.2) and the value of the header
   field is defined by the following ABNF.  Note that unlike other
   section of the document this section is using ABNF syntax/rules from
   [RFC2616], including "implied *LWS rule".
--------------------

So where in the draft is supposed to use "normal" ABNF syntax/rules
(non including "implied *LWS") ?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Sep 2011 11:34:26 -0600

<hat type='AD'/>

On 9/2/11 6:11 AM, Alexey Melnikov wrote:
>>> WebSockets

Yes, the concern is that we might introduce bugs at the last minute.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 7 Sep 2011 14:55:44 +0900

>  4.2.1 step 6 should probably say "value of 13".

Yes, it's a bug.

> for me to unmask the data if I simply echo the ping directly back...

This is continuation of this thread. I think we should clarify this, i.e.
use MUST NOT or MAY here, or we'll see the same question repeatedly in the
future.
http://www.ietf.org/mail-archive/web/hybi/current/msg07768.html

If we allow the server to mask frames, clients need to implement logic for
unmasking to prepare for them. As we don't know any important use-case of
server-to-client masking, I think we should just forbid it.
OLD: All frames sent from the server to the client are not masked.
NEW: All frames sent from the server to the client MUST NOT be masked.

Let's also change
OLD: All frames sent from the client to the server are masked to avoid ...
NEW: All frames sent from the client to the server MUST be masked to avoid
...

Thanks,
Takeshi

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 7 Sep 2011 09:14:52 +0200

> NEW: All frames sent from the client to the server MUST be masked to avoid
Since the masking and unmasking are the same operations, I fail to
understand the added complexity of server-to-client masking. Clients already
know how to unmask since they can mask in the first place with the same
operation. In my mind you'll get more questions on the reason why it's one
way only as opposed to mask both ways. In fact the spec creates more
questions than it ought to when it suggests intermediaries may have problems
on client-to-server communication but not the other way around.

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 7 Sep 2011 09:30:55 +0200

On Wed, Sep 07, 2011 at 09:14:52AM +0200, Sylvain Hellegouarch wrote:
> operation.

Except they don't know the masking key. The purpose of masking is not
to prevent a *client* from emitting the data it wants, but to prevent
some *javascript code* running in a browser from doing so. The client
is not the issue here, the issue is the fact that the attacker on the
server side might easily make a client execute some controlled JS code.
We want to ensure that someone who's present at both ends cannot easily
control the byte stream sent by the client. And since the JS does not
know the key, there's no easy way to perform the operation backwards
first.

Regards,
Willy

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 7 Sep 2011 09:36:02 +0200

> know the key, there's no easy way to perform the operation backwards
I suggest section 5.1 to be clarified with that point then.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 7 Sep 2011 09:37:27 +0200

> I suggest section 5.1 to be clarified with that point then.
Never mind that, section 10.3 already does so.

---

From: "Len Holgate" <[email-masked]>
Date: Wed, 7 Sep 2011 08:38:50 +0100

> 	If we allow the server to mask frames, clients need to 
> implement logic for unmasking to prepare for them. As we 
> don't know any important use-case of server-to-client 
> masking, I think we should just forbid it.
> 	NEW: All frames sent from the client to the server MUST 
> be masked to avoid ...

That sounds good; well better than it being vague anyway. 

Now, of course, the masking bit in the header is pretty much redundant... 

Equally good would be:

OLD: All frames sent from the server to the client are not masked.
NEW: All frames sent from the server to the client CAN be masked but there's
no technical or security reason for them to be and so in most cases they
SHOULD NOT be masked.

Clients already have the code to mask/unmask, the logic isnt that complex...

Len

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 7 Sep 2011 16:58:21 +0900

Len, Sylvain,

Yes, it's not complicated, but needs to be tested, requires small but more
code to be maintained. I just prefer not having more code if there's no
necessity.

About the redundancy of masking bit, see the post by
John<http://www.ietf.org/mail-archive/web/hybi/current/msg07777.html>in
the thread I mentioned.

Thanks,

---

From: "Len Holgate" <[email-masked]>
Date: Wed, 7 Sep 2011 09:36:14 +0100

Fair enough.

So, will server to client masking become MUST NOT in the next draft? 

Len

> -----Original Message-----
> From: Takeshi Yoshino [mailto:[email-masked]] 
> Sent: 07 September 2011 08:58
> To: Len Holgate; [email-masked]
> Cc: [email-masked]
> Subject: Re: [hybi] I-D Action: 
> draft-ietf-hybi-thewebsocketprotocol-13.txt
> 
> Len, Sylvain,
> 
> Yes, it's not complicated, but needs to be tested, requires 
> small but more code to be maintained. I just prefer not 
> having more code if there's no necessity.
> 
> 
> About the redundancy of masking bit, see the post by John 
> <http://www.ietf.org/mail-archive/web/hybi/current/msg07777.ht
ml>  in the thread I mentioned.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 7 Sep 2011 10:51:28 +0200

> So, will server to client masking become MUST NOT in the next draft? 

Adding "MUST NOT" in a spec always causes issues in implementations
because the receivers expect that the case never happens and generally
don't handle the situation gracefully. Basically, the on-wire protocol
makes it possible to enable or disable masking so we don't need to put
specific conditions on the cases we're not interested in.

Regards,
Willy

---

From: "Len Holgate" <[email-masked]>
Date: Wed, 7 Sep 2011 09:52:38 +0100

In which case it should be MAY...

The current wording is broken and will lead to broken implementations.

Someone pick one or the other. 

> From: Willy Tarreau [mailto:[email-masked]] 
> Sent: 07 September 2011 09:51
> To: Len Holgate
> Cc: 'Takeshi Yoshino'; [email-masked]; [email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Sep 2011 05:56:28 -0600

<hat type='AD'/>

> know the key, there's no easy way to perform the operation backwards

That's a fine explanation, but it's not clear in Section 10.3, which
seems to focus on intermediaries. This has caused confusion for at least
one IESG member, who commented that masking ought to be MUST-implement
but MAY-enable (i.e., there are some environments in which the client
would not need to mask). Perhaps modifications to Section 10.3 are in
order...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 7 Sep 2011 08:14:13 -0400

Sorry if I'm missing something (I missed the beginning of the thread), but are there people out there who actually *want* masking from the server to the client?  The work by abarth, ekr, et al. showed a roughly 40% performance hit due to masking under some circumstances -- presumably adding s2c masking would degrade performance even further.

--Richard  

On Sep 7, 2011, at 3:38 AM, Len Holgate wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: "Len Holgate" <[email-masked]>
Date: Wed, 7 Sep 2011 13:21:12 +0100

No, but at present it's unclear and I don't care which way it goes as long
as it's clear whether servers CAN mask or MUST NOT mask. 

> From: Richard L. Barnes [mailto:[email-masked]] 
> Sent: 07 September 2011 13:14
> To: Len Holgate
> Cc: 'Takeshi Yoshino'; [email-masked]
> Sorry if I'm missing something (I missed the beginning of the 
> thread), but are there people out there who actually *want* 
> masking from the server to the client?  The work by abarth, 
> ekr, et al. showed a roughly 40% performance hit due to 
> masking under some circumstances -- presumably adding s2c 
> masking would degrade performance even further.
> 
> --Richard  
> 
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 7 Sep 2011 21:32:06 +0900

> makes it possible to enable or disable masking so we don't need to put

Yes. That's unexpected side-effect of addition of MASK bit. Without the
flag, there was no information in a frame if it's masked or not so client
just had to follow what the spec says. So, client never encountered such
situation.

But we don't have to keep it as legal frame just because it's possible.

> specific conditions on the cases we're not interested in.

We should make the spec clear on whether WebSocket client implementation
must be prepared for masked frame or not. I'm fine once it's clear.

Takeshi

---

From: "Len Holgate" <[email-masked]>
Date: Wed, 7 Sep 2011 13:42:07 +0100

> We should make the spec clear on whether WebSocket client 
> implementation must be prepared for masked frame or not. I'm 
> fine once it's clear.

Agree.

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 7 Sep 2011 06:31:26 -0700

> Sorry if I'm missing something (I missed the beginning of the thread), but are
> there people out there who actually *want* masking from the server to the
> client?  The work by abarth, ekr, et al. showed a roughly 40% performance hit

at least for the Python/Twisted implementation I can say that - even after
quite some optimization experiments - the masking is the bottleneck.

I've heard that for C/C++ it's (expected) not the case, and that for node.js/V8
it's also not (maybe due to the heavily JITting the V( performs).

> due to masking under some circumstances -- presumably adding s2c masking
> would degrade performance even further.

+1: s2c => MUST NOT mask

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 7 Sep 2011 22:44:59 +0900

>>  4.2.1 step 6 should probably say "value of 13".

Seems this is already fixed on Alexey's local copy. I just noticed the
thread, sorry.
http://www.ietf.org/mail-archive/web/hybi/current/msg08682.html

---

From: John Tamplin <[email-masked]>
Date: Wed, 7 Sep 2011 10:17:55 -0400

> But we don't have to keep it as legal frame just because it's possible.

I expect it will get used as a WS-variant when dealing with non-browser
clients -- ie, between a frontend which handles
masking/aggregation/deaggregation/SSL and the ultimate backend, I would not
be surprised if there were unmasked client->server frames.  As long as all
the browser clients all enforce masking on their connections, the problem
masking was added for is averted.

> must be prepared for masked frame or not. I'm fine once it's clear.

There really is no point -- the server controls both the mask and the
content, so they can arrange for any sequence on the wire regardless.  The
only case I can imagine where it might be useful is peer-to-peer WS
communication between browsers, and if we ever implement something like that
we can deal with masking then.

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

---

From: Joel Martin <[email-masked]>
Date: Wed, 7 Sep 2011 10:31:54 -0500

> quite some optimization experiments - the masking is the bottleneck.

I notice you are doing the unmasking directly using python code (
https://github.com/oberstet/Autobahn/blob/master/lib/python/autobahn/websocket.py#L635).
Have you tried doing the unmask by offloading it to something like numpy? If
not, you might try something like this:

    numpy.bitwise_xor(data, mask)

You'll need to handle modulus 4 data (since numpy.bitwise_xor wants the data
to be modulus the mask), but that's the general idea. Here is how I do it in
websockify:
https://github.com/kanaka/websockify/blob/6e263063c2b63642a0e17cb91d6b9f6c9365c0c0/websocket.py#L293
My main test is noVNC which doesn't send much data from client to
server,
but I think numpy will do the unmask significantly faster than doing the XOR
in python code directly.

Regards,

Joel Martin (kanaka)

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 7 Sep 2011 08:42:19 -0700

yes, it's plain Python, not over strings, but bytearrays, which gives some boost.

Compared to C/C++ the whole thingy is somewhere 3x slower worst-case .. not bad, but slower.

Using NumPy is a nice tip .. I'll have a look at your code.

I've been looking at

http://stackoverflow.com/questions/2119761/simple-python-challenge-fastest-bitwise-xor-on-data-buffers

also, but did not find time yet to see if it helps.

Thanks again,
Tobias

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Joel Martin
Gesendet: Mittwoch, 7. September 2011 17:32
An: Tobias Oberstein
Cc: Richard L. Barnes; Len Holgate; [email-masked]
Betreff: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt

On Wed, Sep 7, 2011 at 8:31 AM, Tobias Oberstein <[email-masked]<mailto:[email-masked]>> wrote:
at least for the Python/Twisted implementation I can say that - even after
quite some optimization experiments - the masking is the bottleneck.

I notice you are doing the unmasking directly using python code (https://github.com/oberstet/Autobahn/blob/master/lib/python/autobahn/websocket.py#L635). Have you tried doing the unmask by offloading it to something like numpy? If not, you might try something like this:

You'll need to handle modulus 4 data (since numpy.bitwise_xor wants the data to be modulus the mask), but that's the general idea. Here is how I do it in websockify: https://github.com/kanaka/websockify/blob/6e263063c2b63642a0e17cb91d6b9f6c9365c0c0/websocket.py#L293  My main test is noVNC which doesn't send much data from client to server, but I think numpy will do the unmask significantly faster than doing the XOR in python code directly.

Regards,

Joel Martin (kanaka)

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 7 Sep 2011 21:50:32 +0200

On Wed, Sep 7, 2011 at 5:42 PM, Tobias Oberstein <
[email-masked]> wrote:

> yes, it's plain Python, not over strings, but bytearrays, which gives some
> boost.****
>
> ** **
>
> Compared to C/C++ the whole thingy is somewhere 3x slower worst-case .. not
> bad, but slower.****
>
> ** **
>
> Using NumPy is a nice tip .. I'll have a look at your code.****
>
> ** **
>
> I've been looking at****
>
> ** **
>
>
> ****
> ** **
> also, but did not find time yet to see if it helps.****
>
> **
>

I can concur masking is the bottleneck in Python. I was making the mistake
to mask server to client communication which I've been corrected about
today. So I remove the masking from server to client and suddenly
performances increased dramatically for large payloads. In fact your tests
do pass now [1].

As to move to numpy, that adds a rather heavy dependency so hard to tell if
the trade-off would be worth it.

[1] http://www.defuze.org/oss/ws4py/testreports/servers/

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 7 Sep 2011 21:59:55 +0000

[chair hat off]

Notice also that one of the objections against masking was that it would complicate sendfile() scenarios. Since these are expected to be more common from server to the client, not masking in this direction was one of the selling points of the final solution adopted.

Since there are desirable benefits to not masking form server to client, and no real scenarios have been identified to do so in that direction, personally, I prefer to simplify: I like Takeshi-san's previous proposal, namely:

"

Let's also change
OLD: All frames sent from the client to the server are masked to avoid ...
NEW: All frames sent from the client to the server MUST be masked to avoid ...
"

From: [email-masked] [mailto:[email-masked]] On Behalf Of Takeshi Yoshino
Sent: 06 September, 2011 22:56
To: Len Holgate
Cc: [email-masked]
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt

On Thu, Sep 1, 2011 at 16:23, Len Holgate <[email-masked]<mailto:[email-masked]>> wrote:
 4.2.1 step 6 should probably say "value of 13".

Yes, it's a bug.

This is continuation of this thread. I think we should clarify this, i.e. use MUST NOT or MAY here, or we'll see the same question repeatedly in the future.
http://www.ietf.org/mail-archive/web/hybi/current/msg07768.html

If we allow the server to mask frames, clients need to implement logic for unmasking to prepare for them. As we don't know any important use-case of server-to-client masking, I think we should just forbid it.
OLD: All frames sent from the server to the client are not masked.
NEW: All frames sent from the server to the client MUST NOT be masked.

Let's also change
OLD: All frames sent from the client to the server are masked to avoid ...
NEW: All frames sent from the client to the server MUST be masked to avoid ...

Thanks,
Takeshi

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 8 Sep 2011 10:57:54 -0400

Keep in mind, though, that the server still has to *un-mask* the frames from the client, which has the same cost as masking.  So you don't eliminate the performance burden on the server by removing s2c masking.  Or, equivalently, the server gets a performance benefit if clients don't mask.

--Richard

On Sep 7, 2011, at 3:50 PM, Sylvain Hellegouarch wrote:

> 
> 
> On Wed, Sep 7, 2011 at 5:42 PM, Tobias Oberstein <[email-masked]> wrote:
> I can concur masking is the bottleneck in Python. I was making the mistake to mask server to client communication which I've been corrected about today. So I remove the masking from server to client and suddenly performances increased dramatically for large payloads. In fact your tests do pass now [1].
>  
> As to move to numpy, that adds a rather heavy dependency so hard to tell if the trade-off would be worth it.
> 
> -- 
> - Sylvain
> http://www.defuze.org

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 8 Sep 2011 11:06:19 -0400

[trimmed for brevity]

On Sep 7, 2011, at 10:17 AM, John Tamplin wrote:

> Yes. That's unexpected side-effect of addition of MASK bit. Without the flag, there was no information in a frame if it's masked or not so client just had to follow what the spec says. So, client never encountered such situation.

It should also be noted that if the MASK bit is eliminated, then the recipient of a frame can't even parse it in the current format, since it doesn't know whether the first four octets are a masking key or not.

> I expect it will get used as a WS-variant when dealing with non-browser clients -- ie, between a frontend which handles masking/aggregation/deaggregation/SSL and the ultimate backend, I would not be surprised if there were unmasked client->server frames.  As long as all the browser clients all enforce masking on their connections, the problem masking was added for is averted.

This seems to argue against Gabriel's proposed "c2s MUST / s2c MUST NOT".  Proposed alternative:

OLD: "All frames sent from the server to the client are not masked."
NEW: "Frames sent from the server to the client MAY be masked."

OLD: "All frames sent from the client to the server are masked to avoid ..."
NEW: "Frames sent from the client to the server SHOULD be to avoid ..."

NEW: "Servers MUST NOT reject un-masked frames, unless masking is required by local policy."

--Richard

---

From: John Tamplin <[email-masked]>
Date: Thu, 8 Sep 2011 11:14:53 -0400

On Thu, Sep 8, 2011 at 11:06 AM, Richard L. Barnes <[email-masked]> wrote:

> It should also be noted that if the MASK bit is eliminated, then the
> recipient of a frame can't even parse it in the current format, since it
> doesn't know whether the first four octets are a masking key or not.

No, you know which side initiated the connection, so you know whether it is
a client frame or a server frame, and therefore whether it is masked.

> This seems to argue against Gabriel's proposed "c2s MUST / s2c MUST NOT".

No, since it would have to be a variant -- they aren't speaking WebSocket at
that point but a close derivative.  When we first added masking, IIRC Maciej
and others strongly objected to allowing clients to not mask in the
standard, even with a requirement that clients executing potentially hostile
code must mask, so I doubt relaxing it now would be any more acceptable.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 8 Sep 2011 11:37:56 -0400

> No, since it would have to be a variant -- they aren't speaking WebSocket at that point but a close derivative.  When we first added masking, IIRC Maciej and others strongly objected to allowing clients to not mask in the standard, even with a requirement that clients executing potentially hostile code must mask, so I doubt relaxing it now would be any more acceptable.

I'm not disagreeing that applying masking is appropriate for the great majority of clients.  But as you pointed out, there are definite use cases for running WS without masking.  It seems silly to completely rule those things out of the spec, since they're probably going to share code anyway -- instead of a "masking" bit, they would just have a "WS compliant" bit.  Having the switch in the protocol is cheap.  The decision about whether to apply masking is an operational issue, not a protocol issue.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Sep 2011 10:14:46 -0600

> NEW: "Servers MUST NOT reject un-masked frames, unless masking is required by local policy."

Personally (not as your Area Director), that's fine with me.

As your Area Director, I'd appreciate feedback from WG participants so
that we can reach closure on this issue.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Sep 2011 17:21:24 +0100

>>NEW: "Frames sent from the client to the server SHOULD be to avoid ..."
I assume you've missed out "masked" after "SHOULD be".

>Personally (not as your Area Director), that's fine with me.
Personally (not as an editor), I am fine with this text as well.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 8 Sep 2011 12:22:06 -0400

> I assume you've missed out "masked" after "SHOULD be".

Yes.

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 8 Sep 2011 16:24:52 +0000

As chair, I note that the agreement regarding masking (client MUST mask to server) was one of the main points behind the VERY hard fought consensus. I think this is one of those things we can revisit in version 1.1, along with others we've been noting recently.

As an individual, the MAY mask on Server to client seems to gain nothing (I'm with John Tamplin on this one) and potentially lose something (sendfile), so I'd rather say MUST NOT here.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Peter Saint-Andre
> Sent: 08 September, 2011 09:15
> To: Richard L. Barnes
> Cc: [email-masked]
> >> Yes. That's unexpected side-effect of addition of MASK bit. Without the flag,
> there was no information in a frame if it's masked or not so client just had to
> follow what the spec says. So, client never encountered such situation.
> >
> > It should also be noted that if the MASK bit is eliminated, then the recipient of
> a frame can't even parse it in the current format, since it doesn't know whether
> the first four octets are a masking key or not.
> >
> >
> be surprised if there were unmasked client->server frames.  As long as all the
> browser clients all enforce masking on their connections, the problem masking
> was added for is averted.
> >
> Proposed alternative:

---

From: John Tamplin <[email-masked]>
Date: Thu, 8 Sep 2011 12:28:33 -0400

> that we can reach closure on this issue.

I don't object to changing this though I think previous discussions were
clear enough -- I wonder if all those who participated in the discussion at
that point will be around to restate their preferences.

If we do go with this, I would prefer an additional statement for
client->server, stating that if the client makes sends content controlled by
potentially hostile code over a WebSocket connection, it MUST mask the
contents.

I don't object strongly to changing server->client, but I think it is
totally silly to mask it as the server controls both the mask and the
content.  In fact, it may be a bit riskier, because the server could send
content that would be innocuous to something interpreting it as WebSocket
traffic, while the masked bytes are an attack against an intermediary.  So,
I would prefer to leave it as MUST NOT but if others feel strongly that
allowing it is useful I won't fight it.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 8 Sep 2011 12:31:06 -0400

> As chair, I note that the agreement regarding masking (client MUST mask to server) was one of the main points behind the VERY hard fought consensus. I think this is one of those things we can revis…

I think I understood that consensus slightly differently, more as a capability + operational practice than a protocol requirement.  Like I said to John, whatever the text says, masking will be appropriate in most cases.

> As an individual, the MAY mask on Server to client seems to gain nothing (I'm with John Tamplin on this one) and potentially lose something (sendfile), so I'd rather say MUST NOT here.

It doesn't rule out sendfile, since the server can choose not to apply masking.  All the proposed text does is clarify that the server has the choice (as it does in the current text).

--Richard

---

From: Joel Martin <[email-masked]>
Date: Thu, 8 Sep 2011 11:36:48 -0500

On Thu, Sep 8, 2011 at 11:24 AM, Gabriel Montenegro <
[email-masked]> wrote:

> As chair, I note that the agreement regarding masking (client MUST mask to
> server) was one of the main points behind the VERY hard fought consensus. I
> think this is one of those things we can revisit in version 1.1, along with
> others we've been noting recently.
>
> As an individual, the MAY mask on Server to client seems to gain nothing
> (I'm with John Tamplin on this one) and potentially lose something
> (sendfile), so I'd rather say MUST NOT here.

I concur. Client to server MUST mask. Server to client MUST NOT mask. Server
MUST fail unmasked messages from the client.

I would also be okay with adding a note indicating that in a future revision
of the spec, when WebSockets is used with clients that are running trusted
code (i.e. not browsers), the client may choose to not mask and the server
can accept unmasked frames. But I think this should only be a note to
indicate possible future direction.

Joel Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 8 Sep 2011 12:37:45 -0400

On Sep 8, 2011, at 12:28 PM, John Tamplin wrote:

> On Thu, Sep 8, 2011 at 12:14 PM, Peter Saint-Andre <[email-masked]> wrote:
> I don't object to changing this though I think previous discussions were clear enough -- I wonder if all those who participated in the discussion at that point will be around to restate their preferences.
> 
> If we do go with this, I would prefer an additional statement for client->server, stating that if the client makes sends content controlled by potentially hostile code over a WebSocket connection, it MUST mask the contents.

I don't think that statement is quite correct.  Masking may not be needed in some cases where hostile code is present; e.g., if there are no vulnerable intermediaries present.  And the requirement as you've stated it would require masking within the data center, since the SSL termination box would technically be sending content controlled by potentially hostile code.

The appropriate thing to do here, I think, is to document the situations where masking is necessary in the Security Considerations (probably 10.3) and have a strong RECOMMENDED for masking in those cases.

> I don't object strongly to changing server->client, but I think it is totally silly to mask it as the server controls both the mask and the content.  In fact, it may be a bit riskier, because the server could send content that would be innocuous to something interpreting it as WebSocket traffic, while the masked bytes are an attack against an intermediary.  So, I would prefer to leave it as MUST NOT but if others feel strongly that allowing it is useful I won't fight it.

I would be OK with MUST NOT on this side.  I was just being generous with MAY :) 

--Richard

---

From: Joel Martin <[email-masked]>
Date: Thu, 8 Sep 2011 11:38:10 -0500

On Thu, Sep 8, 2011 at 11:36 AM, Joel Martin <[email-masked]> wrote:

> I would also be okay with adding a note indicating that in a future
> revision of the spec, when WebSockets is used with clients that are running
> trusted code (i.e. not browsers), the client may choose to not mask and the
> server can accept unmasked frames. But I think this should only be a note to

This note could be an explanation of why there is a masking bit and it isn't
just assumed/implicit.

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 8 Sep 2011 09:37:51 -0700

> > NEW: "Servers MUST NOT reject un-masked frames, unless masking is required by local policy."

+1 (if it doesn't delay the finalization of the spec)

==

The whole point of c2s masking (what I understood) is making it impossible for a rogue JavaScript
running in the browser coming from somewhere to "attack" naive intermediaries.

Thats fine, and XORing with random mask which is not under JS control does serve that purpose.

However

-  a non-browser client can do whatever it wants anyway

- intermediaries can not check weather c2s frames are really masked, since they can't differentiate
between payload which is masked random noise/encrypted app payload vs. payload that is non-masked
random noise/encrypted app payload anyway

When both (non-browser) peers are under one's control, masking is just consuming CPU without adding something

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 8 Sep 2011 12:40:16 -0400

On Sep 8, 2011, at 12:36 PM, Joel Martin wrote:

> On Thu, Sep 8, 2011 at 11:24 AM, Gabriel Montenegro <[email-masked]> wrote:
> I concur. Client to server MUST mask. Server to client MUST NOT mask. Server MUST fail unmasked messages from the client.
> 
> I would also be okay with adding a note indicating that in a future revision of the spec, when WebSockets is used with clients that are running trusted code (i.e. not browsers), the client may choose to not mask and the server can accept unmasked frames. But I think this should only be a note to indicate possible future direction.

You can already make clients that are not browsers.  Indeed, -13 mentions them in several places.  The future is now!

--Richard

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 8 Sep 2011 16:40:54 +0000

> think this is one of those things we can revisit in version 1.1, along with others
> we've been noting recently.
> 
> I think I understood that consensus slightly differently, more as a capability +
> operational practice than a protocol requirement.  Like I said to John, whatever
> the text says, masking will be appropriate in most cases.

The consensus was clear on the MUST on client to server, so it was a protocol decision, not an operational issue at least at that time.

> > As an individual, the MAY mask on Server to client seems to gain nothing (I'm
> with John Tamplin on this one) and potentially lose something (sendfile), so I'd
> rather say MUST NOT here.
> 
> It doesn't rule out sendfile, since the server can choose not to apply masking.  All
> the proposed text does is clarify that the server has the choice (as it does in the
> current text).

On the server to client, the text is not clear, so I'm not sure it is ok to claim the server can or cannot mask (it is simply not clear).

---

From: John Tamplin <[email-masked]>
Date: Thu, 8 Sep 2011 12:59:28 -0400

> random noise/encrypted app payload anyway

This isn't correct - an intermediary can see the MASK bit is set or not, and
if it wants to even find the payload it has to respect that.

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 8 Sep 2011 10:04:36 -0700

A client can just send frames with mask bit set, a random mask, but don't actually mask (XOR) the payload.

The intermediary can check for mask bit set, unmask the payload using the random mask,
and then?

When a client send white noise as payload, XORing the white noise with any mask will not
change the statistics of the result vs the original.

Same for any sane encryption, which looks like white noise after encryption, and will look
like white noise after XOR with _any_ mask

How can an intermediary proof that payload is really masked?

Von: John Tamplin [mailto:[email-masked]]
Gesendet: Donnerstag, 8. September 2011 18:59
An: Tobias Oberstein
Cc: Peter Saint-Andre; Richard L. Barnes; [email-masked]
Betreff: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt

On Thu, Sep 8, 2011 at 12:37 PM, Tobias Oberstein <[email-masked]<mailto:[email-masked]>> wrote:
- intermediaries can not check weather c2s frames are really masked, since they can't differentiate
between payload which is masked random noise/encrypted app payload vs. payload that is non-masked
random noise/encrypted app payload anyway

This isn't correct - an intermediary can see the MASK bit is set or not, and if it wants to even find the payload it has to respect that.

---

From: SM <[email-masked]>
Date: Thu, 08 Sep 2011 10:14:48 -0700

At 09:31 08-09-2011, Richard L. Barnes wrote:
>I think I understood that consensus slightly differently, more as a 
>capability + operational practice than a protocol requirement.  Like 
>I said to John, whatever the text says, masking will be appropriate 
>in most cases.

I read this more as operational practice than a protocol 
requirement.  I am fine with the consensus.

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Sep 2011 11:40:13 -0600

On 9/8/11 11:14 AM, SM wrote:
>> capability + operational practice than a protocol requirement.  Like I
>> said to John, whatever the text says, masking will be appropriate in
>> most cases.
> 
> I read this more as operational practice than a protocol requirement.  I
> am fine with the consensus.

SM, to clarify, you are fine with what Richard Barnes proposed, or with
other text?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John Tamplin <[email-masked]>
Date: Thu, 8 Sep 2011 13:45:40 -0400

On Thu, Sep 8, 2011 at 12:37 PM, Richard L. Barnes <[email-masked]> wrote:

>> client->server, stating that if the client sends content controlled by
> I don't think that statement is quite correct.  Masking may not be needed
> in some cases where hostile code is present; e.g., if there are no
> vulnerable intermediaries present.  And the requirement as you've stated it
> would require masking within the data center, since the SSL termination box
> would technically be sending content controlled by potentially hostile code.
>

Good point.  Seeing as how it is difficult to write an explanation of when
it would be safe to disable C->S masking, I think it is better to keep the
hard-won consensus of the existing document and leave it for a future
revision of the spec, with a note as suggested by Joel.

---

From: John Tamplin <[email-masked]>
Date: Thu, 8 Sep 2011 13:47:39 -0400

On Thu, Sep 8, 2011 at 1:04 PM, Tobias Oberstein <
[email-masked]> wrote:

> A client can just send frames with mask bit set, a random mask, but don't
> actually mask (XOR) the payload.****
>
> ** **
>
> The intermediary can check for mask bit set, unmask the payload using the
> random mask,****
>
> and then?****
>
> ** **
>
> When a client send white noise as payload, XORing the white noise with any
> mask will not****
>
> change the statistics of the result vs the original.****
>
> ** **
>
> Same for any sane encryption, which looks like white noise after
> encryption, and will look****
>
> like white noise after XOR with _any_ mask****
>
> ** **
>

It knows the payload is really masked because a mask was present.
 Obviously, it can't know whether the payload was chosen to produce some
value after masking (any more than it could know why any particular payload
was chosen), but the browsers enforce that by not letting the JS code
control the key.

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 8 Sep 2011 11:18:55 -0700

I think we've talked past one another: yes, in the browser, JS can't tamper with the masking,
by being restricted to do so.

What I meant was non-browser clients using a WS implementation that have an option
to "fake masking": turn on mask bit, insert mask, but don't actually mask.

That would only work if the server peer knows that masking is fake, and likely only
for binary messages. For example announcing: subprotocol "fakemask-safecpu"

An for that case: the presence of a mask (the 4 octets) plus mask bit set is not sufficient
for an intermediary to know that the payload is actually masked and detect the faking.

A masking scheme that i.e. requires the mask to be the first 4 bytes of the SHA1 computed
over the frame payload would have made that impossible, and intermediaries could actually
proof that frames are really masked. Unmask, recompute SHA1 over frame payload and
compare to mask. Very hard to fake. But I'm certainly NOT advocating anything like that.
It would break streaming i.e. - I'm fine with the current stuff.

Von: John Tamplin [mailto:[email-masked]]
Gesendet: Donnerstag, 8. September 2011 19:48
An: Tobias Oberstein
Cc: Peter Saint-Andre; Richard L. Barnes; [email-masked]
Betreff: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt

On Thu, Sep 8, 2011 at 1:04 PM, Tobias Oberstein <[email-masked]<mailto:[email-masked]>> wrote:
A client can just send frames with mask bit set, a random mask, but don't actually mask (XOR) the payload.

It knows the payload is really masked because a mask was present.  Obviously, it can't know whether the payload was chosen to produce some value after masking (any more than it could know why any particular payload was chosen), but the browsers enforce that by not letting the JS code control the key.

---

From: SM <[email-masked]>
Date: Thu, 08 Sep 2011 11:16:44 -0700

Hi Peter,
>SM, to clarify, you are fine with what Richard Barnes proposed, or with

I am fine with what Richard Barnes proposed.  I'll take a point he 
made off-list and leave it to him to decide on whether a change to 
his proposed text is appropriate.

Regards,
-sm

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 8 Sep 2011 13:39:06 -0700

I don't think we can go back on c->s masking. If someone really cares within
a datacenter, they are free to do nonstandard things within their own
infrastructure at their own risk, but I don't see why we would need to
mention that within a standard.

I don't see how a client would necessarily know that it's safe to disable
masking or not, and so I really don't think we should reopen that can of
worms.

As for S->C, I am ambivalent as to whether it's MAY or MUST NOT.

On Wed, Sep 7, 2011 at 5:14 AM, Richard L. Barnes <[email-masked]> wrote:

> Sorry if I'm missing something (I missed the beginning of the thread), but
> are there people out there who actually *want* masking from the server to
> the client?  The work by abarth, ekr, et al. showed a roughly 40%
> performance hit due to masking under some circumstances -- presumably adding
> s2c masking would degrade performance even further.
>
> --Richard
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 8 Sep 2011 23:06:02 +0200

> Keep in mind, though, that the server still has to *un-mask* the frames from the client, which has the same cost as masking.  So you don't eliminate the performance burden on the server by removing…

It is expected that (like for HTTP), when masking performance matters,
most of the traffic will be emitted by the servers. Being able to send
a video using sendfile() is more important than saving the 100 CPU
cycles needed to decode the request for that file.

At the protocol level, there is no need for any relation between the
direction and the choice of masking. This is purely a concern of the
implementation. Basically if you're in a browser, you must mask outgoing
frames to avoid being abused. If you're a public server, you must ensure
that incoming frames are masked for the same reason. That might very well
be a config option in some products so that this can be either disabled
or changed in specific environments.

There is no reason to make it forbidden at the protocol level to use or
not use masking in either direction. The protocol consists in framed
messages and frames may be masked. It's a lot easier if the frames
decoders are always the sames, so in practice you won't gain anything
by trying to enforce an asymetry.

The cost of running the XOR is negligible, as was shown by measurements
months ago. Even a not-so-modern desktop machine has no trouble XORing
at 10 Gbps.

In fact, I think that the reason why we're starting to see this mask/unmask
discussion now is that implementations are progressively taking place and
developers wonder whether they can get rid of something they think is
useless so that it's even easier to write the code. Maybe the draft still
lacks some explanations, maybe even some code examples (though I think
that the masking/unmasking algo is clear enough).

Maybe providing code examples which handle both masked and unmasked frames
would reduce the number of questions, I don't know.

At this stage, it would be nice if people would focus on how to make the
draft more understandable for everyone instead of trying to restart a year
of long debates with the questions that were discussed long ago.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 8 Sep 2011 23:16:38 +0200

Hi Gabriel,

> NEW: All frames sent from the client to the server MUST be masked to avoid ...

As I indicated in another mail a few days ago, using this passive form
always causes trouble : when you receive something which is not supposed
to be possible, what should you do ? And if you're already able to process
it anyway, should you do it ?

I'd rather suggest something like this :

- clients are not required to accept masked frames, so the server MUST NOT
  send masked frames. Whether clients accept or not masked frames has no
  importance.

- In order to ensure intermediary protection, clients MUST mask outgoing
  frames, and servers MUST NOT accept unmasked frames.

However, it would be nice if we insist that those requirements are made for
the public internet and are not a structural protocol requirement, so they
MAY be adapted in very specific environments if there is any benefit from
doing so.

Regards,
Willy

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 8 Sep 2011 21:33:43 +0000

Salut Willy,

> > Notice also that one of the objections against masking was that it would
> complicate sendfile() scenarios. Since these are expected to be more common
> from server to the client, not masking in this direction was one of the selling
> points of the final solution adopted.
> >
> > Since there are desirable benefits to not masking form server to client, and no
> real scenarios have been identified to do so in that direction, personally, I prefer
> to simplify: I like Takeshi-san's previous proposal, namely:
> >
> > "
> As I indicated in another mail a few days ago, using this passive form always
> causes trouble : when you receive something which is not supposed to be
> possible, what should you do ? And if you're already able to process it anyway,
> should you do it ?

The WG already decided to be very strict about this:
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14#section-10.7

If you find a protocol violation, there's no point in continuing with that peer. Less variability leads to less attack vectors, but also less code to test and maintain.

This is why I still think Takeshi-san's proposal above is the best outcome.

> However, it would be nice if we insist that those requirements are made for the
> public internet and are not a structural protocol requirement, so they MAY be
> adapted in very specific environments if there is any benefit from doing so.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 9 Sep 2011 09:35:29 +1000

> that we can reach closure on this issue.

I believe that from a protocol view point, having masking be optional
in either direction makes sense, with the setting of the masking bit
being just a matter of policy.

However, from a procedural point of view, we fought long and hard to
get to MUST be masked C->S and MUST NOT be masked S->C, so unless
consensus suddenly materialises otherwise,  I can live with those
fixed policies in the spec.

I do like Richards phrase that we will then just have a  defacto "WS
compliant" bit ,that is set to 1 for clients and 0 for servers to
indicate compliance.

cheers

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 09 Sep 2011 09:35:26 +0900

> The consensus was clear on the MUST on client to server, so it was a protocol decision, not an operational issue at least at that time.

I agree with this, and I hope we can move on quickly and not have 
another long discussion on masking.

However, just for the record, I would want to point out that the way the 
browser maker people explained their strong desire for masking was "if 
ever something bad happens, it's always the browser which is blamed". 
That seems to indicate that the guys in charge of performing masking 
from the client side (e.g. the browser makers) and the guys interested 
in having it done are the same. In such a case, changing a MUST to a 
SHOULD is much less of a problem than when the SHOULD is there to 
protect somebody else's interest.

> On the server to client, the text is not clear, so I'm not sure it is ok to claim the server can or cannot mask (it is simply not clear).

Whichever way, this definitely should be clarified.

Regards,   Martin.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 9 Sep 2011 07:47:12 +0200

Hi Gabriel,

> This is why I still think Takeshi-san's proposal above is the best outcome.

Well, I still disagree, but it's not important, so I won't insist ;-)

Cheers,
Willy

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 9 Sep 2011 15:10:27 +0900

[masking bit]

>> doesn't know whether the first four octets are a masking key or not.
I'm fine with MASK bit. I just told the history.

Yes.

>>> masking was added for is averted.
Good point. I missed it. Yes, for c2s traffic, the flag is useful. Let's
keep it.

On Fri, Sep 9, 2011 at 01:38, Joel Martin <[email-masked]> wrote:

> This note could be an explanation of why there is a masking bit and it
> isn't just assumed/implicit.
>

+1

----

[c2s client requirement]

On Fri, Sep 9, 2011 at 05:39, Ian Fette (イアンフェッティ) <[email-masked]>
 wrote:

> I don't think we can go back on c->s masking. If someone really cares
> within a datacenter, they are free to do nonstandard things within their own

> revision of the spec, with a note as suggested by Joel.

+1 for these. We shouldn't change c2s masking from MUST to SHOULD.

> to "fake masking": turn on mask bit, insert mask, but don't actually mask.

I understand that "MUST be masked" is not perfect. The same applies to
Sec-WebSocket-Accept. Some bad client may just ignore Sec-WebSocket-Accept.
Taking care of implementations intentionally violating MUSTs brings us back
to the handshake proposal by Adam
http://tools.ietf.org/html/draft-abarth-websocket-handshake-00.

I think use of MUSTs and MUST NOTs in the spec is necessary-sufficient.

----

[c2s server requirement]

> NEW: "Servers MUST NOT reject un-masked frames, unless masking is required

I prefer the spec asks server implementors to guide clients to implement
masking by rejecting unmasked frames as currently specified at
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14#section-5.3
.

----

[relaxing]

For non-browser clients' performance concern, I'd rather like to see some
extension to relax the restriction explicitly. For example,
"Sec-WebSocket-Extensions: no_c2s_masking_intentionally"

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 9 Sep 2011 09:56:48 -0400

>  frames, and servers MUST NOT accept unmasked frames.

Let's not fool ourselves that having servers reject unmasked frames does anything about intermediary protection. 

If there's a WS stack out there that an attacker can force to send unmasked frames, then the game is already over.  The attacker just connects to a server under his control that will accept the unmasked frames, and the gig is up.

> MAY be adapted in very specific environments if there is any benefit from

In which case, you might as well make it a SHOULD, with an operational note that says that c2s masking is strongly RECOMMENDED.

--Richard

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 9 Sep 2011 16:06:37 +0200

> If there's a WS stack out there that an attacker can force to send unmasked frames, then the game is already over.  The attacker just connects to a server under his control that will accept the unm…

It's not what I'm targetting at all. My concern is that if we accept that
servers don't check, then laziness will win and we'll quickly see a number
of clients who won't mask at all because it works. And THEN server-side
controlled software will be an issue. By ensuring that servers only accept
masked frames, we force clients to always enable masking.

Regards,
Willy

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 9 Sep 2011 10:15:00 -0400

> masked frames, we force clients to always enable masking.

As Martin pointed out, though, we actually have good incentive alignment here -- the browsers know that they'll bear the pain if not masking causes problems.  So it doesn't seem like there's really any reason to believe that "laziness will win".

--Richard

---

From: Bruce Atherton <[email-masked]>
Date: Fri, 09 Sep 2011 11:40:55 -0700

On 08/09/2011 5:35 PM, "Martin J. Dürst" wrote:
>
> However, just for the record, I would want to point out that the way 
> the browser maker people explained their strong desire for masking was 
> "if ever something bad happens, it's always the browser which is 
> blamed". That seems to indicate that the guys in charge of performing 
> masking from the client side (e.g. the browser makers) and the guys 
> interested in having it done are the same. In such a case, changing a 
> MUST to a SHOULD is much less of a problem than when the SHOULD is 
> there to protect somebody else's interest.

This is exactly right. Browser makers are the ones who insisted on this 
feature, and they will certainly implement it. I doubt that any other 
implementer of a client even wants masking.

I see no reason to require servers to reject connections with incoming 
unmasked frames. Masking is a concern for browser clients only.

The argument has been made that clients will be lazily implemented to 
not implement masking, but I can't understand why that is an issue. Such 
custom clients could send whatever they wanted to anyway. Browser 
clients will always have masking, unless it is shown that there is no 
benefit to it because the buggy intermediaries are gone.