Subject: [hybi] draft-loreto-hybi-requirements

From: Salvatore Loreto <[email-masked]>
Date: Tue, 23 Feb 2010 21:37:09 +0200

Hi there,

as announced in the "WG kick-off" mail and also written in the charter, 
we have the following goal:

    Apr 2010 - Submit a document as a working group item describing the Web Socket requirements
                (draft-hixie-thewebsocketprotocol  <http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-hixie-thewebsocketprotocol>  will be used as a starting point for further work.)

Having a defined set of requirement written down, is to prevent people 
to continuously argue for more features to be supported by the protocol.
It is expected that the major part of the requirement will be already 
solved by the current version of the protocol, and only few will need some
extra protocol definition.

here a first basic list of requirements I have extrapolated from the 
draft-hixie-thewebsocketprotocol

     http://www.ietf.org/id/draft-loreto-hybi-requirements-00.txt

of course I might have missed something, but I have tried carefully not 
to add anything!
I look forward to see your comments and feedbacks.

As chair, I will maintain editorship of the draft, with a goal of naming 
editors at (or soon after) IETF 77
  - If you are interested in editing either of those drafts, please 
email the chairs off-list.

cheers
Sal

Salvatore Loreto
www.sloreto.com

---

From: Ian Hickson <[email-masked]>
Date: Tue, 23 Feb 2010 18:39:22 -0800

On Tue, Feb 23, 2010 at 11:37 AM, Salvatore Loreto
<[email-masked]> wrote:
> of course I might have missed something, but I have tried carefully not to
> add anything!

The requirements in the draft above seem very low-level — for example
"The Web Socket Protocol MUST run directly on top of TCP transport
protocol." seems to assume a particular solution, rather than state a
problem. We could have designed the protocol to use UDP. Similarly,
"Textual data MUST be encoded as UTF-8." doesn't seem to be a
requirement, so much as a design choice. We could design the protocol
to use EBCDIC, or we could say that every even character is encoded as
ISO-9959-1 and every odd character uses UTF-16LE, for example. These
would probably not be a particularly good choices, but I don't see how
we could say that the problem _requires_ that we use UTF-8.

FWIW, the requirements that led to WebSocket's current design were
sent to the list very early on:

   http://www.ietf.org/mail-archive/web/hybi/current/msg00007.html

To this list I would add a few things that weren't considered then,
for example that it be possible to reuse existing infrastructure to on
the server-side without requiring that entirely new server-side
intermediaries be deployed, and that it not be possible to send data
to a simple server-side implementation of this new protocol from Web
platform features such as XHR or <form>s.

HTH,
-- 
Ian Hickson

---

From: SM <[email-masked]>
Date: Tue, 23 Feb 2010 23:07:48 -0800

>     http://www.ietf.org/id/draft-loreto-hybi-requirements-00.txt

The Intended Status should be Informational.  If this is a WG 
document, it should be renamed to draft-ietf-hybi-requirements.

According to the Abstract, the document considers the requirements 
and resulting features needed for the design of the WebSocket 
Protocol.  That's not stated in the Introduction section.  Section 3 
discusses about WebSocket requirements.  If the protocol has already 
been identified, it could be mentioned in the introduction.

Requirement 1 mentions that the protocol must run directly on top of 
TCP.  If the protocol is going to share a port with HTTP, it follows 
that the protocol should designed in such a way that it follows HTTP 
requirements.  Some of the points in 
draft-loreto-http-bidirectional-01 could be used as a basis for the 
requirements.

As WebSocket has already been identified as input, I assume that it 
already fulfills some of the requirements.  What are the problem 
areas of that protocol?  What constraints should be met by the 
protocol or its variant?  For example, if you say that it has to work 
over port 80, the protocol will either have to use HTTP Upgrade or 
Connect.  What is the impact on existing infrastructure?

Requirement 14 specifies that the protocol must use the origin-based 
security model.  The next requirement specifies an equivalent 
security model.  I gather that the security model should be 
equivalent to a same-origin policy.

Regards,
-sm

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 24 Feb 2010 07:46:47 -0700

> document, it should be renamed to draft-ietf-hybi-requirements.

Informational makes sense, but we'll rename it only after we have WG
consensus that the doc is on the right path and we have a non-chair to take
over as editor.

-- 
Joe Hildebrand
(as chair)

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 24 Feb 2010 17:26:05 +0200

