Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt

Greg Wilkins <gregw@intalio.com> Wed, 08 June 2011 23:03 UTC

Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6159221F8578; Wed, 8 Jun 2011 16:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.422
X-Spam-Level:
X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 QIhQHF-jfp1i; Wed, 8 Jun 2011 16:03:38 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB43D21F8571; Wed, 8 Jun 2011 16:03:37 -0700 (PDT)
Received: by vws12 with SMTP id 12so1077060vws.31 for <multiple recipients>; Wed, 08 Jun 2011 16:03:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.32.2 with SMTP id e2mr25785vdi.189.1307574217177; Wed, 08 Jun 2011 16:03:37 -0700 (PDT)
Received: by 10.52.108.35 with HTTP; Wed, 8 Jun 2011 16:03:37 -0700 (PDT)
In-Reply-To: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
Date: Thu, 9 Jun 2011 09:03:37 +1000
Message-ID: <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Internet-Drafts@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: hybi@ietf.org, i-d-announce@ietf.org
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 08 Jun 2011 23:03:40 -0000

Wow - that was a more extensive rewrite than I was expecting - but
most of the text looks to be good improvements - good work!


However 4.2 says

     The payload data is defined as extension data concatenated wit
application data.

and this is reflected elsewhere in the document.   Concatenation is
not the correct paradigm as this prohibits a compression or encrypting
extension which changes the entire payload.
I think we should simply say that the payload data is the application
data as processed by all the negotiated extensions.


Section 4.4, bullet point 3 is formatted as a bullet point, when it is
really a sub clause of the previous bullet point.  Also the Note about
control frames is formatted as another bullet point.

I also think this section needs another point like:

  * The fragments of one message may not be interleaved between the
fragments of another message unless an extension has been negotiated
that can interpret the interleaving.


4.8 says:

   o  Extension data may be placed in the payload data before the
      application data.

As above, this prevents compression/encrypting extensions.  Extensions
must be allowed to arbitrarily mutate the application data.


9.2.1 Compression

I still maintain that this extension should not be supported - it
breaks all the rules the spec defines for extensions - specifically it
mutates the framing.   There is an alternative compression proposal
available for in frame compression that would comply with the rules of
extensions (assuming we remove the concatenation restriction above).


In section 10, the draft says:

   The biggest security risk when sending text data using this protocol
   is sending data using the wrong encoding.  If an attacker can trick
   the server into sending data encoded as ISO-8859-1 verbatim (for
   instance), rather than encoded as UTF-8, then the attacker could
   inject arbitrary frames into the data stream.

I don't think this is true - not since we dropped sentinel encoded frames.
Length encoded frames are safe to send arbitrary data and there is no
possibility of any payload being interpreted as a frame in the
datastream.