Subject: [hybi] consensus call on c2s masking and decision on s2c masking

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 9 Sep 2011 20:17:21 +0000

The chairs in consultation with the editors and AD (Peter) have thought about the recent suggestion to somehow relax masking from client to server ("c2s"). This is not the first time this topic comes up in the working group. Masking is the ONE point on which the WG has spent the most cycles, blood and tears. It was VERY close to causing a complete shutdown of this group. On a personal note, in well over a decade of IETF participation, I (Gabriel) have never seen a harder consensus than this one.

Furthermore, there is evidence of still strong feeling that we should not revisit this point based on recent messages from Greg Wilkins, John Tamplin, Ian Fette, Takeshi Yoshino. Of course, the feeling is not unanimous. It never was. But it was the only position that allowed the WG to continue. Because of this, the chairs would rather not reopen this issue for debate (but see below). We arrived at a consensus already and there's no new data or inputs that have not been considered before that would warrant our revisiting that position.  Furthermore, we are concerned that a number of the working group participants who were active in the original discussion on this topic are no longer actively involved at this late stage in the process, and we want to make sure that we honor their contributions to the hard-won consensus earlier on.

Of course, a future version of websockets could tackle this issue, just as there are other issues that we have recently earmarked for future work. The truth is that we need deployment experience to know more about some potential directions and acting now on these would be premature.

As for the s2c masking direction. It was not entirely clear in the draft whether it was *allowed* or not, nor was it made explicit at the original consensus on masking (beyond the statement that masking was not *required* in the s2c direction). In the interest of simplicity, we are asking our editors to clarify that masking MUST NOT be done in the server to client direction. We see reasonable support for this in the mailing list.

S2C masking decision:

   Change in the first paragraph of 5.1:

   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.

   Also add that a client MUST close a connection if it detects masked frames.

As for the C2S masking however, given the recent IESG discussions on this topic, we're issuing a short consensus call to run thru next Wednesday end-of-day to make sure we follow the due process. Option 1 is essentially the previous  consensus with the additional clarification regarding potential future relaxation. This is what we believe there is still consensus on. Option 2 is the proposal from Richard Barnes to relax masking.

C2S masking OPTION 1:

   Change in the first paragraph of 5.1:

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

   Clarify that masking rules may be relaxed in future releases after more experience and knowledge is gained from deployment.

C2S masking OPTION 2:

   Change in the first paragraph of 5.1:

   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 masked to avoid ..."

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

Thanks,

Gabriel Montenegro and Salvatore Loreto, Chairs

---

From: John Tamplin <[email-masked]>
Date: Fri, 9 Sep 2011 16:25:59 -0400

On Fri, Sep 9, 2011 at 4:17 PM, Gabriel Montenegro <
[email-masked]> wrote:

>  C2S masking OPTION 1:
>
> **
>
>    Change in the first paragraph of 5.1:****
>
>    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 ...****
>
> ** **
>
>    Clarify that masking rules may be relaxed in future releases after more
> experience and knowledge is gained from deployment.****
>
> ** **
>
> C2S masking OPTION 2:****
>
>    Change in the first paragraph of 5.1:****
>
>    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 masked to
> avoid ..."****
>
> ** **
>
> **
Personally I am fine with either option.  However, before we go with option
#2, I would want to make sure that all those who strongly objected to it in
the past are accounted for, either through a direct response or considering
their previous responses in case they aren't still here.

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 9 Sep 2011 16:36:05 -0400

>    Also add that a client MUST close a connection if it detects masked frames.

Fine with this

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

I prefer option 2, but would gladly add more text when and why masking is strongly RECOMMENDED [1].  

--Richard

[1] Maybe we need to amend RFC 2119 to add a NOT STRICTLY REQUIRED BUT IN THIS SITUATION YOU WOULD BE STUPID NOT TO :)

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 10 Sep 2011 09:29:05 +1000

On 10 September 2011 06:17, Gabriel Montenegro
<[email-masked]> wrote:
> ..."

+1 for option 2.   This makes it very clear that accepting/rejecting
unmasked frames is a matter of policy not protocol.  I like!

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Sep 2011 16:35:13 -0700

On Fri, Sep 9, 2011 at 1:17 PM, Gabriel Montenegro
<[email-masked]> wrote:
> The chairs in consultation with the editors and AD (Peter) have thought
> about the recent suggestion to somehow relax masking from client to server
> ("c2s"). This is not the first time this topic comes up in the working
> group. Masking is the ONE point on which the WG has spent the most cycles,
> blood and tears. It was VERY close to causing a complete shutdown of this
> group. On a personal note, in well over a decade of IETF participation, I
> (Gabriel) have never seen a harder consensus than this one.
>
>
>
> Furthermore, there is evidence of still strong feeling that we should not
> revisit this point based on recent messages from Greg Wilkins, John Tamplin,
> Ian Fette, Takeshi Yoshino. Of course, the feeling is not unanimous. It
> never was. But it was the only position that allowed the WG to continue.
> Because of this, the chairs would rather not reopen this issue for debate
> (but see below). We arrived at a consensus already and there's no new data
> or inputs that have not been considered before that would warrant our
> revisiting that position.  Furthermore, we are concerned that a number of
> the working group participants who were active in the original discussion on
> this topic are no longer actively involved at this late stage in the
> process, and we want to make sure that we honor their contributions to the
> hard-won consensus earlier on.
>
>
>
> Of course, a future version of websockets could tackle this issue, just as
> there are other issues that we have recently earmarked for future work. The
> truth is that we need deployment experience to know more about some
> potential directions and acting now on these would be premature.
>
>
>
> As for the s2c masking direction. It was not entirely clear in the draft
> whether it was *allowed* or not, nor was it made explicit at the original
> consensus on masking (beyond the statement that masking was not *required*
> in the s2c direction). In the interest of simplicity, we are asking our
> editors to clarify that masking MUST NOT be done in the server to client
> direction. We see reasonable support for this in the mailing list.
>
>
>
> S2C masking decision:
>

Yes, I agree that this is fine.

>
>
> As for the C2S masking however, given the recent IESG discussions on this
> topic, we're issuing a short consensus call to run thru next Wednesday
> end-of-day to make sure we follow the due process.

I don't agree that this is due process. This issue has already been decided
by the WG and now the IESG is asking us to revisit this decision? I believe
you'll find that this is an explicit non-criterion in the IETF DISCUSS criteria:

"Disagreement with informed WG decisions that do not exhibit problems
outlined in Section 3.1. In other words, disagreement in preferences
among technically sound approaches."

> Option 1 is essentially
> the previous  consensus with the additional clarification regarding
> potential future relaxation. This is what we believe there is still
> consensus on. Option 2 is the proposal from Richard Barnes to relax masking.
>
>
>
> C2S masking OPTION 1:
>
> ...
> avoid ...

Yes.

> experience and knowledge is gained from deployment.
>
>
>
> C2S masking OPTION 2:
>
>    NEW: "Frames sent from the client to the server SHOULD be masked to avoid
>
>

No.

-Ekr

---

From: Adam Barth <[email-masked]>
Date: Fri, 9 Sep 2011 18:00:05 -0700

On Fri, Sep 9, 2011 at 1:17 PM, Gabriel Montenegro
<[email-masked]> wrote:
> end-of-day to make sure we follow the due process. Option 1 is essentially

Has anyone brought forward any new information on this topic?  If not,
it seems unlikely the working group should change its mind on this
topic.

> experience and knowledge is gained from deployment.

That seems like a good clarification of the current intent of the document.

> required by local policy."

This text is a bad idea, as discussed before.

Adam

---

From: Brian <[email-masked]>
Date: Fri, 9 Sep 2011 18:15:44 -0700

I would prefer a little bit more flexibility in the spec for use cases
internal to a data center etc., so option 2, but I am loathe to really
re-open this debate and am perfectly fine with option 1.  WebSocket
implementations designed with an eye toward use within a private datacenter
will probably be implemented with an option that will disable masking,
knowingly making them non-compliant with the spec.  As far as I'm concerned,
that's perfectly fine.  The browser use case is the only one that needs the
masking in the first place, and there's no chance that any browser vendor is
going to overlook this and not mask c2s frames.  Given that this protocol is
really intended primarily for use by browsers, I don't object to the strong
requirement for c2s masking.

Best to leave the hard-fought battle in the past, keep the previous
consensus, and move forward.

Brian

On Fri, Sep 9, 2011 at 6:00 PM, Adam Barth <[email-masked]> wrote:

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 10 Sep 2011 11:01:28 +0900

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

I'm fine with both option 1 and option 2, and I hope we can settle this 
very quickly.