Hi Ian,

thanks for the comments...
I have written down the draft as a strawman proposal to start the discussion
on the requirements and features the Web Socket protocol should 
respectively meet and support

more in line

/Sal

On 02/24/2010 04:39 AM, Ian Hickson wrote:
> The requirements in the draft above seem very low-level --- for example
[Sal] I agree that those requirements seem to assume a particular solution.
So if there is no particular reason the protocol should mandate

	REQ. 4:  Textual data MUST be encoded as UTF-8.

we can remove it from the requirement list.
However before do that I'd like understand the reason
why that design choice has been taken ... and why all the other alternatives
have been discarded.

about:

    REQ. 1:  The Web Socket Protocol MUST run directly on top of TCP
       transport protocol.

you are right, it should be even more general like "MUST work directly 
on top of transport protocols"
and the reason for that requirement is to

>     http://www.ietf.org/mail-archive/web/hybi/current/msg00007.html
[Sal] actually I have considered them while writing the draft
> intermediaries be deployed,
[Sal] while I agree that we should consider existing infrastructure on 
the sever side
(and actually I would go further saying also intermediaries)
I would understand better what you have in mind...
is it perhaps something like

    "it should be possible for the protocol reuse the existing web
    infrastructure (only server side or also intermediaries?)
    and coexist there smoothly with HTTP" ?

> and that it not be possible to send data
> platform features such as XHR or<form>s.
>    
[Sal] it smell as a security requirements. Can you elaborate and 
generalize it a little more?

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 24 Feb 2010 17:44:56 +0200

Hi,

thanks for the comments

see in line

ciao
/Sal

Salvatore Loreto
www.sloreto.com

> that the protocol should designed in such a way that it follows HTTP
[Sal] I (as individual) tend to agree
>   Some of the points in
> already fulfills some of the requirements.
[Sal] the draft intention is not only to extrapolate the requirements that
WebSocket protocol already fulfils,
but also a way to identify what we want from the protocol write down 
clearly.
>    What are the problem
> protocol or its variant?
[Sal] those are exactly the questions that I would like to see discussed 
here.
> For example, if you say that it has to work
[Sal] impact on existing infrastructure is something we have to consider 
carefully.
during the BoF there was some discussion about the opportunity to use or 
not port 80 and 443
but not a clear decision or consensus.
So this is something that need to be also decided.

> equivalent to a same-origin policy.
[Sal] yes we can generalize it in only one requirement:

	"the security model should be equivalent to a same-origin policy."

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

---

From: SM <[email-masked]>
Date: Wed, 24 Feb 2010 11:34:42 -0800

At 07:44 24-02-10, Salvatore Loreto wrote:
>but also a way to identify what we want from the protocol write down clearly.

BTW, I read this as a strawman's proposal (as mentioned in another 
message), i.e. a starting point to identify the requirements.

>why that design choice has been taken ... and why all the other alternatives

You'll need an internationalization consideration in the 
specifications even if it is not part of the requirements.

>[Sal] while I agree that we should consider existing infrastructure 
>on the sever side

If the protocol has to coexist with existing web infrastructure, 
there is no need to set a transport protocol requirement in this draft.

Regards,
-sm

---

From: Ian Hickson <[email-masked]>
Date: Wed, 24 Feb 2010 20:47:08 +0000 (UTC)

>    infrastructure (only server side or also intermediaries?)

As far as I can tell the discussion has been specifically about 
intermediaries on the server side. It's not clear to me how we can reuse 
man-in-the-middle intermediaries. I suppose we should use client-side 
intermediaries too (like SOCKS proxies).

>    and coexist there smoothly with HTTP" ?

Not necessarily HTTP; if we could come up with a solution that worked 
better but was based on, say, HTTP, or that was a completely new protocol, 
then I don't see why we couldn't use it.

> [Sal] it smell as a security requirements. Can you elaborate and generalize it
> a little more?

For example, it shouldn't be vulnerable to the attacks Maciej has 
described.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 25 Feb 2010 15:21:42 +0900

Hello Joe, others,

On 2010/02/24 23:46, Joe Hildebrand wrote:
> On 2/24/10 12:07 AM, "SM"<[email-masked]>  wrote:
>

As far as I understand, we have a WG deliverable to produce a 
requirements document. Unless there are other, separate requirements 
documents, I propose that we adopt this as a WG draft ASAP.

