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

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 17 November 2014 20:57 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E881AC398 for <hybi@ietfa.amsl.com>; Mon, 17 Nov 2014 12:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.496
X-Spam-Level:
X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9jfeiXYDPYY for <hybi@ietfa.amsl.com>; Mon, 17 Nov 2014 12:57:46 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id D7B4C1AC3A5 for <hybi@ietf.org>; Mon, 17 Nov 2014 12:57:45 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 35A91181C9B; Mon, 17 Nov 2014 12:56:58 -0800 (PST)
To: ifette+ietf@google.com, Alexey.Melnikov@isode.com, barryleiba@computer.org, presnick@qti.qualcomm.com, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com
X-PHP-Originating-Script: 6000:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20141117205658.35A91181C9B@rfc-editor.org>
Date: Mon, 17 Nov 2014 12:56:58 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/hybi/RrLOHFWvQg2Xeh4pM11wELewnPs
Cc: hybi@ietf.org, jhall@futuresouth.us, rfc-editor@rfc-editor.org
Subject: [hybi] [Technical Errata Reported] RFC6455 (4185)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 20:57:51 -0000

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 <jhall@futuresouth.us>

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