Regards,   Martin.

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 10 Sep 2011 16:01:47 +1000

On 10 September 2011 11:15, Brian <[email-masked]> wrote:
> re-open this debate....

Note that one reason for revisiting this issue (albeit as briefly as
possible), is that we now have 1008 Policy failure close response,
which we didn't have before.

So option 2 is really just saying that we should treat unmasked c2s
frames as a policy decision and use a 1008 close if they are not
allowed.

Perhaps it would be more palatable to all if the sense of the last
clause of option 2 was inverted to:

   Unless permitted by local policy, Servers MUST reject un-masked
frames with  a 1008 close of the connection.

cheers

---

From: Patrick McManus <[email-masked]>
Date: Sat, 10 Sep 2011 10:26:34 -0400

> As for the C2S masking however, given the recent IESG discussions on
> this topic, we're issuing a short consensus call to run thru next
> Wednesday end-of-day to make sure we follow the due process.

Given no new information, this doesn't seem appropriate to reopen.

> C2S masking OPTION 1:

yes.

> avoid ..."

no.

I'd repeat the same old arguments, but enough bits have been spilled.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 10 Sep 2011 16:39:14 +0200

This is very tricky. You are right that it was very hard to get this 
consensus. But on the other hand, the technical argument in favor of 
masking was on shaky grounds, in particular as the experiments didn't 
really use what was specified back then (unless I'm misremembering).

> Also add that a client MUST close a connection if it detects masked frames.

No. The frame is self-descriptive, right? The recipient, it it doesn't 
require framing, should still allow it.

> Wednesday end-of-day to make sure we follow the due process. Option 1 is
> essentially the previous consensus with the additional clarification
> regarding potential future relaxation. This is what we believe there is
> still consensus on. Option 2 is the proposal from Richard Barnes to
> relax masking.
>
> C2S masking OPTION 1:
>

Or: "MUST reject, unless ... not required".

I like that. Browsers can continue to do what they think they need to 
do, without affecting other cases.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 10 Sep 2011 16:46:38 +0200

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

Let's not re-open a huge can of worms, please stay on OPTION 1 with the
suggested clarification. Deployments will help get rid of the remaining
faulty intermediaries and in a few years it won't be a problem anymore
to remove masking.

BTW, we could also complete the note by suggesting that experimentations
in controlled environments might work with masking disabled (eg: to test
whether some intermediaries are faulty or not) but that they are not
standard-compliant.

Regards,
Willy

---

From: Joel Martin <[email-masked]>
Date: Sat, 10 Sep 2011 12:56:13 -0500

On Fri, Sep 9, 2011 at 3:17 PM, Gabriel Montenegro <
[email-masked]> wrote:

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

Concur with "MUST NOT".

>  C2S masking OPTION 1:****
>

I prefer OPTION 1 (C2S MUST mask with a note about future releases) but
could live with OPTION 2.

Joel Martin

---

From: Justin Lee <[email-masked]>
Date: Sun, 11 Sep 2011 20:39:23 -0400

I lean a bit toward option 2, personally, though I'm fine-ish with option 1,
too.  Maybe the PTSD has blocked it out, but was the option of making
masking a standard extension that browsers can request ever considered?  It
seems to me that masking (security) vs frame structure (basic protocol
definition) is skirting the separation of concerns principal a bit.  On
known, trusted networks, everything can work just fine without masking.
 It's only in the wilds of the internet that masking holds any value (and
even that is probably debatable).  So why not separate the two out?  Let
browsers request it by default (however it is they choose to build their own
policies) and let others choose to not request it (however it is they choose
to build their own policies)?  Would that not satisfy both camps?

On Sat, Sep 10, 2011 at 1:56 PM, Joel Martin <[email-masked]> wrote:

>> ****

-- 
You can find me on the net at:
http://antwerkz.com
http://antwerkz.com/+
http://antwerkz.com/linkedin
http://antwerkz.com/twitter

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 12 Sep 2011 14:12:16 +1000

It looks like the chairs have yet another tough call to make between
option 1 and option 2. Which everway they call it, it would be good if
they made it clear what close code should be used with any rejections.

For option 2, the use of the word "policy" implies that rejections
would be 1008 policy violation.
For option 1, it is less clear. Should rejections be 1002 protocol
violations or 1008 policy violations.

Regardless of which options is adopted, I strongly prefer 1008 policy
violation (even if we initially say that servers MUST have a policy to
reject unmasked frames from the client).

regards

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 12 Sep 2011 06:47:45 +0200

> reject unmasked frames from the client).

I totally agree with you on this, Greg. And we must keep in mind that when
we move the protocol to work on non-HTTP, the framing will probably not
change so the protocol will remain the same. It will then be much more
clear that it's a matter of policy to mask over HTTP and not a protocol
issue.

Regards,
Willy

---

From: Bruce Atherton <[email-masked]>
Date: Mon, 12 Sep 2011 11:28:37 -0700

>    Also add that a client MUST close a connection if it detects masked 

Good.

>    Clarify that masking rules may be relaxed in future releases after 
> more experience and knowledge is gained from deployment.
>
> C2S masking OPTION 2:
>

I prefer option 2 but am fine with option 1, so long as it does not 
require the server to close the connection if an unmasked frame is 
received. It is clear there are going to be a number of 
"Websocket-similar" protocol deployments (with no client masking), and 
it should be possible to write a server that can work with both.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 12 Sep 2011 20:44:06 +0200

Hi Bruce,

> it should be possible to write a server that can work with both.

I agree with your point here about "being possible to write...". That's
why I think we should really make it clear what is a matter of protocol
and what is the standard use. If we want to ensure that a server rejects
unmasked frames when dealing with the internet, we should at least say
that a server does not need un understand unmasked frames, but if it
does, it must be possible to configure it to block them. That way we
cover most common internet usage and local variants for specific uses.

Regards,
Willy

---

From: Joe Mason <[email-masked]>
Date: Mon, 12 Sep 2011 16:03:38 -0400

+1 on option 1, but add language to make it clear that "1008 Policy Violation" is the correct error to use here
-1 on option 2, which does not match the intended semantics of the current spec so shouldn't be changed now

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Greg Wilkins
> Sent: Monday, September 12, 2011 12:12 AM
> To: Gabriel Montenegro
> Cc: [email-masked]
> Subject: Re: [hybi] consensus call on c2s masking and decision on s2c
> masking
> 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Bruce Atherton <[email-masked]>
Date: Mon, 12 Sep 2011 16:49:48 -0700

> cover most common internet usage and local variants for specific uses.

I guess I just don't understand the need to have the server reject 
unmasked frames. I don't see what it buys you. But if the easiest way to 
move on is to adopt option 1 and have language about how servers deal 
with unmasked frames, then perhaps we need some variation on the option 
2 language concerning servers so it is clear that accepting or rejecting 
unmasked frames on the server is a policy issue.

Something like: "Servers MUST reject unmasked frames unless unmasked 
frames coming in to the server are allowed by local policy."

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 13 Sep 2011 07:47:44 +0200

> unmasked frames on the server is a policy issue.

The only reason is to ensure that masking in the default choice for
communications. If each side considers that it can mask or not because
the other side will decide then we're back to the risk of having some
clients abused to send unmasked frames. As someone stated it, it's mostly
the browsers who want masking so the risk of seeing them not implement the
option seems low. However if almost no server accept unmasked frames by
default, we're certain there is no temptation to do this. And I agree that
this is only a policy issue. I'd love to see WS being used in locations we
did not imagine and in clear in both directions.

> frames coming in to the server are allowed by local policy."

Sounds perfect.

Willy

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 13 Sep 2011 15:54:04 +1000

On 13 September 2011 09:49, Bruce Atherton <[email-masked]> wrote:
> Something like: "Servers MUST reject unmasked frames unless unmasked frames
> coming in to the server are allowed by local policy."

+1

---

From: "Alexander Philippou" <[email-masked]>
Date: Tue, 13 Sep 2011 09:54:05 +0300

+1

Alexander

---

From: Joel Martin <[email-masked]>
Date: Tue, 13 Sep 2011 08:12:27 -0500

> coming in to the server are allowed by local policy."
Works for me.

Joel Martin

---

From: David Endicott <[email-masked]>
Date: Tue, 13 Sep 2011 09:52:05 -0400

**
> required by local policy."

+1   My preference.

"*Be conservative in what you send; be liberal in what you accept." -
J.Postel*

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Sep 2011 06:53:49 -0700

To repeat myself, no.

-Ekr