Content-wise, I agree with most of the points that Ian and others have 
made, but that shouldn't hold us back to adopt WG drafts. It will 
definitely help discussion; indeed in general a WG discusses WG drafts, 
not others. Also, the editorship can be solved later; it's not a problem 
at all because once the draft is a WG draft, the editor's name doesn't 
appear in the draft name anymore. Doing this would also mean that we 
would get ahead of our deadlines, which wouldn't be a bad thing.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: SM <[email-masked]>
Date: Thu, 25 Feb 2010 07:00:31 -0800

At 22:21 24-02-10, Martin J. Dürst wrote:
>As far as I understand, we have a WG deliverable 
>to produce a requirements document. Unless there 
>are other, separate requirements documents, I 
>propose that we adopt this as a WG draft ASAP.

I second that proposal.

>Content-wise, I agree with most of the points 
>that Ian and others have made, but that 
>shouldn't hold us back to adopt WG drafts. It 
>will definitely help discussion; indeed in 
>general a WG discusses WG drafts, not others. 
>Also, the editorship can be solved later;

It would be more productive to discuss about WG 
drafts as that is what a WG is supposed to do.

Regards,
-sm

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 25 Feb 2010 10:46:17 -0700

>> propose that we adopt this as a WG draft ASAP.

Are there any *objections* to draft-loreto-hybi-requirements-00 becoming
draft-ietf-hybi-requirements-00, with the understanding that the contents
*will* change over time as we haggle over the actual requirements?

-- 
Joe Hildebrand
(as chair)

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Feb 2010 18:48:27 +0100

On 25.02.2010 07:21, "Martin J. Dürst" wrote:
> ...

+1

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 25 Feb 2010 21:14:50 +0200

Hi Ian,

comments in line

thanks
/Sal

On 02/24/2010 10:47 PM, Ian Hickson wrote:
> intermediaries on the server side.
[Sal] sorry to ask, but what do you exactly mean for intermediaries on 
the server side?

> It's not clear to me how we can reuse
[Sal] when I say coexist, I do not mean that it should be based on HTTP.
but that if HTTP and the WebSocket protocols exist at the same time in 
the same
place (e.g. in the client side or in the server side) they do not harm 
each other
in any possible way

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 25 Feb 2010 21:21:33 +0200

> For example, it shouldn't be vulnerable to the attacks Maciej has
[Sal] the best way I can think of a general requirement for the attacks 
Maciej has described is something like:

    [Req. X] it should be possible for a Web Socket server discriminate
    between a plain HTTP request
    and a HTTP request used do establish a WebSocket connection.

however a requirements like that would implicitly assume the usage of a 
specific form the handshake:
the one based on HTTP and Upgrade.

(if someone has a better text, please provide it)

Folks, any objection to a requirement like this?

/Sal

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 25 Feb 2010 12:52:40 -0700

> *will* change over time as we haggle over the actual requirements?

No objections here.

Peter

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

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 25 Feb 2010 12:12:21 -0800

On Feb 25, 2010, at 11:21 AM, Salvatore Loreto wrote:
> [Sal] the best way I can think of a general requirement for the  
> attacks Maciej has described is something like:
>
> however a requirements like that would implicitly assume the usage  
> of a specific form the handshake:

I think we should have security requirements, but that way of phrasing  
it seems a little indirect. I would phrase it like this:

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

That's not specific about how to solve the problem, but it is very  
clear about the areas of risk.

Regards,
Maciej

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 25 Feb 2010 22:36:02 +0200

On 02/25/2010 10:12 PM, Maciej Stachowiak wrote:
>>     [Req. X] it should be possible for a Web Socket server
>>     discriminate between a plain HTTP request
>> however a requirements like that would implicitly assume the usage of 
>> a specific form the handshake:
> Requirement: 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).
>

thanks Maciej,
how you have re-phrased is great.

so again folks, any objection to include this requirement as phrased by 
Maciej ?

Cheers
/Sal

---

From: Roberto Peon <[email-masked]>
Date: Thu, 25 Feb 2010 12:42:25 -0800

So long as it doesn't imply incompatibilities with HTTP *before* the end of
the 101 response.

I'd propose the above as another requirement, but it seems we're still
debating that idea.
Certainly my support for any security measures hinges on whether or not it
implies incompatibilities to HTTP.
-=R

