Re: [hybi] deflate-stream and masking

Greg Wilkins <gregw@intalio.com> Wed, 20 July 2011 02:34 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 2368511E809C for <hybi@ietfa.amsl.com>; Tue, 19 Jul 2011 19:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[AWL=0.182, 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 fAZwNJBhPgxY for <hybi@ietfa.amsl.com>; Tue, 19 Jul 2011 19:34:41 -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 82B4811E808B for <hybi@ietf.org>; Tue, 19 Jul 2011 19:34:41 -0700 (PDT)
Received: by vws12 with SMTP id 12so4449040vws.31 for <hybi@ietf.org>; Tue, 19 Jul 2011 19:34:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.174.113 with SMTP id br17mr4061711vdc.107.1311129280427; Tue, 19 Jul 2011 19:34:40 -0700 (PDT)
Received: by 10.52.115.103 with HTTP; Tue, 19 Jul 2011 19:34:40 -0700 (PDT)
In-Reply-To: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>
Date: Wed, 20 Jul 2011 12:34:40 +1000
Message-ID: <CAH_y2NFMdr1ZU2dfy9mCRepZc2R_hnzg0oa3kYPKhWY-FX_8Og@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Hybi <hybi@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [hybi] deflate-stream and masking
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, 20 Jul 2011 02:34:42 -0000

I've just noticed that the w3c is currently intending to make support
for deflate-stream mandatory!

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917

This moves this extension from being useless, but mostly harmless, to
being a major impost on servers and intermediaries.
If the browser make this mandatory, then servers will obviously have
to support it at a cost of extra CPU, extra buffers but for no
significant savings in bandwidth.
Intermediaries that wish to act on frame boundaries will also have to
implement it.

This illustrate that having silly options always puts you at risk of
people taking you up on those options.

This extension is demonstrably broken and needs to be either fixed or removed.

regards



On 20 June 2011 16:33, Greg Wilkins <gregw@intalio.com> wrote:
> As part of my continuing campaign against including deflate-stream in
> the specification as a standard extension, I did a quick test of how
> well it works when applied to masked frames.
>
> I took a days worth of traffic from an IRC channel and wrapped it up
> as JSON messages sent as websocket frames.
> There were 487 message that looked like:
>
>     {channel:"#webtide", username:"tbecker", text:"joakime: jenkins
> had issues pulling from github a couple of times  last week"}
>
> As an unmasked WS stream, it was 50675 bytes, and as a masked stream
> is was 52623 bytes.
> I then compressed both these streams with gzip and got 13306 bytes for
> unmasked and 51704 bytes for the masked!!!!
>
> So for this very typical example, masking was sufficiently random to
> completely negate the benefits of compression.
>
> So the deflate-stream "extension" is:
>
>  + next to useless for inbound traffic
>  + breaks all the rules of what an extension can do
>  + is potentially vulnerable to injection as attackers can send
> repeated patterns that may subvert masking
>  + can be replaced by the in-frame compression extension already proposed.
>  + was inserted in the draft with little or no discussion and without
> clear consensus.
>
> Can I call for a straw poll of who wants to keep this extension in the spec?
>
>
>
> regards
>