On Mon, Sep 12, 2011 at 4:49 PM, Bruce Atherton <[email-masked]> wrote:
> I guess I just don't understand the need to have the server reject unmasked
> frames. I don't see what it buys you. But if the easiest way to move on is
> to adopt option 1 and have language about how servers deal with unmasked
> frames, then perhaps we need some variation on the option 2 language
> concerning servers so it is clear that accepting or rejecting unmasked
> frames on the server is a policy issue.
>

---

From: Piotr Kulaga <[email-masked]>
Date: Tue, 13 Sep 2011 21:33:02 +0000

+1 for option 1. Let's go with more secure approach until we are completely sure that turning it off is safe. It took us months to reach consensus on this topic - let's stick to the intended interpretation of the spec.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gabriel Montenegro
Sent: Friday, September 09, 2011 1:17 PM
To: [email-masked]
Subject: [hybi] consensus call on c2s masking and decision on s2c masking

S2C masking decision:

C2S masking OPTION 1:

C2S masking OPTION 2:

Thanks,

---

From: Joe Mason <[email-masked]>
Date: Wed, 14 Sep 2011 09:56:22 -0400

I'm strongly opposed to "unless allowed by local policy" language.  This makes the spec essentially contradict itself - the client section says "you MUST mask" but the server section implies that there is a way to let clients not mask "by local policy".  This makes the spec much harder to understand for people who don't know all the background!

Another way to look at it is that with this language, the spec is basically saying, "Clients MUST mask, but you can ignore what the spec says about that as a matter of local policy."  Well, implementers are ALREADY able to ignore what the spec says as a matter of local policy - they're just noncompliant, and their policy may be that they're ok with that.  Let's keep that decision clearcut - either you are compliant with the spec, or you've chosen to deviate from the spec.

The consensus we have already come to is that clients to servers must mask, servers to clients must not, and there is a mask bit to indicate whether the mask is present (ie. Which way the message is flowing).  Any language which doesn't exactly fit these requirements breaks that consensus, so we should not be considering it at this late date.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Sep 2011 16:16:43 +0200

> The consensus we have already come to is that clients to servers must mask, servers to clients must not, and there is a mask bit to indicate whether the mask is present (ie. Which way the message i…

The mask bit indicates masking, not direction of message flow direction. 
Please do not confuse those things.

Best regards, Julian

---

From: Joe Mason <[email-masked]>
Date: Wed, 14 Sep 2011 10:21:17 -0400

Sorry to be unclear - I meant that right now since all client->server messages are masked and all server->client messages are not masked, some have suggested removing the mask bit since both server and client know whether they are expecting a masked message.  But the bit is still useful in traffic examination since you may not know whether a message is c->s or s->c.

I'm not advocated changing the definition of the bit in the spec!

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2011 10:17 AM
To: Joe Mason
Cc: Bruce Atherton; Willy Tarreau; [email-masked]; Gabriel Montenegro
Subject: Re: [hybi] consensus call on c2s masking and decision on s2c masking

Best regards, Julian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Sep 2011 16:25:20 +0200

> The consensus we have already come to is that clients to servers must mask, servers to clients must not, and there is a mask bit to indicate whether the mask is present (ie. Which way the message i…

I strongly agree. A specification must be strict. A MUST is a MUST. Of
course anyone can implement the spec in the way he wants, by breaking
rules or making it not compliant. The document should not cover those
cases.

Also, I've never seen a text like the proposed text in any RFC.

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Sep 2011 16:25:59 +0200

> I'm not advocated changing the definition of the bit in the spec!

Well, the point is, you can only *assume* that the masking bit tells you 
the direction. It might not, if somebody uses a client that does not mask.

...let's not paint ourselves into a corner where it becomes impossible 
to send unmasked from the client, just because there's code out there 
that makes incorrect assumptions about the masking bit.

Best regards, Julian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Sep 2011 16:41:06 +0200

2011/9/14 Julian Reschke <[email-masked]>:
> Well, the point is, you can only *assume* that the masking bit tells you the
> direction. It might not, if somebody uses a client that does not mask.
>
> ...let's not paint ourselves into a corner where it becomes impossible to
> send unmasked from the client, just because there's code out there that
> makes incorrect assumptions about the masking bit.

If a client sends a frame with no masking then it's not compliant with
the spec. We should entirely forget and not care about those cases
which break the spec.

In the case in which the client is spec-compliant, the masking bit is
valid to detect the direction of the frame. Just true.

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Sep 2011 16:47:22 +0200

On 2011-09-14 16:41, Iñaki Baz Castillo wrote:
> 2011/9/14 Julian Reschke<[email-masked]>:

We already have stated that there may be cases where it's totally ok for 
clients to send unmasked frames; for instance, non-browser clients, not 
on the open internet.

Even *if* the spec continues to consider this case to be non-compliant 
it should not make this use case impossible by suddenly changing the 
semantics of the "mask" bit. It means what it means (and it's not the 
direction of the message flow).

Best regards, Julian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Sep 2011 16:51:17 +0200

2011/9/14 Julian Reschke <[email-masked]>:
> clients to send unmasked frames; for instance, non-browser clients, not on
> the open internet.

Then the draft should say:

  "Frames from *web-browser* to server MUST be masked. Frames from
other WebSocket clients MAY be masked".

(so the server MUST allow incoming frames with and without masking).

> Even *if* the spec continues to consider this case to be non-compliant it
> should not make this use case impossible by suddenly changing the semantics
> of the "mask" bit. It means what it means (and it's not the direction of the
> message flow).

I agree on that. Such a bit should not be understood as the "frame direction".

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

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 14 Sep 2011 16:51:39 +0200

> the spec. We should entirely forget and not care about those cases

Iñaki, there is a difference between a spec and its uses, please don't
confuse them both.

> valid to detect the direction of the frame. Just true.

Please no, don't spread this awful idea !!! That's the worst idea to bring
here, this means that this bit will be misused and will cause security
trouble everywhere.

The direction and the masking bit are *INDEPENDANT*. It just happens that
most often it will be a good guess to deduce the direction from the masking
bit in a network trace. Nothing more.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Sep 2011 16:58:31 +0200

> Iñaki, there is a difference between a spec and its uses, please don't

IMHO a spec should not consider bad usage of the spec itself.

> bit in a network trace. Nothing more.

Ok, I'm fully convinced :)

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

---

From: Bruce Atherton <[email-masked]>
Date: Wed, 14 Sep 2011 14:55:23 -0700

> I'm strongly opposed to "unless allowed by local policy" language.  This makes the spec essentially contradict itself - the client section says "you MUST mask" but the server section implies that t…

No, that is not what the proposed language says. It says that clients 
MUST mask, and that servers MUST reject unmasked frames unless allowed 
by local policy. This is not a contradiction.

Two examples to demonstrate the separation:

   1) Frames may be unmasked by intermediaries and sent on to servers. 
This does not change the requirement for clients to mask all frames.
   2) Servers may wish to support Non-Websocket clients that use a 
variation of Websockets that has no client masking. There are a number 
of people here who have expressed interest in interoperating with both 
Websockets clients and these similar-but-not-Websockets clients.

---

From: Joe Mason <[email-masked]>
Date: Wed, 14 Sep 2011 18:20:17 -0400

If clients must mask, who is allowed to send unmasked frames to servers?

If a server interacts with similar-but-not-Websockets clients, is is not a websockets server.  It is a websockets-plus-something-else server.  It can turn on the "allows clients to not mask" behavior when talking to a non-websocket client, and follow the spec when talking to a websocket client.  (Presuming it can distinguish them.  If a similar-but-not-websockets client simply announces itself as a websocket client but then does not mask its frames, then it is not similar-but-not-websockets: it is simply websockets which is not following the spec correctly.  And if a server is ok with talking to such noncompliant clients, it is similarly noncompliant.)  The spec says nothing about what a server that handles multiple protocols will do when speaking to a protocol that isn't websockets, so it does not disallow this.

An intermediary that unmasks the client frames, likewise, is no longer speaking websockets and the spec has nothing to say about this.

The spec needs to be, above all else, clear and unambiguous.  "unless allowed by local policy" is neither.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 15 Sep 2011 00:31:08 +0200

> An intermediary that unmasks the client frames, likewise, is no longer speaking websockets and the spec has nothing to say about this.

That's precisely why it's better to ensure the protocol is not restricted
to *your* usage but covers other people's usages. Declaring as "forbidden"
things that are technically possible and that make sense for some users is
the worst thing to do in a spec, because many people will implement them
and once done, you're screwed, because every implementation does its variant
a different way.

> The spec needs to be, above all else, clear and unambiguous.  "unless allowed by local policy" is neither.

Exactly. And if within a WG, you can already find a few percent of supporters
for a usage within less than 100 persons, you can be sure that it will not
take long before you see products appear with non-compliant implementations
that bring real value that we were not smart enough to think about here.

