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

[Takeshi Yoshino <[e-mail]>]

[masking bit]

On Fri, Sep 9, 2011 at 00:14, John Tamplin <[e-mail]> wrote:

> On Thu, Sep 8, 2011 at 11:06 AM, Richard L. Barnes <[e-mail]>
>  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.
>
>
I'm fine with MASK bit. I just told the history.


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

Yes.


>  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.
>>
>>
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 <[e-mail]> wrote:

> On Thu, Sep 8, 2011 at 11:36 AM, Joel Martin <[e-mail]> 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
>> indicate possible future direction.
>>
>
> 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 (イアンフェッティ) <[e-mail]>
 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
> 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.
>

On Fri, Sep 9, 2011 at 02:45, John Tamplin <[e-mail]> wrote:

> On Thu, Sep 8, 2011 at 12:37 PM, Richard L. Barnes <[e-mail]>
>  wrote:
>
>>
>> On Sep 8, 2011, at 12:28 PM, John Tamplin wrote:
>>
>>>  If we do go with this, I would prefer an additional statement for
>>> client->server, stating that if the client 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.
>>
>
> 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.
>

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

On Fri, Sep 9, 2011 at 03:18, Tobias Oberstein <[e-mail]>
 wrote:

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

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]

On Fri, Sep 9, 2011 at 00:06, Richard L. Barnes <[e-mail]> wrote:

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

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"