Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt

Peter Saint-Andre <stpeter@stpeter.im> Wed, 07 September 2011 11:54 UTC

Return-Path: <stpeter@stpeter.im>
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 6009221F8C1F for <hybi@ietfa.amsl.com>; Wed, 7 Sep 2011 04:54:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 JVXTJMlENGqy for <hybi@ietfa.amsl.com>; Wed, 7 Sep 2011 04:54:45 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 86E5421F8A58 for <hybi@ietf.org>; Wed, 7 Sep 2011 04:54:41 -0700 (PDT)
Received: from squire.local (unknown [216.17.251.17]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 83D4E418BB; Wed, 7 Sep 2011 05:59:26 -0600 (MDT)
Message-ID: <4E675BEC.5000502@stpeter.im>
Date: Wed, 07 Sep 2011 05:56:28 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Willy Tarreau <w@1wt.eu>
References: <20110831184207.1514.64093.idtracker@ietfa.amsl.com> <0fc901cc6878$1681eec0$0a00a8c0@Venus> <CAH9hSJb2rH+fX0AnekYxsEkHKzb15aHrg_hDQw1baWLiWBF-3w@mail.gmail.com> <CALkdAkjMro781JiQE7R8wZQf6zW83d25YWiy=QBEgdyJTHXepA@mail.gmail.com> <20110907073055.GD16712@1wt.eu>
In-Reply-To: <20110907073055.GD16712@1wt.eu>
X-Enigmail-Version: 1.3.1
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.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, 07 Sep 2011 11:54:46 -0000

<hat type='AD'/>

On 9/7/11 1:30 AM, Willy Tarreau wrote:
> On Wed, Sep 07, 2011 at 09:14:52AM +0200, Sylvain Hellegouarch wrote:
>> Since the masking and unmasking are the same operations, I fail to
>> understand the added complexity of server-to-client masking. Clients already
>> know how to unmask since they can mask in the first place with the same
>> operation.
> 
> Except they don't know the masking key. The purpose of masking is not
> to prevent a *client* from emitting the data it wants, but to prevent
> some *javascript code* running in a browser from doing so. The client
> is not the issue here, the issue is the fact that the attacker on the
> server side might easily make a client execute some controlled JS code.
> We want to ensure that someone who's present at both ends cannot easily
> control the byte stream sent by the client. And since the JS does not
> know the key, there's no easy way to perform the operation backwards
> first.

That's a fine explanation, but it's not clear in Section 10.3, which
seems to focus on intermediaries. This has caused confusion for at least
one IESG member, who commented that masking ought to be MUST-implement
but MAY-enable (i.e., there are some environments in which the client
would not need to mask). Perhaps modifications to Section 10.3 are in
order...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/