Look at what's done with server-side web accelerators. It's pretty disgusting,
some of them are doing everything that is not permitted by specs. Still they
sell and cause trouble where they're deployed, simply because they bring
value to the customer. Better be clear about what is possible and what is
permitted than saying things are not possible when they are. At least you
can hope that variants will approximately converge and be easier to merge
into WS 1.1.

Regards,
Willy

---

From: Bruce Atherton <[email-masked]>
Date: Wed, 14 Sep 2011 15:42:36 -0700

> If clients must mask, who is allowed to send unmasked frames to servers?

Intermediaries.

> If a server interacts with similar-but-not-Websockets clients, is is not a websockets server.

Sure it can be. It can be a Websockets server, an HTTP server, and a 
similar-but-not-Websockets server. But if Websockets servers are 
required by the spec to reject unmasked frames, then you force the 
server to either: not support the latter; to ignore the spec and be 
incompatible with Websockets; or to invent a new, nonstandardized 
protocol. None of those seems like a good idea to me, but that is just 
my opinion. In any case, it doesn't alleviate the need to allow 
intermediaries to unmask.

> An intermediary that unmasks the client frames, likewise, is no longer speaking websockets and the spec has nothing to say about this.

This is not true at all. The Websockets connection is end-to-end. All 
the spec requires is that the frames start out masked. It says nothing 
about whether the frames need to arrive at the server masked, which is 
what we are now trying to clarify. I have my position on how this should 
be clarified and you have yours. Both are equally valid as far as the 
spec as it currently exists is concerned.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 00:45:03 +0200

2011/9/14 Bruce Atherton <[email-masked]>:
>  1) Frames may be unmasked by intermediaries and sent on to servers. This
> does not change the requirement for clients to mask all frames.

Please define what an intermediary is. It is not defined in the draft
so it does not exist.

Also, if the "intermediary" unmaskes frames from WebSocket clients,
then it's behaving as a WebSocket server.

>  2) Servers may wish to support Non-Websocket clients that use a variation
> of Websockets that has no client masking.

Then they are not WebSocket clients, so they are not speaking the
WebSocket protocol defined in this draft. Period.

> There are a number of people here
> who have expressed interest in interoperating with both Websockets clients
> and these similar-but-not-Websockets clients.

Which kind of hack is that? why should a specification about
*WebSocket* protocol cover the case of a *non-WebSocket* client???

If the server communicates with WebSocket clients then it's using
WebSocket protocol.
If the server communicates with not-WebSocket clients then it's using
some other "protocol", but not WebSocket, so such "protocol" MUST be
out of the scope of this draft.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 00:57:19 +0200

>> If clients must mask, who is allowed to send unmasked frames to servers?

The famous intermediaries.

> similar-but-not-Websockets server. But if Websockets servers are required by
> the spec to reject unmasked frames, then you force the server to either: not
> support the latter; to ignore the spec and be incompatible with Websockets;
> or to invent a new, nonstandardized protocol. None of those seems like a
> good idea to me, but that is just my opinion. In any case, it doesn't
> alleviate the need to allow intermediaries to unmask.

Nothing prevents the service provider to use unmasked frames from
"intermediaries" to "servers", as those network elements exist within
provider's infrastructure.  But there is no need for covering that in
the spec.

>> An intermediary that unmasks the client frames, likewise, is no longer
>> speaking websockets and the spec has nothing to say about this.
>
> This is not true at all. The Websockets connection is end-to-end.

What is end-to-end for you? If the client connects to the
"intermediary" and performs the WS handshake with the "intermediary",
then the WebSocket connection is from client to intermediary, rather
than client to server. But since the concept of intermediary is
unknown or vaguely defined...

> All the spec requires is that the frames start out masked. It says nothing about
> whether the frames need to arrive at the server masked, which is what we are
> now trying to clarify.

This makes NO sense. The draft just defines WebSocket clients and
WebSocket servers. The term "intermediary" is undefined, so
"something" in the path (between a WS client and WS server) which
unmaskes frames should not be considered here.

First define *in the spec* what a WS intermediary is. Then you can
adapt/modify the spec in order to cover cases in which there are WS
intermediaries in the path.

Regards.

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

---

From: Bruce Atherton <[email-masked]>
Date: Wed, 14 Sep 2011 16:04:56 -0700

On 14/09/2011 3:45 PM, Iñaki Baz Castillo wrote:
> 2011/9/14 Bruce Atherton<[email-masked]>:

It doesn't exist? Huh. That would be news to a lot of people who seem to 
be able to use the word without a problem. The spec also doesn't define 
the meaning of the word "the". Or "protocol". Or...

When I use the word "intermediary", I am talking about everything that 
lies in the path of the connection, everything that the packets pass 
through between the client and the server. This includes switches, hubs, 
routers, border equipment, proxys, load balancers, the NICs and buffers 
and switching fabric of all this, in other words everything that is in 
the path. Now, most of this will have no effect on the connection or on 
the packets or on the HTTP headers or on the WS frames, but some parts do.

> then it's behaving as a WebSocket server.

No it's not. It is manipulating information in Websocket frames just as 
if it were reframing. The semantic content is left unchanged, and indeed 
is probably completely opaque to the intermediary. This would in no way 
constitute a Websockets server.

---

From: Brian <[email-masked]>
Date: Wed, 14 Sep 2011 16:13:23 -0700

We're really stretching the limits of logical reasoning and debate at this
point.

We had reached a tense consensus quite some time ago that masking was
non-optional from client-to-server.  If I recall, there were some
participants that said in no uncertain terms that they would not accept any
language whatsoever that might make it in any way allow clients to send
unmasked frames, and the rest of this WG grudgingly agreed.  I suggest that
we continue with the spirit of that original consensus at this point and
move on.  This discussion so far is just the tip of the iceberg if we
re-open this can of worms.

There will be WebSocket components created that violate this point of the
spec out in the wild, many likely designed for use within a secure
datacenter.  However I doubt that there will be any real incompatible
variation amongst such implementations that disable masking -- given an
understanding of how the protocol works, there is unambiguously one obvious
way to disable masking that would achieve the desired result of reducing the
processing overhead for the ultimate server - set the "MASK" bit to zero and
don't include the mask key in the frame header.  The only other option,
using a 0x00000000 mask key, would not achieve the desired goal and will
thus likely not be implemented.

Honestly, I think it is perfectly acceptable to say that clients MUST mask
outgoing frames, but servers MAY accept unmasked incoming frames.  The only
clients that matter for the purposes of masking enforcement are the
mainstream browsers, and there is no chance that they're going to allow
their implementations to violate this point of the spec and ever send
unmasked frames.  We do NOT need server enforcement on this point.  If there
is an obscure non-browser client that doesn't mask frames then who cares?
 That client doesn't in any way matter in terms of the vulnerability against
which masking was meant to protect.  And the browser vendors certainly don't
need any hand-holding by servers to make sure they stay on the
straight-and-narrow when it comes to masking enforcement.

Brian

On Wed, Sep 14, 2011 at 3:45 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> variation

---

From: Bruce Atherton <[email-masked]>
Date: Wed, 14 Sep 2011 16:17:49 -0700

> provider's infrastructure.  But there is no need for covering that in

There is if the spec specifically requires servers to receive the frames 
masked. That was my concern about option 1, although it was not spelled 
out that option 1 would require this.

> than client to server.

Who said it performed the handshake with the intermediary? The handshake 
would be with the server. That is what makes it the server.

> unmaskes frames should not be considered here.

I know that you personally don't get what an intermediary is. You've 
said so many many times. But the spec uses the term no less than 11 
times, so I think you need to accept that the spec does have something 
to say about intermediaries, whether you consider that valid or not.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 01:24:10 +0200

2011/9/15 Bruce Atherton <[email-masked]>:
> It doesn't exist? Huh. That would be news to a lot of people who seem to be
> able to use the word without a problem. The spec also doesn't define the
> meaning of the word "the". Or "protocol". Or...
>
> When I use the word "intermediary", I am talking about everything that lies
> in the path of the connection, everything that the packets pass through
> between the client and the server. This includes switches, hubs, routers,
> border equipment, proxys, load balancers, the NICs and buffers and switching
> fabric of all this, in other words everything that is in the path. Now, most
> of this will have no effect on the connection or on the packets or on the
> HTTP headers or on the WS frames, but some parts do.

No, if we are speaking about WebSocket protocol (which is an
application-level protocol) then an "intermediary" is just something
that deals with WebSocket protocol traffic. An IP router is not a
WebSocket intermediary.