On Thu, Feb 25, 2010 at 12:36 PM, Salvatore Loreto <
[email-masked]> wrote:

> [Req. X] it should be possible for a Web Socket server discriminate between
> a plain HTTP request
> I think we should have security requirements, but that way of phrasing it
> seems a little indirect. I would phrase it like this:
>
> 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).
>
>  That's not specific about how to solve the problem, but it is very clear
> about the areas of risk.
>
>  Regards,
> Maciej
>
>
> thanks Maciej,

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 25 Feb 2010 13:31:16 -0800

On Feb 25, 2010, at 12:42 PM, Roberto Peon wrote:

> So long as it doesn't imply incompatibilities with HTTP *before* the  
> end of the 101 response.
>
> I'd propose the above as another requirement, but it seems we're  
> still debating that idea.
> Certainly my support for any security measures hinges on whether or  
> not it implies incompatibilities to HTTP.

I think HTTP compatibility is a separate requirement (or set of  
requirements) and we need to aim for a design that meets all of them.

It would be nice to unpack "HTTP compatibility" into requirements that  
are somewhat more concrete. For example:

Requirement: The WebSocket protocol should be designed so that it is  
possible and practical to share a single host and port. Consideration  
should be given to making it possible to provide WebSocket services  
via modules that plug in to existing popular Web servers.

The above is a statement that can be evaluated pretty objectively,  
while "compatible with HTTP" is something I could see as turning into  
theoretical debates about the meaning of "compatible". Perhaps there  
are other concrete requirements or use cases that we can come up with  
which related to HTTP compatibility.

Regards,
Maciej

> -=R
>
> On Thu, Feb 25, 2010 at 12:36 PM, Salvatore Loreto <[email-masked] 
> > wrote:
>
>> I think we should have security requirements, but that way of  
>> phrasing it seems a little indirect. I would phrase it like this:
>>
>> 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).
>>
> so again folks, any objection to include this requirement as phrased  
> by Maciej ?
>
> Cheers
> /Sal
>

---

From: Tim Bray <[email-masked]>
Date: Thu, 25 Feb 2010 13:41:57 -0800

On Thu, Feb 25, 2010 at 1:31 PM, Maciej Stachowiak <[email-masked]> wrote:

> It would be nice to unpack "HTTP compatibility" into requirements that are
> somewhat more concrete. For example:

Another example requirement: The syntax of the messages which make up
the WebSocket handshake should be compatible with that of HTTP
headers, to facilitate re-use of existing well-debugged software.

 -T

---

From: Roberto Peon <[email-masked]>
Date: Thu, 25 Feb 2010 15:15:27 -0800

On Thu, Feb 25, 2010 at 1:31 PM, Maciej Stachowiak <[email-masked]> wrote:

> possible and practical to share a single host and port. Consideration should
> be given to making it possible to provide WebSocket services via modules
> that plug in to existing popular Web servers.
>

This is a fine restatement. I like it, and agree with your point about
avoiding ambiguity.
-=R

>
>
> The above is a statement that can be evaluated pretty objectively, while
> "compatible with HTTP" is something I could see as turning into theoretical
> debates about the meaning of "compatible". Perhaps there are other concrete
> requirements or use cases that we can come up with which related to HTTP
> compatibility.
>
> Regards,
> Maciej
>
>
> -=R
>

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 25 Feb 2010 16:21:14 -0800

On Feb 25, 2010, at 3:15 PM, Roberto Peon wrote:

>> So long as it doesn't imply incompatibilities with HTTP *before*  
>> the end of the 101 response.
>>
> It would be nice to unpack "HTTP compatibility" into requirements  
> that are somewhat more concrete. For example:
>
> possible and practical to share a single host and port.  
> Consideration should be given to making it possible to provide  
> WebSocket services via modules that plug in to existing popular Web  
> servers.
>
> This is a fine restatement. I like it, and agree with your point  
> about avoiding ambiguity.

Thanks! Though now that I re-read it, I see that my wording was a bit  
off. Freshly restated version:

Requirement: The WebSocket protocol should be designed so that it is  
possible and practical to share a single host and port with HTTP.  
Consideration should be given to making it possible to provide  
WebSocket services via modules that plug in to existing popular Web  
servers.

(The change is adding the words "with HTTP" to the end of the first  
sentence.)

