[hybi] Draft 13 - a bit too historical about the masking debate

Greg Wilkins <gregw@intalio.com> Thu, 01 September 2011 02:00 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 5051421F8D67 for <hybi@ietfa.amsl.com>; Wed, 31 Aug 2011 19:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.908
X-Spam-Level:
X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saGdYPkjyS-R for <hybi@ietfa.amsl.com>; Wed, 31 Aug 2011 19:00:33 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABF9A21F8D32 for <hybi@ietf.org>; Wed, 31 Aug 2011 19:00:33 -0700 (PDT)
Received: by vxi29 with SMTP id 29so1193661vxi.31 for <hybi@ietf.org>; Wed, 31 Aug 2011 19:02:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.34.171 with SMTP id a11mr916513vdj.313.1314842525143; Wed, 31 Aug 2011 19:02:05 -0700 (PDT)
Received: by 10.52.185.133 with HTTP; Wed, 31 Aug 2011 19:02:05 -0700 (PDT)
Date: Thu, 01 Sep 2011 12:02:05 +1000
Message-ID: <CAH_y2NE1qbADKXNLkixc5MEPyQ5-zwLNH55Y6n_gSQn5Mxgh4A@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Hybi <hybi@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [hybi] Draft 13 - a bit too historical about the masking debate
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: Thu, 01 Sep 2011 02:00:34 -0000

Draft 13 contains a lot of text about the reasons for masking.   That
must not have been easy to write and for the most part it reads well.
However I'm not sure we should go into so much detail about the
history of the disagreements and the process.  Specifically I think
the following paragraph:

  To avoid such attacks on deployed intermediaries, the working group
   decided to adopt a solution that would provably protect against such
   attacks.  There were many proposed solutions that people argued
   "should" protect against the above attacks, such as adding in more
   random data and null bytes to the handshake, starting each frame with
   a byte that has the first (highest order) bit set such that the data
   appears to be non-ASCII, and so forth, but in the end none of these
   solutions were provably secure.  The deployed intermediaries were
   already not conforming to existing specifications, and given that we
   can't possibly enumerate all of the ways in which such
   nonconformities could exhibit themselves and that we cannot
   exhaustively discover and test each nonconformant intermediary
   against each possible attack, there was consensus to adopt an
   approach that did not require people to reason about how
   nonconformant intermediaries might behave.  Namely, the working group
   decided to mask all data from the client to the server, so that the
   remote script (attacker) does not have control over how the data
   being sent appears on the wire, and thus cannot construct a message
   that could be mis- interpreted by an intermediary as an HTTP request.


could be changed to to something like

  To provably avoid such attacks on deployed intermediaries,  it is not
  sufficient to prefix application supplied data with framing that is not
  compliant HTTP, as it is not possible to exhaustively discover and test
  that each nonconformant intermediary does not skip such non HTTP
  framing and act incorrectly on the frame payload.  Thus the defence
  adopted is to mask all data from the client to the server, so that the
  remote script (attacker) does not have control over how the data being
  sent appears on the wire, and thus cannot construct a message that
  could be misinterpreted by an intermediary as an HTTP request.