> No it's not. It is manipulating information in Websocket frames just as if
> it were reframing.

If the intermediary is capable of unmasking WS frames then it is a
WebSocket server as per spec. The draft does not define other entities
capable of examining and unmasking WS frames so it MUST be a WS
server.

> The semantic content is left unchanged, and indeed is
> probably completely opaque to the intermediary. This would in no way

I insist:

- The draft defines a NEW protocol called WebSocket, and also defines
WS client and WS server.
- The draft defines how messages are sent between WS client and WS
server (and vice versa).
- The draft DOES NOT define what a "WS intermediary" is.
- So the draft MUST NOT rely on the existence of "WS intermediaries". Period.

All the people here talk about "intermediaries" (I mean "WS
intermediaries", and not IP routers or switches, please). How is
possible that all of you know what a WS intermediary is taking into
account that it has NEVER existed before and it's not defined by the
spec??? magic? telepathy?

Please, DEFINE "WS intermediary" in the draft and WHAT they can do at
WebSocket protocol level. Then you can add more text in the draft for
cases in which those ALREADY DEFINED WS intermediaries exist in the
path between the WS client and server.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 01:30:59 +0200

2011/9/15 Bruce Atherton <[email-masked]>:
> I know that you personally don't get what an intermediary is. You've said so
> many many times. But the spec uses the term no less than 11 times, so I
> think you need to accept that the spec does have something to say about
> intermediaries, whether you consider that valid or not.

The term "intermediary" appears 18 times in the draft (version 14).
Now please inspect the draft again and let me know where
"intermediary" is defined.

If does not matter whether the *WebSocket* specification talks 18 or
2000 times about "intermediaries at WebSocket protocol level", it MUST
define it as such term can ***only*** be defined in THIS spec (which
is about WebSocket protocol).

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

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 15 Sep 2011 09:49:27 +1000

> I'm strongly opposed to "unless allowed by local policy" language.  This makes the spec essentially contradict itself - the client section says "you MUST mask" but the server section implies that t…

I do not think this is contradictory.

Another way of phrasing this would be: "if the server is to not accept
a frame from the client because it is not masked, then it MUST use the
1008 policy violation close to do so."

It is not different to saying "the message body MUST be UTF-8 unless
the message is not a text message."

The ordering of the language is primarily for emphasis, ie having the
MUST before an unless, rather than an if before the MUST is actually
equivalent.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 15 Sep 2011 09:52:34 +1000

> "intermediary" is defined.

Iñaki,

intermediaries are defined by those exact same 18 mentions of what an
intermediary can or cannot do.

I see no need to restrict or define an intermediary in anyway more
than how it may or may not affect the protocol, simply because the
range of possible intermediaries is essentially infinite and we should
allow any, so long as they comply with the bounds we set in the spec.

regards

---

From: Joe Mason <[email-masked]>
Date: Wed, 14 Sep 2011 20:21:01 -0400

But the spec provides for binary messages, so saying, "a message must be UTF-8 unless it is not a text message" is consistent. It does not provide for client->server frames that aren't masked, so saying, "a frame received by the server must be masked, unless it is allowed to be unmasked" contradicts the section that says it is not allowed to be unmasked.

----- Original Message -----
From: Greg Wilkins [mailto:[email-masked]]
Sent: Wednesday, September 14, 2011 07:49 PM
To: Joe Mason
Cc: Bruce Atherton <[email-masked]>; Willy Tarreau <[email-masked]>; [email-masked] <[email-masked]>; Gabriel Montenegro <[email-masked]>
Subject: Re: [hybi] consensus call on c2s masking and decision on s2c masking

regards

---

From: Joe Mason <[email-masked]>
Date: Wed, 14 Sep 2011 20:38:05 -0400

The spec specifically covers the fact that intermediaries are allowed to change message fragmentation. It doesn't say anywhere that intermediaries are allowed to remove masking. I think that therefore intermediaries should not be allowed to remove masking.  If this IS to be allowed, it should be discussed in detail and not merely implied. (And I don't think we should add that capability now - too late in the process.)

If an intermediary changes websocket frames, it is still required to emit valid frames. A client->server frame with no mask is not valid.

----- Original Message -----
From: Bruce Atherton [mailto:[email-masked]]
Sent: Wednesday, September 14, 2011 06:42 PM
To: Joe Mason
Cc: Willy Tarreau <[email-masked]>; [email-masked] <[email-masked]>; Gabriel Montenegro <[email-masked]>
Subject: Re: [hybi] consensus call on c2s masking and decision on s2c masking

Intermediaries.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 15 Sep 2011 10:57:34 +1000

> But the spec provides for binary messages, so saying, "a message must be UTF-8 unless it is not a text message" is consistent. It does not provide for client->server frames that aren't masked, so s…

Saying it like this avoids having to restate any prohibition on
unmasked c2s frames.  the proposal is to say two things: a) Accepting
unmasked frames from a client is a matter of policy; b) For this
version of the specification the policy MUST NOT  (or SHOULD NOT)
allow unmasked c2s frames, but that this may change in future versions
of the specification.

On 15 September 2011 10:38, Joe Mason <[email-masked]> wrote:
> The spec specifically covers the fact that intermediaries are allowed to change message fragmentation. It doesn't say anywhere that intermediaries are allowed to remove masking. I think that therefore intermediaries should not be allowed to remove masking.  If this IS to be allowed, it should be discussed in detail and not merely implied. (And I don't think we should add that capability now - too late in the process.)  If an intermediary changes websocket frames, it is still required to emit valid frames. A client->server frame with no mask is not valid.

So we don't need to explicitly say that an intermediary must send
legal WS frames.  Even more so, we don't need to say that an
intermediary must not remove masking.  That is just adding layer upon
layer of redundant prohibitions.

If in some future version we explicitly allow the policies that allow
c2s unmasked frames, then people can then start writing intermediaries
that unmask and calling them compliant.

What we want to avoid is people seeing that the protocol itself
prohibits unmasked frames and thus to write intermediaries that assume
masking for all time.  If they do, then the policy to allow unmasked
frames will never be possible because we will have lots of deployed
intermediaries that assume it is not.

Hence we have language that says that frames may be masked or
unmasked, but that the current policy is to allow only masked frames.
Hopefully this will encourage implementations to be written in a
flexible way, so that the policy might be changed in the future if
need be.

regards

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Sep 2011 19:58:48 -0600

> is about WebSocket protocol).

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-16#section-2.4

Even RFC 2616 says:

   ... There are three common
   forms of intermediary: proxy, gateway, and tunnel. A proxy is a
   forwarding agent, receiving requests for a URI in its absolute form,
   rewriting all or part of the message, and forwarding the reformatted
   request toward the server identified by the URI. A gateway is a
   receiving agent, acting as a layer above some other server(s) and, if
   necessary, translating the requests to the underlying server's
   protocol. A tunnel acts as a relay point between two connections
   without changing the messages; tunnels are used when the
   communication needs to pass through an intermediary (such as a
   firewall) even when the intermediary cannot understand the contents
   of the messages.

I see no reason for the WebSocket spec to define, or redefine, the term.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Sep 2011 20:31:46 -0600

On 9/14/11 5:13 PM, Brian wrote:

> Honestly, I think it is perfectly acceptable to say that clients MUST
> mask outgoing frames, but servers MAY accept unmasked incoming frames.
>  The only clients that matter for the purposes of masking enforcement
> are the mainstream browsers, and there is no chance that they're going
> to allow their implementations to violate this point of the spec and
> ever send unmasked frames.  We do NOT need server enforcement on this
> point.  If there is an obscure non-browser client that doesn't mask
> frames then who cares?  That client doesn't in any way matter in terms
> of the vulnerability against which masking was meant to protect.  And
> the browser vendors certainly don't need any hand-holding by servers to
> make sure they stay on the straight-and-narrow when it comes to masking
> enforcement.

Personally (not with my AD hat on), I agree with Brian that it's fine to
say "client MUST NOT do X" and to refrain from saying "but if client
does X then server MUST do Y" (where Y is most likely closing the
connection). That leaves the server behavior up to the best judgment of
the implementer, which often is perfectly appropriate. As far as I can
see, that would imply something like the following:

OLD
   All frames sent from the client to the server are masked to
   avoid confusing network intermediaries, such as intercepting proxies.
   All frames sent from the server to the client are not masked.

NEW
   To avoid confusing network intermediaries (such as intercepting
   proxies), a client MUST mask all frames that it sends to the server.
   A server MUST NOT mask any frames that it sends to the client.

