Subject: [hybi] [Technical Errata Reported] RFC6455 (4185)

From: RFC Errata System <[email-masked]>
Date: Mon, 17 Nov 2014 12:56:58 -0800 (PST)

The following errata report has been submitted for RFC6455,
"The WebSocket Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=4185

--------------------------------------
Type: Technical
Reported by: Jonathan Hall <[email-masked]>

Section: 5.4

Original Text
-------------

Corrected Text
--------------

Notes
-----
Eratta resubmitted to correct mistake made at the end: intermediaries has been replaced with implementations.

There is no indication or mention of the payload length of the frame with regards to fragmentation. In abstract, it's apparent that the payload length specified in the header of the frame corresponds to the actual frames payload length. However, implementations have been observed that allow the headers payload length to be specified as a higher length than the actual raw payload of that frame. In the event that this occurs, some implementations are reallocating memory to support the length of what is reported as the entire payload of all fragmented messages combined, and continue building the buffer off of each frame from that point forward by allocating enough memory for specified payload length. Obviously, this opens up the potential for a memory consumption DoS attack on an implementation that uses this method. A lack of specification with regards to the RFC allows for such a mistake to happen, as it is not clearly defined in the fragmentation section.

The RFC specifies that fragmented messages should be used to send messages of an unknown length, i.e. streaming media, and therefore should also specify that the frame length bit should be preserved to the length of only that current frame and not be used to specify the overall payload length of all fragmented messages combined. Implementations should be forced to work with them on a frame-by-frame basis and to drop the connection of any instances where the specified length of the frames payload does not match the length of the actual raw payload data for that one frame.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17)
--------------------------------------
Title               : The WebSocket Protocol
Publication Date    : December 2011
Author(s)           : I. Fette, A. Melnikov
Category            : PROPOSED STANDARD
Source              : BiDirectional or Server-Initiated HTTP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Zhong Yu <[email-masked]>
Date: Tue, 18 Nov 2014 13:01:09 -0600

Section 5.2 clearly defines the meaning of "Payload length". It seems
improbable that an implementation could get it wrong.

Zhong Yu
http://bayou.io

---

From: Brian McKelvey <[email-masked]>
Date: Tue, 18 Nov 2014 19:45:33 -0800

And if an implementation did get it wrong, it would not inter-operate with any correct implementations.

Brian

Sent from my iPhone

> On Nov 18, 2014, at 11:01 AM, Zhong Yu <[email-masked]> wrote:
> 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi