Subject: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt

From: [email-masked]
Date: Mon, 13 Jun 2011 16:37:45 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF.

	Title           : The WebSocket protocol
	Author(s)       : Ian Fette
	Filename        : draft-ietf-hybi-thewebsocketprotocol-09.txt
	Pages           : 68
	Date            : 2011-06-13

   The WebSocket protocol enables two-way communication between a client
   running untrusted code running in a controlled environment to a
   remote host that has opted-in to communications from that code.  The
   security model used for this is the Origin-based security model
   commonly used by Web browsers.  The protocol consists of an opening
   handshake followed by basic message framing, layered over TCP.  (In
   theory, any transport protocol could be used so long as it provides
   for reliable transport, is byte clean, and supports relatively large
   message sizes.  However, for this document, we consider only TCP.)
   The goal of this technology is to provide a mechanism for browser-
   based applications that need two-way communication with servers that
   does not rely on opening multiple HTTP connections (e.g. using
   XMLHttpRequest or &lt;iframe&gt;s and long polling).

   Please send feedback to the [email-masked] mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-09.txt

---

From: Dirkjan Ochtman <[email-masked]>
Date: Tue, 14 Jun 2011 08:34:02 +0200

>   Please send feedback to the [email-masked] mailing list.

Thanks for incorporating the changes I suggested.

One thing that seems weird: for draft-09, the protocol version has not
been updated because the wire protocol is unchanged, but it seems to
me like the changes in
handling RSV bit values would be enough to require a version update:
the required server behavior is different from draft 8 to draft 9, but
it cannot discern which version the client implements.

Cheers,

Dirkjan

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 14 Jun 2011 15:38:02 +0900

Side-by-side diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-thewebsocketprotocol-09

FYI, list of changes 8->9

----

Semantic change
- any of RSV=1 : ignore the value -> _Fail the WebSocket Connection_
(section4.2)

Note addition, clarification
- example of subprotocol now doesn't contain space (section1.9)
- added note about message interleaving (section4.4)
- added note about close frame masking (section4.5.1)
- added note about version numbering (section5.1)
-- IANA version number registry 9 (actually, this won't be used)
(section11.12)
- added upgrade and connection header (section5.2.2)
- added note about what/how extension may modify (section6.2)
- big rewrite of security consideration about wrong encoding (section10)

Typo, etc.
- typo fixes
-- ws -> wss (section3)
-- host -> port (section3)
- style fixes
-- itemize (section3)
-- bullet point removal (section4.4)
-- moved out Note paragraph to the bottom of the subsection (section4.4)
-- phrasing fix (status-line) (section5.2.2)

---

From: Patrick McManus <[email-masked]>
Date: Tue, 14 Jun 2011 10:37:07 -0400

> - any of RSV=1 : ignore the value -> _Fail the WebSocket Connection_

Ian, Gabriel, Salvatore,

As always, thanks for the updates?

I'm trying to figure out where this change came from? I can't find a
reference to it in any of the feedback on -08, though I'm probably
overlooking something.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 14 Jun 2011 10:40:47 -0400

> As always, thanks for the updates?

rather "thanks for the updates.". Doh :)

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 14 Jun 2011 10:02:54 -0700

There was an email to the chairs pointing out that unknown values in
reserved bits vs unknown opcode values were handled differently. The chairs
discussed and asked me to make them both fail.

On Tue, Jun 14, 2011 at 7:37 AM, Patrick McManus <[email-masked]>wrote:

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

---

From: Patrick McManus <[email-masked]>
Date: Tue, 14 Jun 2011 14:06:42 -0400

On Tue, 2011-06-14 at 10:02 -0700, Ian Fette (イアンフェッティ) wrote:
> reserved bits vs unknown opcode values were handled differently. The
> chairs discussed and asked me to make them both fail.
> 

I'm confused. 

In -08 an unknown RSV* mandates a MUST ignore, and an unknown opcode
also mandates a MUST ignore. That seems like a match to me.

In -09 unknown RSV* mandates a FAIL, and unknown opcode mandates an
ignore.

how does that mesh with what was done?

---

From: "Andy Green (林安廸)" <[email-masked]>
Date: Tue, 14 Jun 2011 19:35:25 +0100