I see no particular reason to legislate that the client MUST close the
connection if it receives a masked frame, or that the server MUST close
the connection if it receives an unmasked frame. That said, it *might*
be helpful to mention somewhere that the appropriate error code to
return if you do close the connection is 1008.

Now, with my AD hat on, I'd like to see this group come to consensus,
and soon. I know that the original masking consensus was very difficult
to achieve. There are many reasons why it would be best to find a
consensus in this discussion that cleaves as closely as possible to the
original consensus. I strongly encourage the group to keep that in mind
as it wraps up this discussion.

Peter

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

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 15 Sep 2011 15:53:48 +1000

On 15 September 2011 12:31, Peter Saint-Andre <[email-masked]> wrote:
> and soon.

I think we are at rough consensus on the detail : clients MUST mask,
servers MUST NOT mask and if anybody violates either of those, then it
is a 1008 close.
But I think we are fighting over the exact form of wording to capture
that simple statement and to explain why.

So perhaps a minimal addition to your proposal:

  To avoid confusing network intermediaries (such as intercepting
  proxies), a client MUST mask all frames that it sends to the server.
  A server MUST NOT mask any frames that it sends to the client.
  If a server receives an frame without masking or a client receives a
  frame with masking, then the connection SHOULD be closed with
  1008 policy violation close code.

---

From: Brian <[email-masked]>
Date: Thu, 15 Sep 2011 00:04:29 -0700

>  1008 policy violation close code.

This is definitely closer to what I had in mind....  How about "MAY be
closed..."  :)

Server-side enforcement of client-to-server masking is not useful.  And the
client enforcing that the server sends only non-masked frames is likewise
pointless.

The clients that matter (browsers) will mask, unequivocally.  If the server
doesn't have to care about making sure that received messages are masked,
then compliant servers will be able to accept connections from non-compliant
clients that we're likely to see inside secure data centers.

Brian

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 10:34:56 +0200

> I see no reason for the WebSocket spec to define, or redefine, the term.

This is WebSocket protocol, not HTTP. I don't think that HTTP traffic
and WebSocket traffic (frames) are equivalent, not at all.

Regards.

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

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 15 Sep 2011 01:53:28 -0700

FWIW, I'm planning to add those options (default) to our implementation:

maskClientFrames (true)
requireMaskedClientFrames (true)
maskServerFrames (false)
acceptMaskedServerFrames (false)
applyMask (true)

With the defaults, the implementation behaves to the MUST / MUST NOT as
you describe - which I think makes perfect sense as default.

Should that make it into the final spec, the implementation is then conformant
with the defaults, but the user can override (on his own risk, making the running
program then potentially non-conformant).

In case of policy violation, whether a Close is sent or the connection is just dropped
is another option:

failConnectionWithClose (false)

The default with this last one is to make it behave like the browsers do currently.

The applyMask option is to allow for fake masking which for sending frames
sets the mask bit, insert a random/zero mask, but does not actually apply
the mask. For receiving, it switches off applying any mask present.

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> Greg Wilkins
> Gesendet: Donnerstag, 15. September 2011 07:54
> An: Peter Saint-Andre
> Cc: [email-masked]
> Betreff: Re: [hybi] consensus call on c2s masking and decision on s2c masking
> 
> I think we are at rough consensus on the detail : clients MUST mask, servers
> MUST NOT mask and if anybody violates either of those, then it is a 1008
> close.
> But I think we are fighting over the exact form of wording to capture that
> simple statement and to explain why.
>

---

From: "Len Holgate" <[email-masked]>
Date: Thu, 15 Sep 2011 11:03:44 +0100

> acceptMaskedServerFrames (false)

I already have this... And by default you get compliant clients and servers
but you can adjust if you really want to; much like the fact that I will
continue to sell my SSL layer separately and you can build clients and
servers with it if you want to purchase it or leave it out if it's not
important to you.

Len
http://www.serverframework.com

---

From: "Len Holgate" <[email-masked]>
Date: Thu, 15 Sep 2011 11:33:38 +0100

Not wanting to kick the ants nest again, but... 

If the concensus over c2s masking were that it IS acceptable to allow local
policy to dictate if c2s masking is used...

Then suddenly the deflate-stream extension might make sense again as a
potential option in 'no masking' situations...

Unlikely, I guess, since the intermediaries that would be doing the
heavy-lifting with regards to removing SSL and c2s masking would likely also
be the ones dealing with deflation as well.

Len

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 15 Sep 2011 03:35:35 -0700

> I already have this... And by default you get compliant clients and servers but

Nice. I like that approach: but compliant by default, but freedom of choice.

The more I contemplate about it, the more I think it's more precise to speak of

"the behavior of a program is compliant with a certain aspect of a spec"

than

"an implementation complies to a spec"

An implementation, whether source or object code, is just code. And code
not run is just bits.

And whether those bits when run exhibit compliant or non-compliant behavior
may depend on run-time options.

---

From: "Len Holgate" <[email-masked]>
Date: Thu, 15 Sep 2011 11:39:35 +0100

> may depend on run-time options.

Indeed. I also include deflate-stream functionality, since I had implemented
it and there's a slim chance that client's may want it, even though it's no
longer 'compliant' and only likely to be useful in 'non masking' situations.

Len

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 15 Sep 2011 03:42:41 -0700

> Unlikely, I guess, since the intermediaries that would be doing the heavy-
> lifting with regards to removing SSL and c2s masking would likely also be the
> ones dealing with deflation as well.

Speaking of _intermediaries_ and masking, I assume intermediaries are allowed to

1) change frame masking
2) fail connections due to masking policy violation

?

When I needed to implement a WS intermediary, I guess the spec wouldn't tell
me currently what exactly I am allowed.

For example, which of the following is MAY, MUST or SHOULD for server-to-client frames
and/or client-to-server frames processed by _intermediaries_:

  * Receive a masked frame, unmask the frame, remask with different frame and forward.

  * Receive a masked frame, unmask the frame and forward the frame unmasked.

  * Receive an unmasked frame, mask the frame and forward.

  * Coalesce two received unmasked frames into a masked frame and forward.

  * Coalesce two received masked frames into a masked frame with new mask (one of the
     original masks?) and forward.

  * Coalesce two received frames, one masked, one unmasked into a masked frame with
    new mask (the original mask of the one masked frame?) and forward.

  * Coalesce two received frames, one masked, one unmasked into an unmasked
   frame and forward.

  * Receive a masked frame, unmask the frame, fragment into two unmasked frames and forward.

  * Receive a masked frame, unmask the frame, fragment into two masked frames with
   new masks (the original mask of the unfragmented frame?) and forward.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 15 Sep 2011 12:06:01 +0100

Gabriel Montenegro wrote:

> The chairs in consultation with the editors and AD (Peter) have 
> thought about the recent suggestion to somehow relax masking from 
> client to server ("c2s"). This is not the first time this topic comes 
> up in the working group. Masking is the ONE point on which the WG has 
> spent the most cycles, blood and tears. It was VERY close to causing a 
> complete shutdown of this group. On a personal note, in well over a 
> decade of IETF participation, I (Gabriel) have never seen a harder 
> consensus than this one.
>
>  
>
> Furthermore, there is evidence of still strong feeling that we should 
> not revisit this point based on recent messages from Greg Wilkins, 
> John Tamplin, Ian Fette, Takeshi Yoshino. Of course, the feeling is 
> not unanimous. It never was. But it was the only position that allowed 
> the WG to continue. Because of this, the chairs would rather not 
> reopen this issue for debate (but see below). We arrived at a 
> consensus already and there's no new data or inputs that have not been 
> considered before that would warrant our revisiting that position.  
> Furthermore, we are concerned that a number of the working group 
> participants who were active in the original discussion on this topic 
> are no longer actively involved at this late stage in the process, and 
> we want to make sure that we honor their contributions to the hard-won 
> consensus earlier on.
>
>  
>
> Of course, a future version of websockets could tackle this issue, 
> just as there are other issues that we have recently earmarked for 
> future work. The truth is that we need deployment experience to know 
> more about some potential directions and acting now on these would be 
> premature.
>
>  
>
> As for the s2c masking direction. It was not entirely clear in the 
> draft whether it was *allowed* or not, nor was it made explicit at the 
> original consensus on masking (beyond the statement that masking was 
> not *required* in the s2c direction). In the interest of simplicity, 
> we are asking our editors to clarify that masking MUST NOT be done in 
> the server to client direction. We see reasonable support for this in 
> the mailing list.
>
>  
>
> S2C masking decision:
>
> Wednesday end-of-day to make sure we follow the due process. Option 1 
> is essentially the previous  consensus with the additional 
> clarification regarding potential future relaxation. This is what we 
> believe there is still consensus on. Option 2 is the proposal from 
> Richard Barnes to relax masking.
>
>  
>
> C2S masking OPTION 1:
>
My personal preference is for option 2, but I can live with option 1 if 
this will make the WG move forward.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 13:10:23 +0200