Regards,
Maciej

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 25 Feb 2010 17:25:21 -0700

> via modules that plug in to existing popular Web servers.

Does anyone else want the opposite requirement as well?

Requirement: The WebSocket protocol should be designed so that it is
possible and practical to use a different port number for WebSockets and
HTTP(s).

This may just come down to security considerations suggesting that the
same-origin policy in the hosting application SHOULD NOT match port numbers.

In my case, the WebSocket server will be a separate piece of software, and
(at least in development/test setups) I don't want to have to set up a proxy
on my HTTP server.

-- 
Joe Hildebrand
(as individual contributor)

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 25 Feb 2010 16:28:16 -0800

> headers, to facilitate re-use of existing well-debugged software.

Sounds like a worthy goal, but maybe it should be limited to the  
requirement rather than including the conclusion:

Requirement: Facilitate re-use of existing well-debugged software when  
implementing WebSocket.

Although, phrasing it that way, it seems like we should be clear about  
what kinds of existing well-debugged software we want to facilitate  
the reuse of. HTTP libraries? HTTP header parsing code? Full Web  
servers? Some existing code in browser implementations?

It also seems to me like this requirement is more a "SHOULD" than a  
"MUST". In other words, if we found that the best way to meet all the  
hard requirements (possibility of port sharing, security, actually  
supporting bidirectional messaging, etc) somehow made it slightly  
harder to reuse existing software, then it seems to me we could do  
that and not consider the effort a failure. I think we should  
distinguish between requirements that we feel we must meet to have a  
viable solution, and "would be nice" requirements that would be  
preferable all other things being equal, but should not trump other  
requirements.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 25 Feb 2010 16:29:38 -0800

> (at least in development/test setups) I don't want to have to set up  

I agree that this is a good goal. This really seems more about having  
a standalone server that's not tied up with a Web server than port  
numbers per se, so I'd restate it as:

Requirement: The WebSocket protocol should be designed so that it is  
possible and practical to make a standalone WebSocket server that is  
not embedded into an existing HTTP server.

Regards,
Maciej

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 25 Feb 2010 17:33:20 -0700

> not embedded into an existing HTTP server.

+1.  That captures it, and is much more generic.

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 27 Feb 2010 08:31:49 +0100

Maciej Stachowiak wrote:
> I agree that this is a good goal. This really seems more about having a
> standalone server that's not tied up with a Web server than port numbers
> per se, so I'd restate it as:
> 
> possible and practical to make a standalone WebSocket server that is not
> embedded into an existing HTTP server.

I agree with the sentiment, but think this should be worded differently.

a standalone websocket server *is-a* HTTP server even if the
only request it can handle is an Upgrade and the only response it
can send is a 101.   It's just not a full featured HTTP server.

So how about:

  A web socket server MUST support only those parts of HTTP that are
  necessary for a websocket connection to be securely established.

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Sat, 27 Feb 2010 00:00:40 -0800

>  necessary for a websocket connection to be securely established.

I think in the WebSocket protocol as written, a WebSocket only server  
would likely *not* be conforming to all the server conformance  
requirements of the HTTP RFC. Nor do I see why it would be necessary  
or helpful to require such. So I don't think it's true that "a  
standalone websocket server is-a HTTP server", nor do I think it is  
desirable. If you think it would be a useful requirement, please  
provide rationale. One obvious example of an RFC2616 violation would  
be that a standalone WebSocket server would likely not support HEAD at  
all.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 27 Feb 2010 09:12:49 +0100

Maciej,

I think we are agreeing on substance.... just not on words.

I agree a standalone websocket server should not
have to support HEAD.

So if you ignore what I said about *is-a* HTTP server, do you agree
with the intent of the statement:

ie this is saying that a websocket server does not need
to support full RFC2616.  It would only need to support the bits
necessary to establish a websocket connection - whatever they may
end up being.

regards

Maciej Stachowiak wrote:
> requirements of the HTTP RFC. Nor do I see why it would be necessary or
> helpful to require such. So I don't think it's true that "a standalone
> websocket server is-a HTTP server", nor do I think it is desirable. If
> you think it would be a useful requirement, please provide rationale.
> One obvious example of an RFC2616 violation would be that a standalone
> WebSocket server would likely not support HEAD at all.
> 
> Regards,
> Maciej
>