Subject: [hybi] requirement draft as wg item

From: Salvatore Loreto <[email-masked]>
Date: Tue, 11 May 2010 18:07:49 +0300

Hi,

I want let you know that Greg and Maciej have agreed to take on the 
editorship of the requirement draft,
and yesterday they have submitted it as wg item.
The 00 version is substantially the version that has been discussed 
during the face to face meeting
in Anaheim.

http://tools.ietf.org/html/draft-ietf-hybi-websocket-requirements-00

cheers
Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 12 May 2010 15:00:55 +0800

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.

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.

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

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Salvatore Loreto
> Sent: Wednesday, 12 May 2010 1:08 AM
> To: [email-masked]
> Subject: [hybi] requirement draft as wg item
> 
> Hi,
> 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 13 May 2010 00:04:50 -0700

> E.g. C1, C2 for client, S1, S2, S3 for server, X1, X2 for security.

Sounds like a good change. Does anyone object?

> 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 pol…

Instead of "use" or "support" I think the right verb phrase would be "MUST work with" or "MUST be compatible with". It's a matter of fitting into the model. It's not clear what it means to use or suport it.

> ...with a similar degree of justification.  (Random thought: requiring Content-Length: 0 might be a price worth paying here.)

Splitting it into two requirements is reasonable, but I think something more like the original wording will be easier for security reviewers to understand.

Regards,
Maciej

---

From: Mike Belshe <[email-masked]>
Date: Thu, 13 May 2010 02:09:06 -0700

A few questions:
* Does requirement 1, stating the WebSocket must run on top of a transport
protocol inhibit use of WebSockets on top of any other protocols like SPDY?
Is that an intended consequence?

* Requirement 11 refers to a "sub-protocol", but "sub-protocol" is not
defined. I am not meaning to be difficult, but I am not sure what does or
does not qualify as as sub-protocol.

Mike

On Tue, May 11, 2010 at 8:07 AM, Salvatore Loreto <
[email-masked]> wrote:

> The 00 version is substantially the version that has been discussed during
> the face to face meeting
> in Anaheim.
>

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 May 2010 12:02:09 +0200

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

> 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 pol…

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

> ...with a similar degree of justification.  (Random thought: requiring Content-Length: 0 might be a price worth paying here.)

Nice - much simpler.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 May 2010 15:18:30 +0200

Mike Belshe wrote:
> A few questions:
> * Does requirement 1, stating the WebSocket must run on top of a
> transport protocol inhibit use of WebSockets on top of any other
> protocols like SPDY? Is that an intended consequence?

I think there is a lot of confusion between websockets the wire protocol
and websockets the browser feature.

I think it would make little sense to carry websockets the protocol
over SPDY, but a lot sense to carry websockets the browser feature
over SPDY.

I've previously suggested that we name the protocol WSTP for
Websocket Transport Protocol, so that it would be much clearer
when we are talking about the browser feature and when we are talking
about the wire protocol.

However, I think that REQ.1 could be better phrased.   Maybe something
like: The WebSocket Protocol MUST rund directly on top of TCP or
equivalent transport mechanism ?

> defined. I am not meaning to be difficult, but I am not sure what does
> or does not qualify as as sub-protocol.

I agree and I also don't yet understand exactly what we all mean by
subprotocol

I'm not even sure there is a requirement for subprotocols.  It might
just be a nice to have feature of a particular solution.

regards

---

From: Scott Ferguson <[email-masked]>
Date: Thu, 13 May 2010 09:03:17 -0700

> just be a nice to have feature of a particular solution.
It allows validation for applications, just like normal version numbers.

If you have an iPhone client talking quake/1.0 packets to a server, but 
the server is actually using an incompatible quake/2.0 packet syntax, 
it's useful to address that issue upfront as part of the handshake. 
(Plus allowing easy rejection of a quake/1.0 client trying to talk with 
an xmpp/2.0 server with a reasonable error message.)

You could always force the application to validate its own version in a 
separate handshake, but it's a universal need so has value here.

The "sub-protocol" really means the full protocol stack. "sub-" just 
meaning it's built on top of WebSockets, i.e. that the full protocol is 
one of the possible protocols that could be designed on top of WebSockets.

-- Scott