> how does that mesh with what was done?

I guess it can make sense, the opcode has a length so you can skip it 
okay even if you don't understand what's inside.

But RSV bits might mess with the framing so you can't interpret the 
length correctly any more, you're dead in the water then for skipping it.

-Andy

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 14 Jun 2011 22:43:41 +0000

The 07 version had no explicit behavior defined, but if any bits or opcodes were used unexpectedly, something was obviously very wrong:

07:
   As such, in the absence of extensions negotiated during the opening    
    handshake (Section 5), all reserved bits MUST be 0 and reserved     
    opcode values MUST NOT be used.

08 had to resolve what to do with RSV bits and opcodes, so it introduced behavior to ignore:

08:
For RSV bits: " the receiving endpoint MUST ignore that value."
Opcode: " receiving endpoint MUST ignore that frame"

In some discussion with Alexey, Ian and the chairs, it seemed like the behavior to introduce should be to abort the connection, in line with something being very wrong. 09 was supposed to reflect that, but as you point out, it only does that half way:

09:
For RSV bits: " receiving endpoint MUST _Fail the WebSocket  Connection_. "
Opcode: no change from 08: ignore that frame

The intent was to have Opcode also say " receiving endpoint MUST _Fail the WebSocket  Connection_" given that something is very wrong anyways.

Whatever it is, it is best if both RSV and Opcode are handled the same way (either always fail the connection or always ignore)

Does this clarify? Do folks agree that revising to failing in both cases is fine? 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> "Andy Green (???)"
> Sent: Tuesday, June 14, 2011 11:35
> To: Patrick McManus
> Cc: [email-masked]
> Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
> 
> I guess it can make sense, the opcode has a length so you can skip it okay even if
> you don't understand what's inside.
> 
> But RSV bits might mess with the framing so you can't interpret the length
> correctly any more, you're dead in the water then for skipping it.
> 
> -Andy

---

From: Patrick McManus <[email-masked]>
Date: Tue, 14 Jun 2011 20:35:26 -0400

> Does this clarify? Do folks agree that revising to failing in both cases is fine? 

Yes, thanks. (yes both to clarification and failing both).

I've been talking with our security team and they are pretty strongly of
the point of view that violations of the RSV and Opcode MUSTs need to
result in failing the connection. That is what we did in our -07
implementation when the error handling was undefined. Silently redacting
messages from the application stream by dropping is considered tatamount
to corruption and is a security risk for the application.

There is a similar reaction to the -08+ requirement that (paraphrased)
non UTF-8 sequences are interpreted as U+FFFD. Silently rewriting the
data is frowned on from a security pov. We are considering just failing
such a non-conformant connection (and I suppose becoming non-conformant
ourselves by doing so.).

-Patrick

---

From: "Simon Pieters" <[email-masked]>
Date: Wed, 15 Jun 2011 11:16:04 +0200

On Wed, 15 Jun 2011 02:35:26 +0200, Patrick McManus <[email-masked]>  
wrote:

>> Whatever it is, it is best if both RSV and Opcode are handled the same  
>> way (either always fail the connection or always ignore)
>>
> result in failing the connection.

I don't know what the security problem is here, but since extensions are  
agreed upon in the handshake the server has no business using the  
extension if the client didn't ask for it, so failing the connection is  
fine with me.

> That is what we did in our -07

Rewriting broken UTF-8 sequences to U+FFFD is done all over the Web  
platform (exception being XML although most browsers did it in XML too  
until it was tested in Acid3). Failing the connection here seems to make  
the protocol brittle. What's the security problem?

-- 
Simon Pieters
Opera Software

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Jun 2011 11:20:16 +0200

On 2011-06-15 11:16, Simon Pieters wrote:
> ...
> ...

Failing the connections makes broken servers fail early. Sounds good to me.

Best regards, Julian

---

From: Patrick McManus <[email-masked]>
Date: Wed, 15 Jun 2011 08:47:18 -0400

> the protocol brittle. What's the security problem?

The objection is a general one to any silent rewriting of application
level data. The value of what was actually sent is now ambiguous to the
js application and this could interfere with application layer
semantics, checksums, signatures, etc... Unlike the broad HTML based
web, there is no reason to introduce the workaround here when we can
simply enforce the must use UTF-8 requirement.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 21 Jun 2011 14:21:03 +1000

