Subject: I-D Action: draft-ietf-hybi-thewebsocketprotocol-14.txt

From: [email-masked]
Date: Thu, 08 Sep 2011 12:11:27 -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
                          Alexey Melnikov
	Filename        : draft-ietf-hybi-thewebsocketprotocol-14.txt
	Pages           : 77
	Date            : 2011-09-08

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

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 02:33:34 -0700

"""
10.4.  Implementation-Specific Limits

   Implementations MUST impose implementation-specific limits on
   otherwise unconstrained inputs, e.g. to prevent denial of service
   attacks, to guard against running out of memory, or to work around
   platform-specific limitations.  In particular, a malicious endpoint
   can try to exhaust its peer memory by sending either a single big
   frame (e.g. of size 2**60), or by sending a long stream of small
   frames which are a part of a fragmented message.  In order to protect
   from this implementations SHOULD impose limit on frame sizes and the
   total message size after reassembly from multiple frames.
"""

This text seems to suggest that

a) sending large frames or large messages is seen as a DoS attack and discouraged
b) all implementations would have internal limits wrt to frame/message size

IMHO, this is misleading.

Implementations with a frame-based API likely don't have limits regarding
total message size. Implementations with a streaming API likely don't have
limits regarding frame size (besides the protocol imposed limit of 2 ^63 octets).

Why are those implementations required to impose limits? Does not make sense.

Also, sending large frames/messages is not a DoS attack, but a valid use of WS.
When the receiving peer is incapable of processing the frame/message, it
should protect itself, but the sender isn't the one to blame for those limits.

I'd like to suggest something more neutral:

"""
Implementations which have implementation- and/or platform-specific
limitations regarding the frame size or total message size after reassembly
from multiple frames MUST protect against exceeding those limits.

Exceeding implementation/platform specific limits on otherwise unconstrained
inputs could be used by a malicous peer to mount a DoS attack or exhaust
the peers memory.
"""

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 02:49:08 -0700

"""
10.6.  Connection confidentiality and integrity

   Communications confidentiality and integrity is provided by running
   the WebSocket protocol over TLS (wss URIs).  WebSocket
   implementations MUST support TLS, and SHOULD employ it when
   communicating with their peers.
"""

Why MUST?

For example, TLS does not provide end-to-end confidentiality when
WebSockets used for communicating between client peers, and
the WS server is only there to mediate e.g. publish/subscribe messages.

In this case, confidentiality/integrity can be accomplished by encrypting
the payload of the messages, but without encrypting the point-to-point
transports between the clients to the server. Encrypting the transport
when the payload is already encrypted does not make sense in this
scenario.

I'd like to suggest:

"""
When point-to-point communication confidentiality and integrity is
desired and sufficient, the implementation SHOULD use TLS.
"""

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Sep 2011 06:52:10 -0400

Short answer: BCP 61, Section 7.
<http://tools.ietf.org/html/bcp61#section-7>

On Sep 12, 2011, at 5:49 AM, Tobias Oberstein wrote:

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 12 Sep 2011 06:58:35 -0400

> a) sending large frames or large messages is seen as a DoS attack and discouraged

It isn't always (neither is sending a GET request as a frame payload), but it can be used that way.

> b) all implementations would have internal limits wrt to frame/message size

All implementations *do*.  Storage is finite.

> limits regarding frame size (besides the protocol imposed limit of 2 ^63 octets).

In that case, the burden is just passed to the recipient of the stream.  I would be OK with text calling this out as an exception.

> inputs could be used by a malicous peer to mount a DoS attack or exhaust

The qualification in the first sentence is not really meaningful -- every host has finite storage.  If my laptop were at the office on a nice fat pipe, you could fill the hard disk in a couple of hours; servers typically operate on much thinner margins.

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 04:02:41 -0700

> All implementations *do*.  Storage is finite.

No. This assumes you would need to store the received data, which might
not be necessary.

Here is an example of a WS server that computes a SHA256 over data
received, sending a digest update for every 1M octets received.

It can run forever in constant memory.

http://www.tavendo.de/autobahn/tutorial/streaming.html#streaming

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 12 Sep 2011 04:13:02 -0700

> <http://tools.ietf.org/html/bcp61#section-7>

I'm not sure, are you pointing to 

"   However security must be a MUST IMPLEMENT so that end users will have
   the option of enabling it when the situation calls for it.
"?

This does not say TLS must be used, but only that "security" is mandatory.

TLS provides point-to-point security, but not end-to-end, the latter
providing a higher level of confidentiality.