> 2) fail connections due to masking policy violation

Don't forget that an _intermediary_ is also allowed to:

3) Change the color of the frames.
4) Add the string "~·~LOVE~·~" at the end of UTF-8 text frames.
5) Tweet every WS message to Twitter.
6) Make a call to 112 for each binary frame received.

> me currently what exactly I am allowed.

The spec assumes that WebSocket is like HTTP world, full of
black-boxes to make HTTP protocol scalable. Those black-boxes are
called _intermediaries_ in the WS draft. "No need" to explain/describe
them since they are custom/proprietary stuff, and the fact that
WebSocket did not exist before and the term "WS intermediary" is
defined nowhere in the draft does not matter (all the people knows
what a "WS intermediary" is, period).

>   new masks (the original mask of the unfragmented frame?) and forward.

It depends on each black-box.

PS: I suggest to include the term "black-box" in the draft.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 13:11:58 +0200

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

I prefer option 1.

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

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 15 Sep 2011 04:26:05 -0700

...
> PS: I suggest to include the term "black-box" in the draft.

I agree with you: the draft lacks wrt intermediaries.

I agree with Greg

"intermediaries are defined by those exact same 18 mentions of what an intermediary can or cannot do."

that intermediaries should be defined in the spec by what _behavior_ they are allowed wrt WS.

I don't care what we call them (I'd be fine with blac-box;), and I don't care about a definition besides behavior.

But the behavior should be complete.

It is incomplete at least regarding

masking (in particular in conjunction with coalescing/fragmentation)
ordering guarantees (i.e. between control/data frames)

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Sep 2011 06:21:11 -0600

<hat type='individual'/>

> this will make the WG move forward.

In an ideal world -- and I think we can all agree that an ideal world
would not include thousands of email messages about masking :) -- I
would agree with you. In the messy world we inhabit, I incline toward
option #1.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Sep 2011 09:49:38 -0600

On 9/15/11 1:04 AM, Brian wrote:
> On Wed, Sep 14, 2011 at 10:53 PM, Greg Wilkins <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

WFM. So (with a few tweaks)...

  To avoid confusing network intermediaries (such as intercepting
  proxies), a client MUST mask all frames that it sends to the server.
  A server MUST NOT mask any frames that it sends to the client.
  If a server receives a frame without masking or a client receives a
  frame with masking, then it MAY close the connection with the 1008
  policy violation close code.

/psa

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 15 Sep 2011 16:22:03 +0000

Thanks folks, this consensus call is now closed. The chairs and AD will deliberate and communicate shortly to the group.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gabriel Montenegro
Sent: 09 September, 2011 13:17
To: [email-masked]
Subject: [hybi] consensus call on c2s masking and decision on s2c masking

S2C masking decision:

C2S masking OPTION 1:

C2S masking OPTION 2:

Thanks,

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Sep 2011 09:24:16 -0700

For the record, I certainly don't agree with this MAY, nor do I agree that it
in any way reflects consensus.

-ekr

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 15 Sep 2011 18:35:26 +0000

Right, this MAY contradicts current text in section 5.3, but see my next message.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Rescorla
> Sent: 15 September, 2011 09:24
> To: Peter Saint-Andre
> Cc: [email-masked]; Greg Wilkins

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 15 Sep 2011 18:40:23 +0000

Salvatore, Peter and I agree and communicate consensus that we're going with Option 1:

C2S masking OPTION 1:

There was no earth-shattering reason to change from this, which was our previous consensus. WG sentiment was somewhat more favorable to option 1. Besides, some of those on option 2 were flexible about option 1 (at least Bruce and Alexey). However, the contrary was not true.

I include the informal tally at the very end of this message, this was one of the helpful inputs in our decision.

Here are the final changes to the spec to clarify the above (including s2c masking).

Section 5.1:

OLD

   In the WebSocket protocol, data is transmitted using a sequence of

   frames.  All frames sent from the client to the server are masked to

NEW

   In the WebSocket protocol, data is transmitted using a sequence

   of frames.  To avoid confusing network intermediaries (such as

   intercepting proxies) and for security reasons that are further

   discussed in Section 10.3, a client MUST mask all frames that it

   sends to the server (see section 5.3 for further details).  The

   server MUST close the connection upon receiving a frame that is

   not masked.  In this case, a server MAY send a close frame with a

   status code of 1002 (protocol error) as defined in Section 7.4.1.  A

   server MUST NOT mask any frames that it sends to the client.  A

   client MUST close a connection if it detects a masked frame.  In

   this case, it MAY use the status code 1002 (protocol violation) as

   defined in Section 7.4.1.  (These rules might be relaxed in a future

   specification.)

Section 5.3 : remove the first paragraph

Thanks,

Gabriel and Salvatore

Ps - the informal tally is:

Not Clear:

*        Alexander Philippou <[email-masked]>

Neutral:

*        John Tamplin <[email-masked]>

*        "Martin J. Dürst" <[email-masked]>

Option 1 (strict masking):

*        Eric Rescorla <[email-masked]>

*        Adam Barth <[email-masked]>

*        Brian <[email-masked]>

*        Patrick McManus <[email-masked]>

*        Willy Tarreau <[email-masked]>

*        Joel Martin <[email-masked]>

*        Justin Lee <[email-masked]>

*        Joe Mason <[email-masked]>

*        Piotr Kulaga <[email-masked]>

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

*        Peter Saint-Andre <[email-masked]>

Option 2 (relaxed masking):

*        Richard L. Barnes <[email-masked]>

*        Greg Wilkins <[email-masked]>

*        Julian Reschke <[email-masked]>

*        Bruce Atherton <[email-masked]>

*        David Endicott <[email-masked]>

*        Alexey Melnikov <[email-masked]>

S2C masking decision:

C2S masking OPTION 1:

C2S masking OPTION 2:

Thanks,

---

From: John Tamplin <[email-masked]>
Date: Thu, 15 Sep 2011 14:43:08 -0400

On Thu, Sep 15, 2011 at 2:40 PM, Gabriel Montenegro <
[email-masked]> wrote:

>  NEW
>
>    In the WebSocket protocol, data is transmitted using a sequence ****
>
>    of frames.  To avoid confusing network intermediaries (such as ****
>
>    intercepting proxies) and for security reasons that are further ****
>
>    discussed in Section 10.3, a client MUST mask all frames that it ****
>
>    sends to the server (see section 5.3 for further details).  The ****
>
>    server MUST close the connection upon receiving a frame that is ****
>
>    not masked.  In this case, a server MAY send a close frame with a ****
>
>    status code of 1002 (protocol error) as defined in Section 7.4.1.  A **
> **
>
>    server MUST NOT mask any frames that it sends to the client.  A ****
>
>    client MUST close a connection if it detects a masked frame.  In ****
>
>    this case, it MAY use the status code 1002 (protocol violation) as ****
>
>    defined in Section 7.4.1.  (These rules might be relaxed in a future **
> **
>
>    specification.)
>

Why the different parenthetical explanations of status code 1002?

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Sep 2011 12:44:29 -0600

On 9/15/11 12:43 PM, John Tamplin wrote:
> On Thu, Sep 15, 2011 at 2:40 PM, Gabriel Montenegro
> <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     NEW
> 
>        In the WebSocket protocol, data is transmitted using a sequence ____
> 
>        of frames.  To avoid confusing network intermediaries (such as ____
> 
>        intercepting proxies) and for security reasons that are further ____
> 
>        discussed in Section 10.3, a client MUST mask all frames that it ____
> 
>        sends to the server (see section 5.3 for further details).  The ____
> 
>        server MUST close the connection upon receiving a frame that is ____
> 
>     ____
>        status code of 1002 (protocol error) as defined in Section
>     7.4.1.  A ____
> 
>        server MUST NOT mask any frames that it sends to the client.  A ____
> 
>        client MUST close a connection if it detects a masked frame.  In ____
> 
>        this case, it MAY use the status code 1002 (protocol violation)
>     as ____
> 
>        defined in Section 7.4.1.  (These rules might be relaxed in a
>     future ____
> 
>        specification.)
> 
> 

That looks like a typo.

Peter

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

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 15 Sep 2011 18:46:58 +0000

Right, they should both be "protocol error"

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: 15 September, 2011 11:44
> To: John Tamplin
> Cc: Gabriel Montenegro; [email-masked]

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 15 Sep 2011 21:47:43 +0300

