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

"Simon Pieters" <simonp@opera.com> Wed, 15 June 2011 09:16 UTC

Return-Path: <simonp@opera.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 1CE071F0C85 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 02:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
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 aC71o4RcFE3A for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 02:16:08 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id B23561F0C66 for <hybi@ietf.org>; Wed, 15 Jun 2011 02:16:07 -0700 (PDT)
Received: from simon-pieterss-macbook.local (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5F9G369014138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Jun 2011 09:16:04 GMT
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>, "Patrick McManus" <pmcmanus@mozilla.com>
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>
Date: Wed, 15 Jun 2011 11:16:04 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Simon Pieters" <simonp@opera.com>
Message-ID: <op.vw31c2t3idj3kv@simon-pieterss-macbook.local>
In-Reply-To: <1308098126.1944.194.camel@ds9>
User-Agent: Opera Mail/11.11 (MacIntel)
Cc: "hybi@ietf.org" <hybi@ietf.org>
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 09:16:09 -0000

On Wed, 15 Jun 2011 02:35:26 +0200, Patrick McManus <pmcmanus@mozilla.com>  
wrote:

> On Tue, 2011-06-14 at 22:43 +0000, Gabriel Montenegro wrote:
>
>> Whatever it is, it is best if both RSV and Opcode are handled the same  
>> way (either always fail the connection or always ignore)
>>
>> Does this clarify? Do folks agree that revising to failing in both  
>> cases is fine?
>
> Yes, thanks. (yes both to clarification and failing both).
>
> I've been talking with our security team and they are pretty strongly of
> the point of view that violations of the RSV and Opcode MUSTs need to
> result in failing the connection.

I don't know what the security problem is here, but since extensions are  
agreed upon in the handshake the server has no business using the  
extension if the client didn't ask for it, so failing the connection is  
fine with me.

> That is what we did in our -07
> implementation when the error handling was undefined. Silently redacting
> messages from the application stream by dropping is considered tatamount
> to corruption and is a security risk for the application.
>
> There is a similar reaction to the -08+ requirement that (paraphrased)
> non UTF-8 sequences are interpreted as U+FFFD. Silently rewriting the
> data is frowned on from a security pov. We are considering just failing
> such a non-conformant connection (and I suppose becoming non-conformant
> ourselves by doing so.).

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?

-- 
Simon Pieters
Opera Software