So, when end-to-end security is desired by a user in some scenario,
an implementation could provide a message payload encryption scheme
and BCP 61, Section 7 would be fulfilled without having TLS implemented.

What about

"""
Point-to-point communications confidentiality and integrity is provided by running
the WebSocket protocol over TLS (wss URIs).

WebSocket  implementations MUST support TLS, and SHOULD employ it when
communicating with their peers, unless a stronger form of security scheme
like end-to-end encryption is in place.
"""

> > WebSockets used for communicating between client peers, and the WS
> > server is only there to mediate e.g. publish/subscribe messages.
> >
> > In this case, confidentiality/integrity can be accomplished by
> > encrypting the payload of the messages, but without encrypting the
> > point-to-point transports between the clients to the server.
> > Encrypting the transport when the payload is already encrypted does
> > not make sense in this scenario.
> >
> > I'd like to suggest:
> >
> > """

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 11:03:06 -0600

On 9/12/11 11:01 AM, Richard L. Barnes wrote:
> 
> On Sep 12, 2011, at 7:13 AM, Tobias Oberstein wrote:
> 
>> "   However security must be a MUST IMPLEMENT so that end users
>> will have the option of enabling it when the situation calls for
>> it. "?
>> 
>> TLS provides point-to-point security, but not end-to-end, the
>> latter providing a higher level of confidentiality.
>> 
>> So, when end-to-end security is desired by a user in some
>> scenario, an implementation could provide a message payload
>> encryption scheme and BCP 61, Section 7 would be fulfilled without
>> having TLS implemented.
>> 
>> What about
>> 
>> """ Point-to-point communications confidentiality and integrity is
>> provided by running the WebSocket protocol over TLS (wss URIs).
>> 
>> WebSocket  implementations MUST support TLS, and SHOULD employ it
>> when communicating with their peers, unless a stronger form of
>> security scheme like end-to-end encryption is in place. """
> 
> -1
> 
> This text doesn't change anything meaningful.  The current "MUST
> support / SHOULD employ" is entirely standard for compliance with BCP
> 61 and sufficiently describes the requirements in this case.

Agreed (with my AD hat on).

Peter

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

---

From: Joe Mason <[email-masked]>
Date: Wed, 14 Sep 2011 15:37:13 -0400

The new paragraph added to 11.3.5 Sec-WebSocket-Version (page 65, line 32) contains text cut-and-pasted from Sec-WebSocket-Protocol, but missed updating the header name after the first one:

    The |Sec-WebSocket-Version| header field MAY appear multiple times in	
    an HTTP response (which is logically the same as a single |Sec-	
    WebSocket-Protocol| header field that contains all values.  However	
    the |Sec-WebSocket-Protocol| header field MUST NOT appear more than	
    once in an HTTP request.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Thursday, September 08, 2011 3:28 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-14.txt

>	Filename        : draft-ietf-hybi-thewebsocketprotocol-14.txt
The list of changes in this version is as follows:

Addressed multiple DISCUSS issues from IESG:
Text based on a note from Roy Fielding about use of port 80/443.
Clarified that header fields are case-insensitive (Stephen).
Fixed a wrong version number in one place (multiple people).
Clarified what is meant by "If the server supports encryption" (Stephen).
base64 data can be empty. (Pete)
Clarified how multiple versions of WebSocket can be supported. (Stephen)
Clarified that frame payload lenght must use minimal encoding. (Stephen)
Allow frame-rsv* to be 1 in the ABNF (if negotiated via extensions). (Sean)
Clarified that multiplexing is not defined in this document.
Various clarifications about Pings (data is allowed, etc.)
Additional security consideration about cache poisoning when masking is 
not used. (Russ/GenArt).
Expanded text about denial of service from receiving big frames or long 
sequences of small frames. (Russ/GenArt).
MUST support TLS. Better cipher recommendations. (Stephen)
Clarified that no security properties are expected from SHA-1.
Additionally:
Allow to use quoted-string in extension-param (still restricted to ASCII).
Extended meaning of 1007 close status code (as per WG consensus).
Addressed some Comments from Pete Resnick (avoid use of "conformance"), 
Robert Sparks and Wesley.
Reduced version of the text about history of masking.
Clarified that masking key is randomly generated in each frame.
Clarified that some header fields can appear multiple times. (per WG 
discussion)
Fixed several typos.

Please note that this version doesn't address all DISCUSS comments 
(blocking comments) from IESG and I also have a list of some other 
remaining changes (both non blocking comments from IESG and some 
comments from the WG.) So there would be a version -15 to address these.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.