IETF Logo Mail Archive

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

Patrick McManus <pmcmanus@mozilla.com> Wed, 15 June 2011 12:47 UTC

Return-Path: <pmcmanus@mozilla.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 AAAFC11E80F0 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 05:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level:
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_14=0.6]
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 cI0+au3seDM8 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 05:47:32 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 4817911E80EF for <hybi@ietf.org>; Wed, 15 Jun 2011 05:47:32 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id 3DAF510194; Wed, 15 Jun 2011 08:47:31 -0400 (EDT)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 008B110154; Wed, 15 Jun 2011 08:47:21 -0400 (EDT)
From: Patrick McManus <pmcmanus@mozilla.com>
To: Simon Pieters <simonp@opera.com>
In-Reply-To: <op.vw31c2t3idj3kv@simon-pieterss-macbook.local>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com> <1308062227.1944.162.camel@ds9> <BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com> <1308074802.1944.175.camel@ds9> <4DF7A9ED.3000609@warmcat.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403256BF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <1308098126.1944.194.camel@ds9> <op.vw31c2t3idj3kv@simon-pieterss-macbook.local>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 15 Jun 2011 08:47:18 -0400
Message-ID: <1308142038.1944.217.camel@ds9>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.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, 15 Jun 2011 12:47:32 -0000

On Wed, 2011-06-15 at 11:16 +0200, Simon Pieters wrote:

> Rewriting broken UTF-8 sequences to U+FFFD is done all over the Web  
> platform (exception being XML although most browsers did it in XML too  
> until it was tested in Acid3). Failing the connection here seems to make  
> the protocol brittle. What's the security problem?
> 

The objection is a general one to any silent rewriting of application
level data. The value of what was actually sent is now ambiguous to the
js application and this could interfere with application layer
semantics, checksums, signatures, etc... Unlike the broad HTML based
web, there is no reason to introduce the workaround here when we can
simply enforce the must use UTF-8 requirement.

v2.23.0 | Report a Bug | By Email