[apps-discuss] Review of draft-ietf-hybi-thewebsocketprotocol for apps-review

Lisa Dusseault <lisa.dusseault@gmail.com> Thu, 21 July 2011 05:09 UTC

Return-Path: <lisa.dusseault@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9E521F8B00 for <apps-discuss@ietfa.amsl.com>; Wed, 20 Jul 2011 22:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPZLc3Exrqct for <apps-discuss@ietfa.amsl.com>; Wed, 20 Jul 2011 22:09:32 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id F26FC21F8AFA for <apps-discuss@ietf.org>; Wed, 20 Jul 2011 22:09:26 -0700 (PDT)
Received: by ywp31 with SMTP id 31so502492ywp.31 for <apps-discuss@ietf.org>; Wed, 20 Jul 2011 22:09:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer; bh=YbC8GR8fiGM0m2M2mUjXcQmtkMpqZwQCNSPbN8cpnvA=; b=aUIuhTA018dyM7Xye0U4QAvHc+x9Ck07xLWv89KkI4pLSANWEXtuozoh5gJL8uioFh xYM9cE9qWDcj0Xr3feZdIZXnAeIR0N+hF4gzsvtDakwJ1ufwSpo94ZxDOxQjk9S/Wcxs czL0sc3rv7jJCBbM7C9slzGLeADE4btyyNVpU=
Received: by 10.150.72.30 with SMTP id u30mr154027yba.120.1311224966127; Wed, 20 Jul 2011 22:09:26 -0700 (PDT)
Received: from [192.168.1.105] (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by mx.google.com with ESMTPS id h6sm1329160icy.1.2011.07.20.22.09.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 22:09:24 -0700 (PDT)
From: Lisa Dusseault <lisa.dusseault@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-9-57797879
Date: Wed, 20 Jul 2011 22:09:23 -0700
Message-Id: <E43F73C1-36B4-4A06-9AF0-83C7498B28FA@smule.com>
To: apps-discuss@ietf.org, Alexey Melnikov <alexey.melnikov@isode.com>, ifette+ietf@google.com, Pete Resnick <presnick@qualcomm.com>, Peter Saint-Andre <stpeter@jabber.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [apps-discuss] Review of draft-ietf-hybi-thewebsocketprotocol for apps-review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2011 05:10:10 -0000

I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-hybi-thewebsocketprotocol (reviewed -10)
Title: The WebSocket protocol
Reviewer: Lisa Dusseault
Review Date: July 20, 2011

Readiness Summary: This draft is almost ready for publication on the Standards Track, but it has a few issues that should be fixed or thought about before publication.

Document Summary: The Websocket protocol defines a HTTP handshake to transition from a Web context to a bi-directional connection.  It also defines framing and masking for use in the bi-directional context.  It addresses a number of security concerns involving untrusted application code running in browsers, but assumes that browsers are trusted and servers hosting Websockets are trusted to a greater extent. 

Major Issues

1.  Masking

It would be good to state what the purpose of masking is.  The sentence is "Frames sent from the client to the server are masked to avoid confusing network intermediaries", but I didn't upon reading this, or looking at the specification text for masking, understand why network intermediaries would be confused.  A citation or further explanation would be good.  I see later there's an explanation in page 50, so a forward reference would also work.

2.  Cookie handling

Section 5.1, 
 The request MAY include headers associated with sending cookies,
    as defined by the appropriate specifications [RFC6265].  These
    headers are referred to as _Headers to Send Appropriate
    Cookies_.

    and

 "Additionally, if any headers in the
  server's handshake indicate that cookies should be set (as defined by
  [RFC6265]), these cookies are referred to as _Cookies Set During the
  Server's Opening Handshake_."

 and 

Section 5.2.1, point 8
 	8.  Optionally, other headers, such as those used to send cookies to
     a server.  Unknown headers MUST be ignored.

First, a nit:   these important underlined terms are referred to where?  I didn't see anywhere where these terms are used other than where they are defined here.

The more substantive issue: I'm left unclear as to whether cookies are really expected to be used, or how the client might know that it needs to use cookies or else the application will not work.  In many Web sites, the site will not work if cookies are not used by the client, and this is sufficiently rare that it's OK.  Is that OK for a Websockets app?  How will the user know how to fix the problem?  Since Websockets can't as easily reply with a Web page to explain how to enable cookies, it would be good to be more clear on this.  

3.  Failing a WebSocket Connection

Section 7.1.7 is supposed to describe how to _Fail the WebSocket Connection_.  It explains how the client does so.  However, there's at least one case in section 9.1 where the server receiving a malformed Sec-WebSocket-Extensions header must _Fail the WebSocket Connection_.  How does the server do this? 

4.  Dropping with extreme prejudice

From the Security Considerations: 

"If at any time a server is faced with data that it does not
understand, or that violates some criteria by which the server
determines safety of input, or when the server sees an opening
handshake that does not correspond to the values the server is
expecting (e.g. incorrect path or origin), the server SHOULD just
disconnect.  It is always safe to disconnect."

This seems pretty excessive.  When the server just disconnects, the client can't tell much about what went wrong, and whether an automated retry would be any use at all.  This is bad for deployed use, and even worse for development/debugging.  Yet we're recommending servers be that unhelpful?  Wouldn't it be better to recommend that the server reply with an error response (some HTTP status codes defined here, too) that can help the client diagnose an incorrect origin?  An error like that is often going to be a mis-configuration on one side or the other, rather than an attack.

I'd also like to know what the websockets server implementations currently do.


Minor Issues

The reservation of different ranges of error codes for use by extensions, libraries and frameworks, and application code, seems to be intended to avoid conflicts between those kinds of use.  I don't think it will work very well.  I don't understand where a library ends and application code begins, even in code I write where I write an error_handler to be called by the library I'm using (which might be a "library" only for convenience sake or might be a library that dozens of other software programs use).  

The border between code and "extensions" is not even very clear; if somebody writes an extension intending to publish an internet-draft but never gets around to it, they may have ended up using the wrong range with the right intentions.

The border between extensions and "this protocol" is not very clear; if I submit a internet-draft with a feature proposed to be a requirement for websockets, I might prefer to use a 1000-1999 range error code but if the feature is relegated to an optional draft it should change to 2000-2999 range. 

This kind of ambiguity leads to arguments at best, unnecessary changes to code (when specs are changed late after such arguments) at worst.  I'm not sure what to recommend; perhaps only one range reserved for  "this protocol and extensions published within the IETF process", and another range for "libraries, frameworks and application code".


Thanks,
Lisa Dusseault