Re: [hybi] requirement draft as wg item

[Greg Wilkins <[e-mail]>]

Thomson, Martin wrote:
> Reading through this, it would be easier to maintain if the requirements were numbered separately by section:
> 
> E.g. C1, C2 for client, S1, S2, S3 for server, X1, X2 for security.


I agree - does anybody object if I reformat the document to make
requirements number subsections?  Maceij?




> Regarding the following security requirement: 
> 
>    REQ. 17:  The WebSocket Protocol MUST use the Origin-based security
>       model commonly used by Web browsers to restrict which Web pages
>       can contact a WebSocket sever when the WebSocket protocol is used
>       from a Web page.
> 
> It seems that _using_ this model is not what the protocol does.  "Supporting" might be a better choice.  The attacks that are foiled by the same model are foiled by the browser and its security policy, not the protocol.  Same comment for the next requirement.

This was an issue raised at the meeting and where it was pointed out
that there is no specification for "Origin-based security model".

I believe the chairs intend to open a trac issue for this once
we've got the process of dealing with tracs established.

Personally I think this is not so much a requirement on the
protocol, but on the websocket API implementation.  As you say,
the protocol needs only support the security policy implemented
by it's containing scope (ie the browser).




> I'm still not satisfied by the discussion on protocol mimickry.  That needs a much longer explanation than the one given.  Also, this:
> 
>    REQ. 19:  WebSocket should be designed to be robust against cross-
>       protocol attacks.  The protocol design should consider and
>       mitigate the risk presented by WebSocket clients to existing
>       servers (including HTTP servers).  It should also consider and
>       mitigate the risk to WebSocket servers presented by clients for
>       other protocols (including HTTP).
> 
> Could be more simply worded as two requirements:
> 
>   REQ X-.  An HTTP request MUST be difficult for a WebSocket server to mistake for a WebSocket handshake.
> 
> With much more explanation.  A simple scenario (as Ian provided me recently) would go a long way.  Similarly:
> 
>   REQ X-. A WebSocket handshake MUST be difficult for an HTTP server to mistake for a valid HTTP request.
> 
> ...with a similar degree of justification.  (Random thought: requiring Content-Length: 0 might be a price worth paying here.)

Nice - much simpler.