>> Why the different parenthetical explanations of status code 1002?
just a cut and past error.
1002 indicates a protocol error as stated in 7.4.1

/Sal

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Sep 2011 12:48:23 -0600

> Right, they should both be "protocol error"

Fixed in the RFC Editor notes:

https://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/writeup/

Peter

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

---

From: Joe Mason <[email-masked]>
Date: Thu, 15 Sep 2011 16:41:48 -0400

> Sent: Wednesday, September 14, 2011 8:58 PM
> To: Joe Mason
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]

I agree that this is what the spec should impart, but the language given doesn't say that to me.  I find it unclear enough that I think it will cause confusion. 

Since these two lines are so close together, I don't see the problem with restating the prohibition on unmasked c2s frames.  I would prefer:

Clients MUST mask frames they send.
Servers MUST respond to unmasked frames they receive with error code 1008 (Policy Violation).

(Possibly with a "Rationale" below explaining why this is a policy violation, and not a protocol violation, and stating that this policy may be relaxed in future versions.)

If we allow unmasked client frames in a later version, the "Clients MUST" line will need to be updated, so there's not much chance of forgetting to update the "Servers MUST" line at the same time.

> layer of redundant prohibitions.

Agreed.  That's why I think it's important to be clear that servers MUST reject masked frames - otherwise it's undefined whether intermediaries can remove masking.

> intermediaries that assume it is not.

That's a good point.  That's definitely an assumption I could see intermediaries making.  How about adding:

Intermediaries SHOULD handle unmasked frames being passed from client to server, so that if the above requirements are relaxed in a future version of this spec they will remain compatible.

Joe

---

From: Joe Mason <[email-masked]>
Date: Thu, 15 Sep 2011 16:45:27 -0400

As a minor nit, the new paragraph says "1002 (protocol error)" once and "1002 (protocol violation)" once.  It should be consistent as "protocol error".

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gabriel Montenegro
Sent: Thursday, September 15, 2011 2:40 PM
To: [email-masked]
Subject: Re: [hybi] consensus call on c2s masking and decision on s2c masking

C2S masking OPTION 1:

Section 5.1:

OLD

NEW

   specification.)

Thanks,

Gabriel and Salvatore

Not Clear:

Neutral:

S2C masking decision:

C2S masking OPTION 1:

C2S masking OPTION 2:

Thanks,

---

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

On 9/15/11 2:45 PM, Joe Mason wrote:
> As a minor nit, the new paragraph says “1002 (protocol error)” once and
> “1002 (protocol violation)” once.  It should be consistent as “protocol
> error”.

That's already been noted and fixed.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 16 Sep 2011 08:43:55 +1000

For the record, I object to the addition of the 1002 code being made
part of the consensus call for option 1.

The 1002 code was not given as part of the option 1 as originally
proposed by this call.
I asked for clarification for 1002 vs 1008
The 1008 code was widely supported and I saw nobody speak up for a 1002.
Many that preferred option 2 were flexible towards option 1 on the
basis of a 1008 code.

My own reading of the thread is that there was rough consensus around
options 1 + 1008 code

But I'll respect the call of the chairs and let this rest.

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 15 Sep 2011 23:07:49 +0000

The consensus call was on changes to the spec. 1002 is already in the spec per the previous consensus call (and now confirmed with option 1):

In section 5.3, first paragraph:
   The client MUST mask all frames sent to the server.  This is required
   for security reasons which are further discussed in Section 10.3.  A
   server MUST close the connection upon receiving a frame with the MASK
   bit set to 0.  In this case, a server MAY send a close frame with a
   status code of 1002 (protocol error) as defined in Section 7.4.1.

All that was done in the final text was to move that paragraph and existing text up to 5.1, and massage it to *also* talk about s2c masking (which was underspecified before). We aligned s2c with the previous text (now confirmed via option 1) on c2s.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg
> Wilkins
> Sent: Thursday, September 15, 2011 15:44
> To: Gabriel Montenegro
> Cc: [email-masked]
> For the record, I object to the addition of the 1002 code being made part of the
> consensus call for option 1.
> 
> The 1002 code was not given as part of the option 1 as originally proposed by
> this call.
> I asked for clarification for 1002 vs 1008 The 1008 code was widely supported
> and I saw nobody speak up for a 1002.
> Many that preferred option 2 were flexible towards option 1 on the basis of a
> 1008 code.
> 
> My own reading of the thread is that there was rough consensus around options
> 1 + 1008 code
>

---

From: Brian <[email-masked]>
Date: Thu, 15 Sep 2011 18:28:37 -0700

Would someone care to speak up as to why we should care whether or not
servers enforce this?  IMO there's no useful reason in practicality because
the browsers are the both the only attack vector where masking is necessary
and were also the ones who felt that the masking must be strictly mandatory.
 The fine people implementing their respective browsers at Microsoft, Apple,
Opera, Mozilla, and Google are more than competent enough, and they don't
need a bunch of random server implementations holding their feet to the fire
to make sure they implement client-to-server masking correctly.

As for all the other non-browser clients out there... it really doesn't
matter whether they mask -- protocol violation or not.  *Only major
browsers* pose a security risk worth considering by not masking.
 Furthermore, by the time a server has received the data and has the
opportunity to close the connection, any potential attack has already been
executed.  There is absolutely no practicable security gain to be had by
requiring that servers enforce client-to-server masking.

To honor the original consensus, I was in favor of keeping option 1 in terms
of strict wording that the clients MUST mask outgoing data.  I'm certainly
not, however, in favor of making the servers enforce it.  If they decide
they want to enforce it, that's nice, and there should be a standard error.
 But it would be far easier and better for everyone moving forward (to the
golden era when we don't need client-to-server masking) if they didn't
bother.  Servers should rely on the mask bit in the header to determine
whether to unmask the frame, and leave it at that.

Brian

On Thu, Sep 15, 2011 at 4:07 PM, Gabriel Montenegro <
[email-masked]> wrote:

> The consensus call was on changes to the spec. 1002 is already in the spec
> per the previous consensus call (and now confirmed with option 1):
>
> All that was done in the final text was to move that paragraph and existing
> text up to 5.1, and massage it to *also* talk about s2c masking (which was
> underspecified before). We aligned s2c with the previous text (now confirmed
> via option 1) on c2s.
>
> Greg
> proposed by
> options

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Sep 2011 07:31:44 +0200

> Brian

Well said!

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Sep 2011 02:21:59 -0600

On 9/15/11 7:28 PM, Brian wrote:
> servers enforce this?  IMO there's no useful reason in practicality
> because the browsers are the both the only attack vector where masking
> is necessary and were also the ones who felt that the masking must be
> strictly mandatory.  The fine people implementing their respective
> browsers at Microsoft, Apple, Opera, Mozilla, and Google are more than
> competent enough, and they don't need a bunch of random server
> implementations holding their feet to the fire to make sure they
> implement client-to-server masking correctly.
> 
> opportunity to close the connection, any potential attack has already
> been executed.  There is absolutely no practicable security gain to be
> had by requiring that servers enforce client-to-server masking.
> 
> To honor the original consensus, I was in favor of keeping option 1 in
> terms of strict wording that the clients MUST mask outgoing data.  I'm
> certainly not, however, in favor of making the servers enforce it.  If
> they decide they want to enforce it, that's nice, and there should be a
> standard error.  But it would be far easier and better for everyone
> moving forward (to the golden era when we don't need client-to-server
> masking) if they didn't bother.  Servers should rely on the mask bit in
> the header to determine whether to unmask the frame, and leave it at that.

Section 5.3 of draft-ietf-hybi-thewebsocketprotocol-14 already states:

The same or substantially similar text can be found all the way back in
version 7 from April. Thus the server enforcement aspect already had
consensus in the working group as far as we (chairs and AD) could see.
We tried to make the least intrusive changes to the spec as it stands
today (version -14) based on the recent discussion.

Peter

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 16 Sep 2011 12:11:35 -0400

+1

---

From: Patrick McManus <[email-masked]>
Date: Fri, 16 Sep 2011 13:23:50 -0700

On 9/15/11 6:28 PM, Brian wrote:
> servers enforce this?
Because it enhances the confidence that all websockets flows will carry 
this property regardless of context.

And I've observed that technologists are not very good about always 
knowing when a context is safe or not for the large combinations of 
technology layered in their designs. The IETF should be building 
protocols that are safe in as many contexts as possible so they don't 
rely on the coordination of people that may very well abstract these 
details away.

I lament that I was not in the camp of SSL-only early on. I would be 
now. Sure it is expensive, but its a cost worth paying.

-Patrick

[I failed to cc: the list the first time I sent this - sorry for the 
repeat Brian]