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

Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> Wed, 08 June 2011 23:28 UTC

Return-Path: <Gabriel.Montenegro@microsoft.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 CE05A11E80CD for <hybi@ietfa.amsl.com>; Wed, 8 Jun 2011 16:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 nD+v2+pkv8gj for <hybi@ietfa.amsl.com>; Wed, 8 Jun 2011 16:28:15 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id BD83311E8085 for <hybi@ietf.org>; Wed, 8 Jun 2011 16:28:15 -0700 (PDT)
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 8 Jun 2011 16:28:09 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 8 Jun 2011 16:28:08 -0700
Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Wed, 8 Jun 2011 16:28:08 -0700
From: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
To: "ifette@google.com" <ifette@google.com>, Greg Wilkins <gregw@intalio.com>
Thread-Topic: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
Thread-Index: AQHMJgIGNC+RWZvmeEiFRxtORC8MYpS0ie2AgAAFroD//4ttwA==
Date: Wed, 8 Jun 2011 23:28:07 +0000
Message-ID: <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com>
In-Reply-To: <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.90]
Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7TK5EX14MBXW603w_"
MIME-Version: 1.0
Cc: "hybi@ietf.org" <hybi@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:28:16 -0000

About compression: Greg already expressed this feeling on the mailing list and there was very strong opposition.
At this point, I’d rather we not make such big changes. Let’s limit 09 to nits and typos.

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Ian Fette (????????)
Sent: Wednesday, June 08, 2011 16:24
To: Greg Wilkins
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt

On Wed, Jun 8, 2011 at 4:03 PM, Greg Wilkins <gregw@intalio.com<mailto:gregw@intalio.com>> wrote:
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.

Not really. We used to say the "body" of the frame was extension data followed by application data, indeed the payload len has always meant len(ext)+len(app). This re-write takes a lot of the sections that used to talk about this and now just talks about "payload" where payload data is extension data followed by application data, just as before. It doesn't prevent a compressing or encrypting extension -- the extension is free to modify the application data. [perhaps that point needs to be called out more explicitly somewhere]. For instance, a compressing extension could have a small amount of "extension data" such as an instruction to reset state and contain "application data" (the compressed data).

I think we should simply say that the payload data is the application
data as processed by all the negotiated extensions.

I think I would prefer to to keep some distinction of what data is purely for the extensions and what data is the actual data being passed by the protocol, at least conceptually. We can make it clearer that the extensions modify payload data, and at some points the distinction may not be crystal clear, but I think the distinction is still useful (for instance, by saying that a pong must have identical application data, we don't have to say that the payload is identical.)


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.


yes, sorry


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.

anyone else have thoughts here? it seems reasonable to me but I'd like to hear other opinions.



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.

see prior explanation earlier in this response



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).

How do others feel about keeping it / yanking it?


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.

I agree the text needs to be changed, but perhaps rather than killing it entirely, it can be rewritten as a more general statement of please be careful with encodings, as when you tell a recipient something is utf-8, they may make assumptions that will prove problematic if you send them something like iso-8859-1 instead, or at the least may cause misinterpretation or loss of data.

_______________________________________________
hybi mailing list
hybi@ietf.org<mailto:hybi@ietf.org>
https://www.ietf.org/mailman/listinfo/hybi