Draft -09 still has examples that say:

Sec-WebSocket-Version: 8

I guess we also need to think about what we are going to do with this
field as we approach "final"

cheers

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 20 Jun 2011 21:23:15 -0700

The request MUST include a header with the name "Sec-WebSocket-
        Version".  The value of this header MUST be 8. _Note: Although a
        draft -09 was published, as -09 was comprised of editorial
        changes and not changes to the wire protocol, 9 was not used as
        a valid value for Sec-WebSocket-Version.  This value was
        reserved in the IANA registry but was not and will not be used.

Fette                   Expires December 15, 2011              [Page 30]

  <http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#page-31>Internet-Draft
          The WebSocket protocol                June 2011

        If subsequent changes to the wire protocol are necessary, 9 will
        be skipped to prevent confusion with the draft 9 protocol._

On Mon, Jun 20, 2011 at 9:21 PM, Greg Wilkins <[email-masked]> wrote:

> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the BiDirectional or
> Server-Initiated HTTP Working Group of the IETF.
> >

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 21 Jun 2011 14:25:59 +1000

>         reserved in the IANA registry but was not and will not be used.

oops - I just saw that.

However we still need to decide if/when we will be dropping this field
or converting it to something like

   Sec-WebSocket-Version: 1.0

I know some think versioning is an anti pattern, but it has proved
invaluable in handling multiple client versions.

cheers

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 20 Jun 2011 22:01:20 -0700

I think that we should keep it, but I don't think we should force it to 1.0
or anything. I think we should just leave it at 8 (or at a later version if
that's necessitated).

-Ian

2011/6/20 Greg Wilkins <[email-masked]>

---

From: Dirkjan Ochtman <[email-masked]>
Date: Tue, 21 Jun 2011 09:24:36 +0200

> or anything. I think we should just leave it at 8 (or at a later version if

You haven't responded to my email at the start of this thread about
incompatibilities between 08 and 09...

Cheers,

Dirkjan

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 21 Jun 2011 00:40:00 -0700

The changes were all in error handling, and were relatively minor. I believe
they match what implementations were doing anyways, and was told by
implementors that bumping the version number for such minor things was a
pain to them. Also, -08 was out for all of a week? Hopefully there's no real
implementations of that draft. I don't mean to dismiss your concern, it's a
fair point, but hopefully the tradeoff is acceptable.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 21 Jun 2011 16:50:21 +0900

> field as we approach "final"

One way to handle this is to add RFC Editor notes to the relevant text 
pieces to tell the RFC Editor to remove the text (and therewith the 
Sec-WebSocket-Version header). This makes sure we always have a version 
indicator even in the last draft (because we're never sure it will be 
the last) but won't have a version in the final base protocol.

Regards,    Martin.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 21 Jun 2011 01:16:55 -0700

I think we should keep the version header, even in the final. It would not
surprise me if there were future versions, this gives us a convenient way to
support that. (Also, -00 didn't have Version - it didn't show up until -04,
so its presence is also a nice way to determine final from some pre-final
versions.)

-Ian

On Tue, Jun 21, 2011 at 12:50 AM, "Martin J. Dürst"
<[email-masked]>wrote:

> indicator even in the last draft (because we're never sure it will be the
> last) but won't have a version in the final base protocol.
>
> Regards,    Martin.
>
>
> ______________________________**_________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman/listinfo/hybi>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 21 Jun 2011 11:30:22 +0300

we are not going to remove the version header in the final.

To be clear when we introduced the version header the idea was that it 
would be removed in the final;
however when developers started to use it, they found it useful
and since then we have heard only people asking to keep it even in the 
final,
while nobody has asked to remove it, neither during the wglc.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

On 6/21/11 11:16 AM, Ian Fette (イアンフェッティ) wrote:
> I think we should keep the version header, even in the final. It would 
> not surprise me if there were future versions, this gives us a 
> convenient way to support that. (Also, -00 didn't have Version - it 
> didn't show up until -04, so its presence is also a nice way to 
> determine final from some pre-final versions.)
>
> -Ian
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     One way to handle this is to add RFC Editor notes to the relevant
>     text pieces to tell the RFC Editor to remove the text (and
>     therewith the Sec-WebSocket-Version header). This makes sure we
>     always have a version indicator even in the last draft (because
>     we're never sure it will be the last) but won't have a version in
>     the final base protocol.
>
>     Regards,    Martin.
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Jun 2011 11:04:26 +0200

2011/6/21 Salvatore Loreto <[email-masked]>:
> To be clear when we introduced the version header the idea was that it would
> be removed in the final;
> final, while nobody has asked to remove it, neither during the wglc.

IMHO that is because developers are already trying to use WebSocket
and they get confussed with so many versions of the draft (more than
80 in total) and different handshake mechanisms and core protocols
(framing, masking...). So many websocket servers use some ugly version
detection system (by inspecting headers, and so) so they can
accommodate to the client's websocket version.

So, having a header Sec-WebSocket-Version would make life easier for
developers, right. But this is still a hack. I've never seen a
protocol specification upgrading a "version" field in the protocol
messages for each new draft revision. Just never. The protocol version
should be specified in the final RFC, not before.

IMHO this WG is becoming to much "special" and, instead of learning
from the History of Internet protocols, authors are improvising most
of the stuff present in the draft. WebSocket is not just a new
protocol, it is probably "The Protocol" for the next years. Please
don't experiment with such an important specification.

The specification should be written in a way that it becomes a RFC as
best as possible, rather than trying to satisfy impatient developers
during the spec creation process.

Just my opinion. Regards.

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Jun 2011 11:31:05 +0200

> should be specified in the final RFC, not before.

We did that for the Atom format.

> during the spec creation process.

I do not disagree with that.

Implementing a draft is an experiment; an important one.

But once we go to RFC the protocol version number should be bumped to 
something sane...

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 21 Jun 2011 12:37:48 +0300

my comment was about keeping the Sec-WebSocket-Version header.

What number (and format) should be put there at the end, in the final 
RFC, it is a different story.

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Jun 2011 11:56:26 +0200

> my comment was about keeping the Sec-WebSocket-Version header.

I agree.

> What number (and format) should be put there at the end, in the final RFC,
> it is a different story.

What I mean is that, IMHO, it should be "1.0" (or whatever other
agreed value) from now until the draft becomes an RFC, rather than
incrementing such a value in each draft technical modification.

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

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 21 Jun 2011 23:00:34 +1000

On 21 June 2011 19:04, Iñaki Baz Castillo <[email-masked]> wrote:
> IMHO this WG is becoming to much "special"

Well there is something a bit special about this protocol.

We are encouraged to put draft implementations out into the wild so
that we can get some wider experience and feedback (working code
etc.).  But to do this means that the draft protocol is enabled in
browsers that are widely distributed, but also have a wide range of
update policies. It is not uncommon for a browser not to be updated
for many years, or put on a mobile device and never updated.

The result is that draft versions implemented are likely to be in
circulation for a long time.

Having the draft version in the handshake has proven a very workable
solution that prevents the heuristic version determination that was
previously necessary.  Is there any alternative solution?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Jun 2011 15:15:50 +0200

> previously necessary.  Is there any alternative solution?

Having experimental working implementations in order to improve a spec
or detect/fix issues is great. Relying on such implementations is not
so great, even less when you are talking about widely extended web
browsers. In other words, I don't consider "polite" to experiment with
the rest of the world just to realize of issues in a no mature
specification (which is still a draft).

IMHO browser vendors could provide an experimental version with
WebSocket support so developers and people in this WG can test it
against the current specification. Ok, there it could make sense a
*temporal* header like "X-WebSocket-TMP-Version". But such
version/revision value should have no relationship with the final
protocol version (i.e. "1.0") which will be submitted to the IETF.
This is, don't mix experiments with the final spec.

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

---

From: Patrick McManus <[email-masked]>
Date: Tue, 21 Jun 2011 09:25:09 -0400

It is likely that firefox 6 will be shipped with a websockets -09
implementation with the API prefixed under Moz*.

Hopefully Firefox 7 will be shipped with -09 under the normal WebSocket
namespace - we're waiting for the binary issue with the API to be fully
sorted out. That depends on what happens on the JS side of the fence.