From jamie@shareable.org Sun Jan 2 04:35:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23F33A695C for ; Sun, 2 Jan 2011 04:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpEa-i46bQgM for ; Sun, 2 Jan 2011 04:35:59 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id D187F3A6957 for ; Sun, 2 Jan 2011 04:35:58 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1PZNCF-0000iE-3R; Sun, 02 Jan 2011 12:38:03 +0000 Date: Sun, 2 Jan 2011 12:38:03 +0000 From: Jamie Lokier To: Bruce Atherton Message-ID: <20110102123803.GE20751@shareable.org> References: <4D154847.4040908@callenish.com> <4D1A490C.80202@callenish.com> <443B426A-BC34-48E6-8525-F8E98667E82C@apple.com> <4D1A94C5.2040404@callenish.com> <95CC9C10-A790-46B5-AB3E-CF28AA04549E@apple.com> <4D1BF59E.2020400@callenish.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D1BF59E.2020400@callenish.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 12:36:00 -0000 Bruce Atherton wrote: > You are right, that is another cost to having the added security of > per-channel keys, beyond the few bytes. I see this as being the same as > removing the ability to provide a payload from the client in the initial > handshake when a connection is first created. Well worth the price for > the security provided. > > To me, opening a communications channel should have the same level of > security whether it shares a socket or not. It depends what you mean by a "channel". Round-tripless setup means you can create and destroy channels so fast that it's efficient to use unique channels for every HTTP-like request/response pair (i.e. RPC) over the WebSocket. It means there is no motivation for app designers to avoid using it and roll their own. Then the browser & server implementations are responsible for keeping those channels semantically separate. (Framing, etc.) Arguably that would be *more* secure than the current plan, where we expect sites to smoosh together independent WebSocket-using components on the site into a single WebWorker-driven connection using *application*-designed framing & muxing (overlaid), to the extent it's technically feasible. Possibly by replacing the browser's window.WebSocket object site-wide with a Javascript version. Precisely because of that round trip overhead (and other overheads). Pushing framing & muxing towards application designers and app-specific protocols is totally in keeping with the original WebSocket philosophy, but it's not a great security recipe. -- Jamie From gregw@intalio.com Sun Jan 2 07:07:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435B93A698F for ; Sun, 2 Jan 2011 07:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+CVi5CyCwtW for ; Sun, 2 Jan 2011 07:07:47 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 765C33A6979 for ; Sun, 2 Jan 2011 07:07:47 -0800 (PST) Received: by vws7 with SMTP id 7so5359697vws.31 for ; Sun, 02 Jan 2011 07:09:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.195.10 with SMTP id ea10mr2402456vcb.1.1293980993672; Sun, 02 Jan 2011 07:09:53 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 2 Jan 2011 07:09:53 -0800 (PST) In-Reply-To: References: <4D12AD9C.7090503@callenish.com> <4D14121E.7020601@callenish.com> <4D191026.9030303@ducksong.com> Date: Sun, 2 Jan 2011 16:09:53 +0100 X-Google-Sender-Auth: UyT5bnHY8bPDENj7wyWcbm2G_p4 Message-ID: From: Greg Wilkins To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Flexibility should be a design consideration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 15:07:48 -0000 On 28 December 2010 12:33, Eric Rescorla wrote: > > On Tue, Dec 28, 2010 at 12:47 AM, Greg Wilkins wrote: >> >> Nobody has given a technical reason to not just mask the payloads? >> why not? =A0 =A0Is the only objection that this gives us the flexibility >> to have optional or alternate masking? =A0 that is a pretty poor reason. > > Really? I thought at least one person mentioned that they were worried ab= out > the attacker controlling extensions. Regardless, I think that's clearly a > technical > reason. I don't understand why attackers controlling extensions is a technical reason to mask the framing? From gregw@intalio.com Sun Jan 2 07:12:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E24D3A6994 for ; Sun, 2 Jan 2011 07:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifPx2zuZkPGr for ; Sun, 2 Jan 2011 07:12:56 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 495A43A698F for ; Sun, 2 Jan 2011 07:12:56 -0800 (PST) Received: by qyj19 with SMTP id 19so13690681qyj.10 for ; Sun, 02 Jan 2011 07:15:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.214.71 with SMTP id gz7mr4759393qab.349.1293981302813; Sun, 02 Jan 2011 07:15:02 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 2 Jan 2011 07:15:02 -0800 (PST) In-Reply-To: References: Date: Sun, 2 Jan 2011 16:15:02 +0100 X-Google-Sender-Auth: V8KZf-qA0DnQs-L5XSvlxWJ2Y8o Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 15:12:57 -0000 On 28 December 2010 05:25, John Tamplin wrote: > We could certainly define one, but unless it goes into the base frame > (I would object to that) or there is some flag to indicate that > extension data is present and therefore the length is the first thing > in the extension data, then I don't see how it helps. John, but the proposal to send the key and then mask the framing makes the key part of the base framing. It will be impossible to interpret the framing without handling masking and effectively we have defined a new framing field before the existing ones that is the masking key. So whatever reasons you have for objecting to a masking key in the base framing, surely they apply to sending key+masked-frame-header+masked-payload. From ekr@rtfm.com Sun Jan 2 07:16:54 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D763A6994 for ; Sun, 2 Jan 2011 07:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0Ijt11E76z8 for ; Sun, 2 Jan 2011 07:16:53 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 669E23A6998 for ; Sun, 2 Jan 2011 07:16:53 -0800 (PST) Received: by yxt33 with SMTP id 33so5717012yxt.31 for ; Sun, 02 Jan 2011 07:19:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.114.5 with SMTP id m5mr11112906agc.25.1293981539897; Sun, 02 Jan 2011 07:18:59 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sun, 2 Jan 2011 07:18:59 -0800 (PST) In-Reply-To: References: <4D12AD9C.7090503@callenish.com> <4D14121E.7020601@callenish.com> <4D191026.9030303@ducksong.com> Date: Sun, 2 Jan 2011 07:18:59 -0800 Message-ID: From: Eric Rescorla To: Greg Wilkins Content-Type: multipart/alternative; boundary=0016361e84fc08156e0498de8ebf Cc: hybi@ietf.org Subject: Re: [hybi] Flexibility should be a design consideration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 15:16:54 -0000 --0016361e84fc08156e0498de8ebf Content-Type: text/plain; charset=ISO-8859-1 It's a reason to mask the extensions. -Ekr On Sun, Jan 2, 2011 at 7:09 AM, Greg Wilkins wrote: > On 28 December 2010 12:33, Eric Rescorla wrote: > > > > On Tue, Dec 28, 2010 at 12:47 AM, Greg Wilkins > wrote: > >> > >> Nobody has given a technical reason to not just mask the payloads? > >> why not? Is the only objection that this gives us the flexibility > >> to have optional or alternate masking? that is a pretty poor reason. > > > > Really? I thought at least one person mentioned that they were worried > about > > the attacker controlling extensions. Regardless, I think that's clearly a > > technical > > reason. > > I don't understand why attackers controlling extensions is a technical > reason to mask the framing? > --0016361e84fc08156e0498de8ebf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's a reason to mask the extensions.

-Ekr


On Sun, Jan 2, 2011 at 7:09 AM, Greg Wi= lkins <gregw@webt= ide.com> wrote:
On 28 December 2010 12:33= , Eric Rescorla <ekr@rtfm.com> wr= ote:
>
> On Tue, Dec 28, 2010 at 12:47 AM, Greg Wilkins <gregw@webtide.com> wrote:
>>
>> Nobody has given a technical reason to not= just mask the payloads?
>> why not? =A0 =A0Is the only objection that this gives us the flexi= bility
>> to have optional or alternate masking? =A0 that is a pretty poor r= eason.
>
> Really? I thought at least one person mentioned that they were worried= about
> the attacker controlling extensions. Regardless, I think that's cl= early a
> technical
> reason.

I don't understand why attackers controlling extensions is a tech= nical
reason to mask the framing?

--0016361e84fc08156e0498de8ebf-- From gregw@intalio.com Sun Jan 2 08:17:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B503A6979 for ; Sun, 2 Jan 2011 08:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLluynd+J5CJ for ; Sun, 2 Jan 2011 08:17:25 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4B5653A696A for ; Sun, 2 Jan 2011 08:17:25 -0800 (PST) Received: by vws7 with SMTP id 7so5373004vws.31 for ; Sun, 02 Jan 2011 08:19:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.194.69 with SMTP id dx5mr6548005vcb.60.1293985171506; Sun, 02 Jan 2011 08:19:31 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 2 Jan 2011 08:19:31 -0800 (PST) In-Reply-To: References: <4D12AD9C.7090503@callenish.com> <4D14121E.7020601@callenish.com> <4D191026.9030303@ducksong.com> Date: Sun, 2 Jan 2011 17:19:31 +0100 X-Google-Sender-Auth: MLZLqys6gQpaS0vdfrWSCi5yxBY Message-ID: From: Greg Wilkins To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] Flexibility should be a design consideration X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 16:17:26 -0000 On 2 January 2011 16:18, Eric Rescorla wrote: > It's a reason to mask the extensions. Sure, and I'm not opposed to that. If the masking key is placed in the extension data space, then it can can apply to all extensions data after the key. If the key is in the framing header, then it can apply to all extension data. I still have not seen any reason to mask the actual framing and I've given several good reasons why not to mask the framing - which are independent of the questions about optional or not, extension or not. regards From bruce@callenish.com Sun Jan 2 11:05:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599D43A68C8 for ; Sun, 2 Jan 2011 11:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zROe5xCP6XAR for ; Sun, 2 Jan 2011 11:05:57 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 5E3D53A6869 for ; Sun, 2 Jan 2011 11:05:57 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PZTHf-0007Nb-EP for hybi@ietf.org; Sun, 02 Jan 2011 11:08:03 -0800 Message-ID: <4D20CD19.8030408@callenish.com> Date: Sun, 02 Jan 2011 11:08:09 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <4D154847.4040908@callenish.com> <4D1A490C.80202@callenish.com> <443B426A-BC34-48E6-8525-F8E98667E82C@apple.com> <4D1A94C5.2040404@callenish.com> <95CC9C10-A790-46B5-AB3E-CF28AA04549E@apple.com> <4D1BF59E.2020400@callenish.com> <20110102123803.GE20751@shareable.org> In-Reply-To: <20110102123803.GE20751@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 19:05:58 -0000 On 02/01/2011 4:38 AM, Jamie Lokier wrote: > Round-tripless setup means you can create and destroy channels so fast > that it's efficient to use unique channels for every HTTP-like > request/response pair (i.e. RPC) over the WebSocket. That describes Websocket messages. There is no need to introduce muxable channels in that scenario. I think we are talking about different things. > It means there is no motivation for app designers to avoid using it > and roll their own. > > Then the browser& server implementations are responsible for keeping > those channels semantically separate. (Framing, etc.) > > Arguably that would be *more* secure than the current plan, where we > expect sites to smoosh together independent WebSocket-using components > on the site into a single WebWorker-driven connection using > *application*-designed framing& muxing (overlaid), to the extent it's > technically feasible. Possibly by replacing the browser's > window.WebSocket object site-wide with a Javascript version. > Precisely because of that round trip overhead (and other overheads). > > Pushing framing& muxing towards application designers and > app-specific protocols is totally in keeping with the original > WebSocket philosophy, but it's not a great security recipe. It sounds to me like you are arguing against client-side muxing. Note that that is a different argument. Maciej was saying that there didn't seem to be a point to introducing some overhead to client-side muxing (assuming that it exists), and I was disagreeing that the overhead wasn't worthwhile. I have to admit I really don't get what you are saying about why you wouldn't want the ability to separate channels. One can imagine a web page with a channel for a chat client for CRM and another for server-side form validation. If the CRM app is supplied by a third party, the server for it may well run in a sandboxed environment with the primary Websocket server distributing Websocket messages to it. You really don't want the chat app to be able to start mucking around with the form data. You may be able to protect against this in other ways, but why not allow the people deploying these apps to treat them as completely separate "virtual sockets" without all the socket overhead and without having to reinvent the wheel? That's my perspective, anyway. But this thread was really about whether or not framing should be masked, and this portion focused specifically on whether there was an example of an appliance that didn't need to unmask and remask. I think it is clear that there well could be, but we seem to have strayed a long way from that topic. From gregw@intalio.com Sun Jan 2 14:14:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2DE28C0EB for ; Sun, 2 Jan 2011 14:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRb5zfyH9R7L for ; Sun, 2 Jan 2011 14:14:42 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A8D5E3A6927 for ; Sun, 2 Jan 2011 14:14:42 -0800 (PST) Received: by vws7 with SMTP id 7so5451223vws.31 for ; Sun, 02 Jan 2011 14:16:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.187.132 with SMTP id cw4mr3073930vcb.25.1294006608859; Sun, 02 Jan 2011 14:16:48 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 2 Jan 2011 14:16:48 -0800 (PST) In-Reply-To: <443B426A-BC34-48E6-8525-F8E98667E82C@apple.com> References: <4D154847.4040908@callenish.com> <4D1A490C.80202@callenish.com> <443B426A-BC34-48E6-8525-F8E98667E82C@apple.com> Date: Sun, 2 Jan 2011 23:16:48 +0100 X-Google-Sender-Auth: Fc-m9Uw5nPxr12icvrGcz7spyNE Message-ID: From: Greg Wilkins To: Maciej Stachowiak Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 22:14:43 -0000 On 29 December 2010 00:31, Maciej Stachowiak wrote: > Yes. In masking as currently proposed, the actual mask applied is based on a combination of the per-frame > key and a per-connection key, derived from the server and client nonces. I think that having a per-connection key has cons that greatly outweigh any pros. A per-frame key is sufficient to prevent clear text and a per-connection key will make frames non-self describing. This will make it more difficult to create tools such as wireshark plugins to analyse ws streams. I understand that the concern is that a pre-recorded frame might be able to be used in an attack, but such an attack relies on the ability to send arbitrary bytes, and we already know from Adam's/Erics experiment that if you can send arbitrary bytes, you can attack vulnerable intermediaries. regards From ekr@rtfm.com Sun Jan 2 14:18:07 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3683228C0EB for ; Sun, 2 Jan 2011 14:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.095 X-Spam-Level: X-Spam-Status: No, score=-102.095 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq2FBUqoS+St for ; Sun, 2 Jan 2011 14:18:06 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 4EEB63A6927 for ; Sun, 2 Jan 2011 14:18:06 -0800 (PST) Received: by yie19 with SMTP id 19so3533259yie.31 for ; Sun, 02 Jan 2011 14:20:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.2.23 with SMTP id 23mr11696602agb.106.1294006812832; Sun, 02 Jan 2011 14:20:12 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sun, 2 Jan 2011 14:20:12 -0800 (PST) In-Reply-To: References: <4D154847.4040908@callenish.com> <4D1A490C.80202@callenish.com> <443B426A-BC34-48E6-8525-F8E98667E82C@apple.com> Date: Sun, 2 Jan 2011 14:20:12 -0800 Message-ID: From: Eric Rescorla To: Greg Wilkins Content-Type: multipart/alternative; boundary=00163631086b6a74c20498e470b4 Cc: "hybi@ietf.org" Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 22:18:07 -0000 --00163631086b6a74c20498e470b4 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 2, 2011 at 2:16 PM, Greg Wilkins wrote: > On 29 December 2010 00:31, Maciej Stachowiak wrote: > > Yes. In masking as currently proposed, the actual mask applied is based > on a combination of the per-frame > > key and a per-connection key, derived from the server and client nonces. > > I think that having a per-connection key has cons that greatly > outweigh any pros. > > A per-frame key is sufficient to prevent clear text and a > per-connection key will make frames non-self describing. This will > make it more difficult to create tools such as wireshark plugins to > analyse ws streams. I've built several passive analysis systems of this type and in my experience this just isn't correct. You already need to maintain a fair amount of per-connection state to deal with the fact that the TCP segment boundaries don't line up with the frame boundaries. Maintaining a per-connection key is much easier. -Ekr --00163631086b6a74c20498e470b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jan 2, 2011 at 2:16 PM, Greg Wil= kins <gregw@webti= de.com> wrote:
On 29 December 2010 00:31, Maciej Stachowiak <mjs@apple.com> wrote:
> Yes. In masking as currently proposed, the actual mask applied is base= d on a combination of the per-frame
> key and a per-connection key, derived from the server and client nonce= s.

I think that having a per-connection key has cons that greatly
outweigh any pros.

A per-frame key is sufficient to prevent clear text and a
per-connection key will make frames non-self describing. This will
make it more difficult to create tools such as wireshark plugins to
analyse ws streams.

I've built several = passive analysis systems of this type and in my experience this=A0
just isn't correct.

You already need to main= tain a fair amount of per-connection state to deal with
the fact that the TCP segment boundaries don't line up with the fr= ame boundaries.
Maintaining a per-connection key is much easier.<= /div>

-Ekr


--00163631086b6a74c20498e470b4-- From theturtle32@gmail.com Sun Jan 2 14:47:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479AD28C0EB for ; Sun, 2 Jan 2011 14:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHLhIEAJSBkR for ; Sun, 2 Jan 2011 14:47:39 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 19D343A6927 for ; Sun, 2 Jan 2011 14:47:39 -0800 (PST) Received: by iyi42 with SMTP id 42so12740720iyi.31 for ; Sun, 02 Jan 2011 14:49:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=quLRbauWYwfGWAGT+1yNTEotX5m+swDIgooEkKEAqXI=; b=F6o9MB8uLFlRQURVHbXI5lN7SLppsYVesG2BcVyICOkYuGiX8v0Y6GuQ2lutjm2EX2 TzVOzWL+Qd3ZxxGlPlHwKIkJd6XCP/eHdOKgRl9JVnXl7lfxpMvAnUZzNOEZzY4avb/s 2KxVYJmyWqXs1ucq4+xUP7c114C/NWIoJ6sgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=ncaj9J7ezihv1vMa0chRJek+OVtVwKleR0iNpMctupzq6njC2794VVH8GEDWdQjLzJ iWzyRE0ex28KETO0fBYlO+SC1aNlsSont6o2ecsVMrAihL3+L9YLYAkS7+9J/B8CzmSv +mP8NkEG1dGmLyCjF963VsVHME0STeIVCdP70= Received: by 10.42.223.4 with SMTP id ii4mr20439636icb.4.1294008585603; Sun, 02 Jan 2011 14:49:45 -0800 (PST) Received: from [192.168.0.22] (cpe-76-167-26-250.socal.res.rr.com [76.167.26.250]) by mx.google.com with ESMTPS id gy41sm18134313ibb.11.2011.01.02.14.49.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Jan 2011 14:49:44 -0800 (PST) References: <4D154847.4040908@callenish.com> <4D1A490C.80202@callenish.com> <443B426A-BC34-48E6-8525-F8E98667E82C@apple.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1-21286833 Message-Id: <05DC93DB-C707-47D3-BD82-071C552B8EAC@gmail.com> X-Mailer: iPhone Mail (8C148) From: Brian McKelvey Date: Sun, 2 Jan 2011 14:49:40 -0800 To: Eric Rescorla Cc: "hybi@ietf.org" Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 22:47:41 -0000 --Apple-Mail-1-21286833 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It also means that you wouldn't be able to analyze the transmission at all i= f you started listening on the wire after the connection had already been es= tablished.. I'd be happy to live with that though. Brian Sent from my iPhone On Jan 2, 2011, at 2:20 PM, Eric Rescorla wrote: >=20 >=20 > On Sun, Jan 2, 2011 at 2:16 PM, Greg Wilkins wrote: > On 29 December 2010 00:31, Maciej Stachowiak wrote: > > Yes. In masking as currently proposed, the actual mask applied is based o= n a combination of the per-frame > > key and a per-connection key, derived from the server and client nonces.= >=20 > I think that having a per-connection key has cons that greatly > outweigh any pros. >=20 > A per-frame key is sufficient to prevent clear text and a > per-connection key will make frames non-self describing. This will > make it more difficult to create tools such as wireshark plugins to > analyse ws streams. >=20 > I've built several passive analysis systems of this type and in my experie= nce this=20 > just isn't correct. >=20 > You already need to maintain a fair amount of per-connection state to deal= with > the fact that the TCP segment boundaries don't line up with the frame boun= daries. > Maintaining a per-connection key is much easier. >=20 > -Ekr >=20 >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --Apple-Mail-1-21286833 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
It also means that you wouldn't be able to analyze the transmission at all if you started listening on the wire after the connection had already been established..  I'd be happy to live with that though.

Brian

Sent from my iPhone

On Jan 2, 2011, at 2:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Sun, Jan 2, 2011 at 2:16 PM, Greg Wilkins <gregw@webtide.com> wrote:
On 29 December 2010 00:31, Maciej Stachowiak <mjs@apple.com> wrote:
> Yes. In masking as currently proposed, the actual mask applied is based on a combination of the per-frame
> key and a per-connection key, derived from the server and client nonces.

I think that having a per-connection key has cons that greatly
outweigh any pros.

A per-frame key is sufficient to prevent clear text and a
per-connection key will make frames non-self describing. This will
make it more difficult to create tools such as wireshark plugins to
analyse ws streams.

I've built several passive analysis systems of this type and in my experience this 
just isn't correct.

You already need to maintain a fair amount of per-connection state to deal with
the fact that the TCP segment boundaries don't line up with the frame boundaries.
Maintaining a per-connection key is much easier.

-Ekr


_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi
--Apple-Mail-1-21286833-- From jat@google.com Sun Jan 2 15:11:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2D728C0EB for ; Sun, 2 Jan 2011 15:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.964 X-Spam-Level: X-Spam-Status: No, score=-103.964 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezVO4D6aF0Wu for ; Sun, 2 Jan 2011 15:11:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A84C53A6932 for ; Sun, 2 Jan 2011 15:11:20 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p02NDQkE030725 for ; Sun, 2 Jan 2011 15:13:27 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294010007; bh=OvmfLPsqA5hAKtyfW/xs5EQObsE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=McOlRw7fdBe4O5TQ0thP3rselvhL34pEhfwh4rnQI6XYJ/tUjPXYN3J3xO0sFyF0F 5TERvFh0LD4S+G4VZ+29A== Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by hpaq11.eem.corp.google.com with ESMTP id p02NDO0v005946 for ; Sun, 2 Jan 2011 15:13:25 -0800 Received: by gyb11 with SMTP id 11so5025569gyb.19 for ; Sun, 02 Jan 2011 15:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=2yAmytSoZiawNTdbFQmm83uYDoXOL6W0sO3wtoYQLdU=; b=SCEiM2oLS7oaa0e2G+9jsTtWsjWUY/eTkVKDf418Na0kM7GcU1RKYBqnP6G9HQs9od vO081C1bfVWIImnmV/Fg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=dm/MyOywVKOmvw5INl1qsdFZmqUOct5qrOFKDoalNMFhx7UC+XKp8uUb+Feo6h3iGt dinKYBaPL+G8YeCURdew== Received: by 10.101.208.21 with SMTP id k21mr11571000anq.240.1294010004582; Sun, 02 Jan 2011 15:13:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Sun, 2 Jan 2011 15:13:04 -0800 (PST) In-Reply-To: References: From: John Tamplin Date: Sun, 2 Jan 2011 18:13:04 -0500 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: hybi Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 23:11:22 -0000 On Sun, Jan 2, 2011 at 10:15 AM, Greg Wilkins wrote: > but the proposal to send the key and then mask the framing makes the > key part of the base framing. > It will be impossible to interpret the framing without handling > masking and effectively we have defined a new framing field before the > existing ones that =C2=A0is the masking key. > > So whatever reasons you have for objecting to a masking key in the > base framing, surely they apply to sending > key+masked-frame-header+masked-payload. My objection is trying to renegotiate the existing framing mechanism, rather than simply adding a layer above it where it remains the same in both directions, with the only difference being adding an outer layer on client->server. --=20 John A. Tamplin Software Engineer (GWT), Google From gregw@intalio.com Sun Jan 2 16:01:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA2F28C0ED for ; Sun, 2 Jan 2011 16:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3kEUF5fE0OJ for ; Sun, 2 Jan 2011 16:01:41 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id EEB5728C0EC for ; Sun, 2 Jan 2011 16:01:40 -0800 (PST) Received: by qwg5 with SMTP id 5so13659119qwg.31 for ; Sun, 02 Jan 2011 16:03:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.53.213 with SMTP id n21mr18687636qag.399.1294013027517; Sun, 02 Jan 2011 16:03:47 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 2 Jan 2011 16:03:47 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Jan 2011 01:03:47 +0100 X-Google-Sender-Auth: D2m1-6yUO8YraupspohVgr3wpps Message-ID: From: Greg Wilkins To: hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 00:01:41 -0000 On 3 January 2011 00:13, John Tamplin wrote: > My objection is trying to renegotiate the existing framing mechanism, > rather than simply adding a layer above it where it remains the same > in both directions, with the only difference being adding an outer > layer on client->server. John, Wrapping the existing framing in a new masking frame is renegotiating the framing and that is why am strongly opposed to it. We can avoid renegotiating the current framing by putting the key either in the already negotiated extension data or in the payload itself. regards From jat@google.com Sun Jan 2 19:47:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0001E3A697B for ; Sun, 2 Jan 2011 19:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.625 X-Spam-Level: X-Spam-Status: No, score=-104.625 tagged_above=-999 required=5 tests=[AWL=-2.649, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLzprfdkg9pJ for ; Sun, 2 Jan 2011 19:47:11 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 878C13A6936 for ; Sun, 2 Jan 2011 19:47:10 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p033nG2e028379 for ; Sun, 2 Jan 2011 19:49:16 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294026556; bh=+tO54+f6krxXpFKTjFRXm5QwCsw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=HYhcEKPjbCXa40tBnou94r0QWOEPsT3vqAAQXoInEpkELaGkyY9PEyP0urJ3ldpWy 5lqmDPUl9pqbqFOqIX4bw== Received: from ywa6 (ywa6.prod.google.com [10.192.1.6]) by hpaq1.eem.corp.google.com with ESMTP id p033nEmc009399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 2 Jan 2011 19:49:15 -0800 Received: by ywa6 with SMTP id 6so6845893ywa.26 for ; Sun, 02 Jan 2011 19:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=lktpTovWlWE7KACp5ZP2jNxxPtQhqa0DnGF9ggAfPpc=; b=d4yrocPgIUrLyLIafVN8d9tHu7RTEswZcBzyGl5VJm7Hn5kfC5NS5hkBQR8tAZTB89 FUH0Oti1MTklvPj0MSaQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=VB3esEOsoaklvRsUHW1tz7yTb9g5X9RRIM1hYHTyqLJbeZ0AJD+JdNnmlxAe6Z2wAB mUdCe4CPNWqefNnr1ChQ== Received: by 10.90.69.15 with SMTP id r15mr11869610aga.155.1294026554559; Sun, 02 Jan 2011 19:49:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Sun, 2 Jan 2011 19:48:54 -0800 (PST) In-Reply-To: References: From: John Tamplin Date: Sun, 2 Jan 2011 22:48:54 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=0016364ee1e41d4d9c0498e90983 X-System-Of-Record: true Cc: hybi Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 03:47:12 -0000 --0016364ee1e41d4d9c0498e90983 Content-Type: text/plain; charset=UTF-8 On Sun, Jan 2, 2011 at 7:03 PM, Greg Wilkins wrote: > On 3 January 2011 00:13, John Tamplin wrote: > > My objection is trying to renegotiate the existing framing mechanism, > > rather than simply adding a layer above it where it remains the same > > in both directions, with the only difference being adding an outer > > layer on client->server. > > Wrapping the existing framing in a new masking frame is renegotiating > the framing and that is why am strongly opposed to it. > I disagree -- is carrying the defined WebSocket frames inside an SSL session redefining the WebSocket framing? In the same way, adding an extra framing outside of the existing WebSocket framing, which does nothing but add masking, seems exactly analogous to SSL. We can avoid renegotiating the current framing by putting the key > either in the already negotiated extension data or in the payload > itself. The problem is that the framing as specified now, says that the reserved bits will be zero and the extension data area will be empty. We could certainly change that, but again that is going back into defining the framing that we have already agreed upon at a significant cost. I previously wrote up what I thought it would take to make the masking an extension that would fit into what we already defined. However, there is a lot of things that we deferred that would have to be defined in order to do that, and there were significant objections to making it optional. I suppose we could define all that and then define that all implementations, barring connections that never transit outside a trusted network, must request the extension and fail the connection if it isn't accepted. However, that seems to me to really be raising the minimum bar for simple implementations, compared to just adding a masking layer around all of WebSockets (not to mention it seems like it will be a lot harder to get agreement on all those details). -- John A. Tamplin Software Engineer (GWT), Google --0016364ee1e41d4d9c0498e90983 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 2, 2011 at 7:03 PM, Greg Wilkins <gregw@webtide.com> wrote:
On 3 January 2011 00:13, John Tamplin <jat@google.com> wrote:
> My objection is trying to renegotiate the existing framing mechanism,<= br> > rather than simply adding a layer above it where it remains the same > in both directions, with the only difference being adding an outer
> layer on client->server.

Wrapping the existing framing in a new masking frame is renegotiating=
the framing and that is why am strongly opposed to it.

I disagree -- is carrying the defined WebSocket frames insi= de an SSL session redefining the WebSocket framing? =C2=A0In the same way, = adding an extra framing outside of the existing WebSocket framing, which do= es nothing but add masking, seems exactly analogous to SSL.=C2=A0

We can avoid renegotiating the current framing by =C2=A0putting the key
either in the already negotiated extension data or in the payload
itself.

The problem is that the framing as = specified now, says that the reserved bits will be zero and the extension d= ata area will be empty. =C2=A0We could certainly change that, but again tha= t is going back into defining the framing that we have already agreed upon = at a significant cost.

I previously wrote up what I thought it would take to m= ake the masking an extension that would fit into what we already defined. = =C2=A0However, there is a lot of things that we deferred that would have to= be defined in order to do that, and there were significant objections to m= aking it optional. =C2=A0I suppose we could define all that and then define= that all implementations, barring connections that never transit outside a= trusted network, must request the extension and fail the connection if it = isn't accepted. =C2=A0However, that seems to me to really be raising th= e minimum bar for simple implementations, compared to just adding a masking= layer around all of WebSockets (not to mention it seems like it will be a = lot harder to get agreement on all those details).

--
John A. Tamplin
Software Engineer (GWT), Google
--0016364ee1e41d4d9c0498e90983-- From gregw@intalio.com Mon Jan 3 00:40:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1874B3A69C2 for ; Mon, 3 Jan 2011 00:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZF+-7VfmbD4 for ; Mon, 3 Jan 2011 00:40:08 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 244B73A6989 for ; Mon, 3 Jan 2011 00:40:08 -0800 (PST) Received: by qyj19 with SMTP id 19so14119854qyj.10 for ; Mon, 03 Jan 2011 00:42:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.87.13 with SMTP id u13mr17266031qcl.55.1294044134790; Mon, 03 Jan 2011 00:42:14 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Mon, 3 Jan 2011 00:42:14 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Jan 2011 09:42:14 +0100 X-Google-Sender-Auth: _UbFXj6hTPapHlMgti18iqYkIgM Message-ID: From: Greg Wilkins To: hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 08:40:09 -0000 On 3 January 2011 04:48, John Tamplin wrote: > I disagree -- is carrying the defined WebSocket frames inside an SSL session redefining the WebSocket > framing? In the same way, adding an extra framing outside of the existing WebSocket framing, which does > nothing but add masking, seems exactly analogous to SSL. John, It is one thing to propose wrapping WS framing in an existing standard and an entirely different thing to propose a new masking mechanism to wrap WS framing. Besides, looking at SSL as an example, it has well defined framing that is sent in the clear, so that intermediaries can analyse and correctly handle SSL, without actually having to decrypt the payload. > The problem is that the framing as specified now, says that the reserved > bits will be zero and the extension data area will be empty. ... > lot of things that we deferred that would have to be defined in order to do > that, If the extension mechanism as defined can't cope with something as simple as masking, then we have further work to do. If we deferr consideration of working extensions, then we will just end up with an unusable extension mechanism. But is there really a lot of things to change? we could use a reserved bit to indicate masking and that would stay within the current draft. Or we could change one section in the draft to allow extensions to use extension data without using reserve bits (which I think is sensible else we limit the number of extensions possible). > and there were significant objections to making it optional. This is not about making it optional, it is about making it agile so that there is the option of making it optional and/or replaceable either now or in the distant future. From w@1wt.eu Wed Jan 5 01:55:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109583A6B6E for ; Wed, 5 Jan 2011 01:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpVR8nxtAtrE for ; Wed, 5 Jan 2011 01:55:28 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id D49383A6949 for ; Wed, 5 Jan 2011 01:55:27 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p059vRuv016263 for hybi@ietf.org; Wed, 5 Jan 2011 10:57:27 +0100 Date: Wed, 5 Jan 2011 10:57:27 +0100 From: Willy Tarreau To: hybi Message-ID: <20110105095727.GE15851@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 09:55:29 -0000 Hi, considering the amount of complexity we're trying to add to the protocol to solve just a small part of hypothetical cases, I'm wondering why we could not go with a pragmatic approach : - use the hello frames and swap the more/fin bits as suggested by Greg & Gabriel - add the "close" statement to the Connection header in the requests With all that, for an intermediary to fail, it will be required that : - it does not understand status code 101 (around 1/50000 in Adam's tests if my memory serves me right) - it supports HTTP keep-alive - is able to find an HTTP request starting with a method composed of invalid chars (no such intermediary has been identified so far) - is able to accept a second request despite the "Connection: close" in the request (no such intermediary identified so far, though Greg admitted that this had been the case for an older server of his). This might probably leave us with something between 0 and 1 in one million possibly vulnerable intermediaries. Those if they even exist would be particularly buggy considering that they have to fail on #3 above. Please also note that #2 is already quite difficult to implement, which contradicts the sloppiness of #3. My question is : why should we bother for those ? We're making a mess with the WebSocket protocol just because we suspect that there might exist some stupid developers who probably quickly wrote something they called a proxy in just an afternoon for their own use. If such products exist they surely are not waiting for WebSocket to be exploited (eg: chunked encoding or multiple content-lengths are even harder to get right than content-length). So couldn't we focus on more-or-less HTTP-compliant implementations only, cover a few implementation bugs and stop bothering about the most unlikely scenarii involving deliberate bugs ? At one point, we should not try to fix what people deliberately broke for their own use. Best regards, Willy From salvatore.loreto@ericsson.com Wed Jan 5 02:46:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667EA3A6B76 for ; Wed, 5 Jan 2011 02:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEn2oooIFUvN for ; Wed, 5 Jan 2011 02:46:41 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CE41A3A6AFA for ; Wed, 5 Jan 2011 02:46:40 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-18-4d244c8ed78f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F2.AA.23694.E8C442D4; Wed, 5 Jan 2011 11:48:46 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Wed, 5 Jan 2011 11:48:46 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1E9E4232D for ; Wed, 5 Jan 2011 12:48:46 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D7B5F5052A for ; Wed, 5 Jan 2011 12:48:45 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 67424503CF for ; Wed, 5 Jan 2011 12:48:45 +0200 (EET) Message-ID: <4D244C8C.7050601@ericsson.com> Date: Wed, 5 Jan 2011 11:48:44 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110105095727.GE15851@1wt.eu> In-Reply-To: <20110105095727.GE15851@1wt.eu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] Reminder: Straw Poll on GET+Upgrade+Masking ends on January 7th (was Re: A bit of pragmatism) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 10:46:42 -0000 Hi Willy, thanks for your proposal, but I would like folks to focus the discussion on the poll we are running at moment on Get+Upgrade+Masking (btw the poll will over in two days: on January Friday 7th). We are seeing a good consensus support for at least accepting (if not advocating) it: of course there are still technical details that need to be defined and people are still discussing, but the wheels are spinning. For the chairs it is a great relief to see this much agreement. Masking adds complexity to the protocol, that is true, but the cost of masking is a reasonable price that we have to pay to security, and a lot of people seem to be happy to compromise with it. cheers /Sal -- Salvatore Loreto www.sloreto.com On 1/5/11 10:57 AM, Willy Tarreau wrote: > Hi, > > considering the amount of complexity we're trying to add to the protocol > to solve just a small part of hypothetical cases, I'm wondering why we > could not go with a pragmatic approach : > > - use the hello frames and swap the more/fin bits as suggested by > Greg& Gabriel > - add the "close" statement to the Connection header in the requests > > With all that, for an intermediary to fail, it will be required that : > - it does not understand status code 101 (around 1/50000 in Adam's tests > if my memory serves me right) > > - it supports HTTP keep-alive > > - is able to find an HTTP request starting with a method composed of > invalid chars (no such intermediary has been identified so far) > > - is able to accept a second request despite the "Connection: close" > in the request (no such intermediary identified so far, though Greg > admitted that this had been the case for an older server of his). > > This might probably leave us with something between 0 and 1 in one million > possibly vulnerable intermediaries. Those if they even exist would be > particularly buggy considering that they have to fail on #3 above. Please > also note that #2 is already quite difficult to implement, which contradicts > the sloppiness of #3. > > My question is : why should we bother for those ? We're making a mess with > the WebSocket protocol just because we suspect that there might exist some > stupid developers who probably quickly wrote something they called a proxy > in just an afternoon for their own use. If such products exist they surely > are not waiting for WebSocket to be exploited (eg: chunked encoding or > multiple content-lengths are even harder to get right than content-length). > > So couldn't we focus on more-or-less HTTP-compliant implementations only, > cover a few implementation bugs and stop bothering about the most unlikely > scenarii involving deliberate bugs ? At one point, we should not try to > fix what people deliberately broke for their own use. > > Best regards, > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From andy.warmcat.com@googlemail.com Wed Jan 5 03:41:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F38B3A6B74 for ; Wed, 5 Jan 2011 03:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wysjs-zCLSsC for ; Wed, 5 Jan 2011 03:41:34 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BE4603A6E15 for ; Wed, 5 Jan 2011 03:41:33 -0800 (PST) Received: by wyf23 with SMTP id 23so15896691wyf.31 for ; Wed, 05 Jan 2011 03:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=cu4StG3svf3uRbH/JynCqyQ/4KFeTVMR8Pt607dNmoM=; b=MNeYuD9WxKE2f8TsvD/uPK/M3Dz1x0wIjVOOmMgNpYOrsKxHWbRmgcSh8fDKJmKLEc 7CE0UAfMcaoGWFlzQEQ86Pv5XYscWnTJ6wUpRP8o2ZMzEB76oTZ3fuDN3KzWX1/kAi+o YnN7noykyZVoKuOxZmCWrQoxqCzVSJjHo2lOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=UBpu1Yi8yuPWVIBtSE+Keo0SMwG7oh3oL1JhFtsfuxZr6az8GWKs45TB8Mm4ESRHRE pGipveSROl0fEGGnh91eiC7qt9ALfO/aN/12+STXC7rh2ezb+PcMukkG2jtF+K9fXmpT fb71q91uKXNK5tDJNaBFsUFyHk8duPJgfKHCM= Received: by 10.227.154.7 with SMTP id m7mr13132618wbw.2.1294227820257; Wed, 05 Jan 2011 03:43:40 -0800 (PST) Received: from [192.168.1.68] (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id f35sm15864630wbf.14.2011.01.05.03.43.38 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 03:43:39 -0800 (PST) Sender: Andy Green Message-ID: <4D245963.5030104@warmcat.com> Date: Wed, 05 Jan 2011 11:43:31 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <20110105095727.GE15851@1wt.eu> In-Reply-To: <20110105095727.GE15851@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 11:42:53 -0000 On 01/05/11 09:57, Somebody in the thread at some point said: Hi - > My question is : why should we bother for those ? We're making a mess with > the WebSocket protocol just because we suspect that there might exist some > stupid developers who probably quickly wrote something they called a proxy > in just an afternoon for their own use. If such products exist they surely > are not waiting for WebSocket to be exploited (eg: chunked encoding or > multiple content-lengths are even harder to get right than content-length). > > So couldn't we focus on more-or-less HTTP-compliant implementations only, > cover a few implementation bugs and stop bothering about the most unlikely > scenarii involving deliberate bugs ? At one point, we should not try to > fix what people deliberately broke for their own use. Couldn't agree more. Security of these alleged intermediaries is out of scope for websockets because they remain as exploitable as they ever were for packets on both sides of them no matter what needless evasive action websockets takes. Over-engineering websockets to death over a non-reproducible problem that websockets can't fix is crazy. What's needed is to rule trying to solve the unsolveable out of scope and finish up any problems from the real world left with -03. -Andy From bruce@callenish.com Wed Jan 5 10:29:06 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5F33A6CDB for ; Wed, 5 Jan 2011 10:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYR7yEZAyDuE for ; Wed, 5 Jan 2011 10:29:05 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 7EAF23A6C17 for ; Wed, 5 Jan 2011 10:29:05 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PaY8d-0005tk-O6 for hybi@ietf.org; Wed, 05 Jan 2011 10:31:11 -0800 Message-ID: <4D24B8F0.9090404@callenish.com> Date: Wed, 05 Jan 2011 10:31:12 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <1293038752.2369.155.camel@ds9.ducksong.com> In-Reply-To: <1293038752.2369.155.camel@ds9.ducksong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:29:06 -0000 On 22/12/2010 9:25 AM, Pat McManus @Mozilla wrote: > With that in mind I want to ask everyone if they think an approach based > on Get+Upgrade containing mandatory client->server XOR masking meets the > bar of an acceptable and good web sockets protocol. I've never understood the asymmetry of this poll. I'm not seeking to block forward progress here, but perhaps someone could explain it to me. The reason I'm confused is that, as a bidirectional protocol, it seems perfectly reasonable to use Websockets for peer to peer communications. If I have two nodes in a cluster and they are communicating with Websockets, which is the client and which is the server? If the one that opens the connection is the client, does that mean that if, in the future, applications are developed where servers initiate Websocket connections to browsers, then they will be the client and the browser will be the server? What does that do to the security guarantees you are looking for? Perhaps the intention is that Websockets are never used for peer to peer connections, or that we fake a client in that situation. But it seems a lot of complication, and what is the gain? That servers have their load reduced? They still have to unmask all those incoming messages, and as I showed in the web portal usecase, the server may be a Websocket client for far more connections than it is a server. Yes, you get sendfile() from server to client as a result. But if, instead, the server had a way of optionally turning off masking in a frame when needed (there I go again) then you could get that in cases where it mattered. Again, I'm not looking to hold anything up here. I think that the language of the straw poll should be adopted and put into the draft (so if it matters, here is a +1). There is far too much resistance here to letting things into the spec IMHO. It should be much easier to get changes in, even if they are later reversed. But at the same time, I hope that this poll does not rule out further discussion on what "mandatory" and "client->server" means. > * It accomplishes this at reasonable cost > + masking is unidirectional and favors the server end. I've worked on > servers in the past and right now I'm working on a browser and I really > do believe that is the right trade off. A browser is much more > interested in latency than in overall load scaling, while a server has > real concerns about the latter. making sendfile() useless to the browser > is no big deal - it doesn't help with latency when compared to IP time > scales and the client is less likely to have the kind of data that would > be zero copied anyhow. From jat@google.com Wed Jan 5 10:33:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276903A6C69 for ; Wed, 5 Jan 2011 10:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.578 X-Spam-Level: X-Spam-Status: No, score=-104.578 tagged_above=-999 required=5 tests=[AWL=-2.602, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZGJaYjeblM7 for ; Wed, 5 Jan 2011 10:33:42 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 7720F3A6BE9 for ; Wed, 5 Jan 2011 10:33:41 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p05IZlEK024087 for ; Wed, 5 Jan 2011 10:35:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294252547; bh=NagYGcYYlmkPl2QYBa10YGrPfCE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=LDeJxs8RgYATwUfOD59CnlTls14ntC1V3xXzpJ9SGh3I0yiY/7hqoHAfGcMMylV5q 7UoW1JiXihWroY4/m0eBw== Received: from gwaa12 (gwaa12.prod.google.com [10.200.27.12]) by wpaz5.hot.corp.google.com with ESMTP id p05IZP4j008229 for ; Wed, 5 Jan 2011 10:35:46 -0800 Received: by gwaa12 with SMTP id a12so3903110gwa.6 for ; Wed, 05 Jan 2011 10:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=173YhMQcfgBgiBOHRuFyTfQFSBDcU5y7vQQdVn8xy5Q=; b=BibRr+YkdL2Rwjb5IeFw9HpZBYqdDI7SWK/XZZIU0n4w3gbsB4xKIfRJH08y9hgjdS NeQSlMcSwoejh//4vOBA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=E/Vq0QC30271FDhg0H/EziX1G2azT3DlzR3lXwfkiMvMdHvBiNgU+ZL+McVBUbLHTJ xk/zRvp+LjhnrZwOjKgA== Received: by 10.150.192.12 with SMTP id p12mr22706591ybf.263.1294252545668; Wed, 05 Jan 2011 10:35:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Wed, 5 Jan 2011 10:35:25 -0800 (PST) In-Reply-To: <4D24B8F0.9090404@callenish.com> References: <1293038752.2369.155.camel@ds9.ducksong.com> <4D24B8F0.9090404@callenish.com> From: John Tamplin Date: Wed, 5 Jan 2011 13:35:25 -0500 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=000e0cd6b11c3bf8b204991da72f X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:33:43 -0000 --000e0cd6b11c3bf8b204991da72f Content-Type: text/plain; charset=UTF-8 On Wed, Jan 5, 2011 at 1:31 PM, Bruce Atherton wrote: > The reason I'm confused is that, as a bidirectional protocol, it seems > perfectly reasonable to use Websockets for peer to peer communications. If I > have two nodes in a cluster and they are communicating with Websockets, > which is the client and which is the server? If the one that opens the > connection is the client, does that mean that if, in the future, > applications are developed where servers initiate Websocket connections to > browsers, then they will be the client and the browser will be the server? > What does that do to the security guarantees you are looking for? Perhaps the intention is that Websockets are never used for peer to peer > connections, or that we fake a client in that situation. But it seems a lot > of complication, and what is the gain? That servers have their load reduced? > They still have to unmask all those incoming messages, and as I showed in > the web portal usecase, the server may be a Websocket client for far more > connections than it is a server. Yes, you get sendfile() from server to > client as a result. But if, instead, the server had a way of optionally > turning off masking in a frame when needed (there I go again) then you could > get that in cases where it mattered. > > Again, I'm not looking to hold anything up here. I think that the language > of the straw poll should be adopted and put into the draft (so if it > matters, here is a +1). There is far too much resistance here to letting > things into the spec IMHO. It should be much easier to get changes in, even > if they are later reversed. But at the same time, I hope that this poll does > not rule out further discussion on what "mandatory" and "client->server" > means. > AFAIK, there has been no discussion of allowing a server to initiate a connection to the client. In many cases, it isn't even possible to do so, and it isn't clear security administrators would want every browser on their network essentially becoming a server. If you control both ends, then why do you need WebSocket at all, rather than just using TCP directly? In any case, it seems allowing such usage is beyond the current scope. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd6b11c3bf8b204991da72f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 5, 2011 at 1:31 PM, Bruce Atherton <= span dir=3D"ltr"><bruce@callenish= .com> wrote:
The reason I'm confused is that, as a bidirectional protocol, it seems = perfectly reasonable to use Websockets for peer to peer communications. If = I have two nodes in a cluster and they are communicating with Websockets, w= hich is the client and which is the server? If the one that opens the conne= ction is the client, does that mean that if, in the future, applications ar= e developed where servers initiate Websocket connections to browsers, then = they will be the client and the browser will be the server? What does that = do to the security guarantees you are looking for?=C2=A0
=C2=A0
Perhaps the intention is that Websockets are never used for peer to peer co= nnections, or that we fake a client in that situation. But it seems a lot o= f complication, and what is the gain? That servers have their load reduced?= They still have to unmask all those incoming messages, and as I showed in = the web portal usecase, the server may be a Websocket client for far more c= onnections than it is a server. Yes, you get sendfile() from server to clie= nt as a result. But if, instead, the server had a way of optionally turning= off masking in a frame when needed (there I go again) then you could get t= hat in cases where it mattered.

Again, I'm not looking to hold anything up here. I think that the langu= age of the straw poll should be adopted and put into the draft (so if it ma= tters, here is a +1). There is far too much resistance here to letting thin= gs into the spec IMHO. It should be much easier to get changes in, even if = they are later reversed. But at the same time, I hope that this poll does n= ot rule out further discussion on what "mandatory" and "clie= nt->server" means.

AFAIK, there has been no discussion of allow= ing a server to initiate a connection to the client. =C2=A0In many cases, i= t isn't even possible to do so, and it isn't clear security adminis= trators would want every browser on their network essentially becoming a se= rver. =C2=A0If you control both ends, then why do you need WebSocket at all= , rather than just using TCP directly?

In any case, it seems allowing such usage is beyond the= current scope.

--
John A. Tamplin
Software Engineer = (GWT), Google
--000e0cd6b11c3bf8b204991da72f-- From jerod.venema@frozenmountain.com Wed Jan 5 10:46:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DA23A6C39 for ; Wed, 5 Jan 2011 10:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny7uafU8ZiWa for ; Wed, 5 Jan 2011 10:46:54 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 30C6F3A6BE9 for ; Wed, 5 Jan 2011 10:46:54 -0800 (PST) Received: by qyj19 with SMTP id 19so16929336qyj.10 for ; Wed, 05 Jan 2011 10:49:01 -0800 (PST) Received: by 10.229.249.17 with SMTP id mi17mr20452596qcb.123.1294253340843; Wed, 05 Jan 2011 10:49:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.8.2 with HTTP; Wed, 5 Jan 2011 10:48:40 -0800 (PST) In-Reply-To: References: <1293038752.2369.155.camel@ds9.ducksong.com> <4D24B8F0.9090404@callenish.com> From: Jerod Venema Date: Wed, 5 Jan 2011 13:48:40 -0500 Message-ID: To: John Tamplin Content-Type: multipart/alternative; boundary=0016e64cc918a15f1904991dd614 Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:46:56 -0000 --0016e64cc918a15f1904991dd614 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 5, 2011 at 1:35 PM, John Tamplin wrote: > On Wed, Jan 5, 2011 at 1:31 PM, Bruce Atherton wrote: > >> The reason I'm confused is that, as a bidirectional protocol, it seems >> perfectly reasonable to use Websockets for peer to peer communications. If I >> have two nodes in a cluster and they are communicating with Websockets, >> which is the client and which is the server? If the one that opens the >> connection is the client, does that mean that if, in the future, >> applications are developed where servers initiate Websocket connections to >> browsers, then they will be the client and the browser will be the server? >> What does that do to the security guarantees you are looking for? > > > > Perhaps the intention is that Websockets are never used for peer to peer >> connections, or that we fake a client in that situation. But it seems a lot >> of complication, and what is the gain? That servers have their load reduced? >> They still have to unmask all those incoming messages, and as I showed in >> the web portal usecase, the server may be a Websocket client for far more >> connections than it is a server. Yes, you get sendfile() from server to >> client as a result. But if, instead, the server had a way of optionally >> turning off masking in a frame when needed (there I go again) then you could >> get that in cases where it mattered. >> >> Again, I'm not looking to hold anything up here. I think that the language >> of the straw poll should be adopted and put into the draft (so if it >> matters, here is a +1). There is far too much resistance here to letting >> things into the spec IMHO. It should be much easier to get changes in, even >> if they are later reversed. But at the same time, I hope that this poll does >> not rule out further discussion on what "mandatory" and "client->server" >> means. >> > > AFAIK, there has been no discussion of allowing a server to initiate a > connection to the client. In many cases, it isn't even possible to do so, > and it isn't clear security administrators would want every browser on their > network essentially becoming a server. If you control both ends, then why > do you need WebSocket at all, rather than just using TCP directly? > Long time reader, first time posting...hi everyone :) I can see plenty of valid use cases for peer-to-peer WebSockets. One in particular that's come up for me recently is video streaming (for, say, live video conferencing) directly in a browser. It'd be great to be able to use peer-to-peer communication under this scenario - reduce lag, overhead, etc. > > In any case, it seems allowing such usage is beyond the current scope. > Whether or not it's in scope is a different question, but there are clearly use-cases for it. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > -- Jerod Venema Frozen Mountain Software http://www.frozenmountain.com/ (w) 919-300-5141 (c) 919-368-5105 --0016e64cc918a15f1904991dd614 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 5, 2011 at 1:35 PM, John Tamplin <jat@google.com>= wrote:
On Wed, Jan 5, 2011 at 1:31 PM= , Bruce Atherton <bruce@callenish.com> wrote:
The reason I'm confused is that, as a bidirectional protocol, it seems = perfectly reasonable to use Websockets for peer to peer communications. If = I have two nodes in a cluster and they are communicating with Websockets, w= hich is the client and which is the server? If the one that opens the conne= ction is the client, does that mean that if, in the future, applications ar= e developed where servers initiate Websocket connections to browsers, then = they will be the client and the browser will be the server? What does that = do to the security guarantees you are looking for?=A0
=A0
Perhaps the intention is that Websockets are never used for peer to peer co= nnections, or that we fake a client in that situation. But it seems a lot o= f complication, and what is the gain? That servers have their load reduced?= They still have to unmask all those incoming messages, and as I showed in = the web portal usecase, the server may be a Websocket client for far more c= onnections than it is a server. Yes, you get sendfile() from server to clie= nt as a result. But if, instead, the server had a way of optionally turning= off masking in a frame when needed (there I go again) then you could get t= hat in cases where it mattered.

Again, I'm not looking to hold anything up here. I think that the langu= age of the straw poll should be adopted and put into the draft (so if it ma= tters, here is a +1). There is far too much resistance here to letting thin= gs into the spec IMHO. It should be much easier to get changes in, even if = they are later reversed. But at the same time, I hope that this poll does n= ot rule out further discussion on what "mandatory" and "clie= nt->server" means.

AFAIK, there has been no discussion = of allowing a server to initiate a connection to the client. =A0In many cas= es, it isn't even possible to do so, and it isn't clear security ad= ministrators would want every browser on their network essentially becoming= a server. =A0If you control both ends, then why do you need WebSocket at a= ll, rather than just using TCP directly?

Long time reader, first time posting= ...hi everyone :)

I can see plenty of valid use ca= ses for peer-to-peer WebSockets. One in particular that's come up for m= e recently is video streaming (for, say, live video conferencing) directly = in a browser. It'd be great to be able to use peer-to-peer communicatio= n under this scenario - reduce lag, overhead, etc.
=A0

In any case, it seems allowing such usage is beyond the= current scope.

Whether or not = it's in scope is a different question, but there are clearly use-cases = for it.
=A0

-= -
John A. Tamplin
Software Engineer (GWT), Google

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi




--
Jerod Venema
Fro= zen Mountain Software
http://= www.frozenmountain.com/
(w) 919-300-5141
(c) 919-368-5105
--0016e64cc918a15f1904991dd614-- From ekr@rtfm.com Wed Jan 5 10:52:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6513A6BE9 for ; Wed, 5 Jan 2011 10:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwDz6HrgXV-0 for ; Wed, 5 Jan 2011 10:52:26 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 99B2E3A6C74 for ; Wed, 5 Jan 2011 10:52:25 -0800 (PST) Received: by yxt33 with SMTP id 33so6895778yxt.31 for ; Wed, 05 Jan 2011 10:54:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.64.2 with SMTP id r2mr1039532agk.133.1294253670591; Wed, 05 Jan 2011 10:54:30 -0800 (PST) Received: by 10.90.154.19 with HTTP; Wed, 5 Jan 2011 10:54:30 -0800 (PST) In-Reply-To: References: <1293038752.2369.155.camel@ds9.ducksong.com> <4D24B8F0.9090404@callenish.com> Date: Wed, 5 Jan 2011 10:54:30 -0800 Message-ID: From: Eric Rescorla To: Jerod Venema Content-Type: multipart/alternative; boundary=001485f6ca5c48eccc04991dead6 Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 18:52:29 -0000 --001485f6ca5c48eccc04991dead6 Content-Type: text/plain; charset=ISO-8859-1 This is a related, but different problem. See: http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-protocols-00 -Ekr On Wed, Jan 5, 2011 at 10:48 AM, Jerod Venema < jerod.venema@frozenmountain.com> wrote: > On Wed, Jan 5, 2011 at 1:35 PM, John Tamplin wrote: > >> On Wed, Jan 5, 2011 at 1:31 PM, Bruce Atherton wrote: >> >>> The reason I'm confused is that, as a bidirectional protocol, it seems >>> perfectly reasonable to use Websockets for peer to peer communications. If I >>> have two nodes in a cluster and they are communicating with Websockets, >>> which is the client and which is the server? If the one that opens the >>> connection is the client, does that mean that if, in the future, >>> applications are developed where servers initiate Websocket connections to >>> browsers, then they will be the client and the browser will be the server? >>> What does that do to the security guarantees you are looking for? >> >> >> >> Perhaps the intention is that Websockets are never used for peer to peer >>> connections, or that we fake a client in that situation. But it seems a lot >>> of complication, and what is the gain? That servers have their load reduced? >>> They still have to unmask all those incoming messages, and as I showed in >>> the web portal usecase, the server may be a Websocket client for far more >>> connections than it is a server. Yes, you get sendfile() from server to >>> client as a result. But if, instead, the server had a way of optionally >>> turning off masking in a frame when needed (there I go again) then you could >>> get that in cases where it mattered. >>> >>> Again, I'm not looking to hold anything up here. I think that the >>> language of the straw poll should be adopted and put into the draft (so if >>> it matters, here is a +1). There is far too much resistance here to letting >>> things into the spec IMHO. It should be much easier to get changes in, even >>> if they are later reversed. But at the same time, I hope that this poll does >>> not rule out further discussion on what "mandatory" and "client->server" >>> means. >>> >> >> AFAIK, there has been no discussion of allowing a server to initiate a >> connection to the client. In many cases, it isn't even possible to do so, >> and it isn't clear security administrators would want every browser on their >> network essentially becoming a server. If you control both ends, then why >> do you need WebSocket at all, rather than just using TCP directly? >> > > Long time reader, first time posting...hi everyone :) > > I can see plenty of valid use cases for peer-to-peer WebSockets. One in > particular that's come up for me recently is video streaming (for, say, live > video conferencing) directly in a browser. It'd be great to be able to use > peer-to-peer communication under this scenario - reduce lag, overhead, etc. > > >> >> In any case, it seems allowing such usage is beyond the current scope. >> > > Whether or not it's in scope is a different question, but there are clearly > use-cases for it. > > >> >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> > > > -- > Jerod Venema > Frozen Mountain Software > http://www.frozenmountain.com/ > (w) 919-300-5141 > (c) 919-368-5105 > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --001485f6ca5c48eccc04991dead6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a related, but different problem. See:=A0
-Ekr


On Wed, Ja= n 5, 2011 at 10:48 AM, Jerod Venema <jerod.venema@frozenmountain.com> wrote:
=
On Wed, Jan 5, 2011 at 1:35 PM, John Tamplin <jat@google.co= m> wrote:
On Wed, Jan 5, 2011 at 1:31 PM, Bruce Ather= ton <bruce@callenish.com> wrote:
The reason I'm confused is that, as a bidirectional protocol, it seems = perfectly reasonable to use Websockets for peer to peer communications. If = I have two nodes in a cluster and they are communicating with Websockets, w= hich is the client and which is the server? If the one that opens the conne= ction is the client, does that mean that if, in the future, applications ar= e developed where servers initiate Websocket connections to browsers, then = they will be the client and the browser will be the server? What does that = do to the security guarantees you are looking for?=A0
=A0
Perhaps the intention is that Websockets are never used for peer to peer co= nnections, or that we fake a client in that situation. But it seems a lot o= f complication, and what is the gain? That servers have their load reduced?= They still have to unmask all those incoming messages, and as I showed in = the web portal usecase, the server may be a Websocket client for far more c= onnections than it is a server. Yes, you get sendfile() from server to clie= nt as a result. But if, instead, the server had a way of optionally turning= off masking in a frame when needed (there I go again) then you could get t= hat in cases where it mattered.

Again, I'm not looking to hold anything up here. I think that the langu= age of the straw poll should be adopted and put into the draft (so if it ma= tters, here is a +1). There is far too much resistance here to letting thin= gs into the spec IMHO. It should be much easier to get changes in, even if = they are later reversed. But at the same time, I hope that this poll does n= ot rule out further discussion on what "mandatory" and "clie= nt->server" means.

AFAIK, there has been no discussion = of allowing a server to initiate a connection to the client. =A0In many cas= es, it isn't even possible to do so, and it isn't clear security ad= ministrators would want every browser on their network essentially becoming= a server. =A0If you control both ends, then why do you need WebSocket at a= ll, rather than just using TCP directly?

Long time reader, first = time posting...hi everyone :)

I can see plenty of = valid use cases for peer-to-peer WebSockets. One in particular that's c= ome up for me recently is video streaming (for, say, live video conferencin= g) directly in a browser. It'd be great to be able to use peer-to-peer = communication under this scenario - reduce lag, overhead, etc.
=A0

In any case, it seems allowing such usage is beyond the= current scope.

Whether o= r not it's in scope is a different question, but there are clearly use-= cases for it.
=A0

--
John A. Tamplin
Software Engineer (GWT), Google
________________________________________= _______
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi



=
--
Jerod Venema
Frozen Mountain Software
http://www.frozenmountain.com/=
(w) 919-300-5141
(c) 919-368-5105

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--001485f6ca5c48eccc04991dead6-- From ferg@caucho.com Wed Jan 5 11:01:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC9C3A6C69 for ; Wed, 5 Jan 2011 11:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ2+ST1NOh5x for ; Wed, 5 Jan 2011 11:01:46 -0800 (PST) Received: from nm20.bullet.mail.ac4.yahoo.com (nm20.bullet.mail.ac4.yahoo.com [98.139.52.217]) by core3.amsl.com (Postfix) with SMTP id C3D2E3A6C39 for ; Wed, 5 Jan 2011 11:01:46 -0800 (PST) Received: from [98.139.52.196] by nm20.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 19:03:51 -0000 Received: from [98.139.52.161] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 19:03:51 -0000 Received: from [127.0.0.1] by omp1044.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 19:03:51 -0000 X-Yahoo-Newman-Id: 221148.46201.bm@omp1044.mail.ac4.yahoo.com Received: (qmail 80342 invoked from network); 5 Jan 2011 19:03:51 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 05 Jan 2011 11:03:50 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: OqSCSk0VM1l6OSeNdlnlwzc1ijzDkN4L0eirnpUNjk4b1um C5dTz8NaUwAe4tgrTnWoZQAbdbjMIhE86qQWHh..EiVFyM92K_q9NaamO_bv KcsRTB_0k0hGbOJqS5jfIjBs..56wgFfZqnPNWd7EuQ29Iwxv2IV9t8fHX4m mdHyC0A8Xksnjmf7nHPzxnvWJ0BfTHqXkzjV.AEEae0jd2TKzxRUYnpeT.UY S.fN9nBjGZ3NkGjcGanCmodlaWnhryIoJtJ0ro2Y1Ee4gBcL6BmuUhpcKFOl pvoCxD9Ehra4EP47J1GANG8QdFg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D24C095.5070205@caucho.com> Date: Wed, 05 Jan 2011 11:03:49 -0800 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: John Tamplin References: <1293038752.2369.155.camel@ds9.ducksong.com> <4D24B8F0.9090404@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:01:47 -0000 John Tamplin wrote: > On Wed, Jan 5, 2011 at 1:31 PM, Bruce Atherton > wrote: > If you control both ends, then why do you need WebSocket at all, > rather than just using TCP directly? Because many messaging protocols need a framing layer and a standard basic framing protocol is a useful thing. Instead of every application rolling its own framing protocol (and API and network layer), people writing their messaging protocol can concentrate on the messages and leave the network stuff and framing to a common library. It's basic layered software design. (Server to browser is a whole different issue that is well beyond the scope of WebSockets, besides being a security nightmare.) -- Scott > > In any case, it seems allowing such usage is beyond the current scope. > > -- > John A. Tamplin > Software Engineer (GWT), Google > ------------------------------------------------------------------------ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From ietf@adambarth.com Wed Jan 5 11:24:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B633A6C74 for ; Wed, 5 Jan 2011 11:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.014 X-Spam-Level: X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=-1.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQPrV+pxQAmZ for ; Wed, 5 Jan 2011 11:24:52 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id F0FDC3A6C17 for ; Wed, 5 Jan 2011 11:24:51 -0800 (PST) Received: by qwi2 with SMTP id 2so152480qwi.31 for ; Wed, 05 Jan 2011 11:26:58 -0800 (PST) Received: by 10.224.10.210 with SMTP id q18mr22091259qaq.122.1294255618698; Wed, 05 Jan 2011 11:26:58 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id t7sm12623975qcs.16.2011.01.05.11.26.56 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 11:26:56 -0800 (PST) Received: by iwn40 with SMTP id 40so16602397iwn.31 for ; Wed, 05 Jan 2011 11:26:55 -0800 (PST) Received: by 10.231.19.138 with SMTP id a10mr7221074ibb.127.1294255615474; Wed, 05 Jan 2011 11:26:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Wed, 5 Jan 2011 11:26:24 -0800 (PST) In-Reply-To: <4D245963.5030104@warmcat.com> References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> From: Adam Barth Date: Wed, 5 Jan 2011 11:26:24 -0800 Message-ID: To: andy@warmcat.com Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:24:53 -0000 On Wed, Jan 5, 2011 at 3:43 AM, Andy Green wrote: > On 01/05/11 09:57, Somebody in the thread at some point said: >> My question is : why should we bother for those ? We're making a mess with >> the WebSocket protocol just because we suspect that there might exist some >> stupid developers who probably quickly wrote something they called a proxy >> in just an afternoon for their own use. If such products exist they surely >> are not waiting for WebSocket to be exploited (eg: chunked encoding or >> multiple content-lengths are even harder to get right than >> content-length). >> >> So couldn't we focus on more-or-less HTTP-compliant implementations only, >> cover a few implementation bugs and stop bothering about the most unlikely >> scenarii involving deliberate bugs ? At one point, we should not try to >> fix what people deliberately broke for their own use. > > Couldn't agree more. > > Security of these alleged intermediaries is out of scope for websockets > because they remain as exploitable as they ever were for packets on both > sides of them no matter what needless evasive action websockets takes. > > Over-engineering websockets to death over a non-reproducible problem that > websockets can't fix is crazy. > > What's needed is to rule trying to solve the unsolveable out of scope and > finish up any problems from the real world left with -03. The security goals of browser vendors are higher than that. As a general rule, browser vendors do not kick the security can down the road. The buck stops here. Adam From andy.warmcat.com@googlemail.com Wed Jan 5 11:46:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7843A6C78 for ; Wed, 5 Jan 2011 11:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3AntD9ojp8H for ; Wed, 5 Jan 2011 11:46:03 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C4A3E3A6C17 for ; Wed, 5 Jan 2011 11:46:02 -0800 (PST) Received: by wwa36 with SMTP id 36so15718629wwa.13 for ; Wed, 05 Jan 2011 11:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ezTU7Gas36vMgoi0vaivPAMIm3VI77gePy1fDxqI92g=; b=sWycR97kw4mlO711TgaEUn2WfVbl555l833HqSwWYzJzkfGC5zHk+Z8YZUjzoubBBm qNU+uTlerg//ARegL/FJzTbEg0b8faLc89I6rvYUd+I8tQAwvFo7fL0gBU0dHBKD6KL2 kZn5GNnA4k7axIq0ZQQBGeKkp0k2AUT+tmWDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Ns2nZFfhCAaPUhP9uYygzct4iFB4QUwwpZHtMcvQaEg0/vftxoTguMOK1sQpK0lPc5 zb5nRCq6nwUd171fSm7qbhJNZ/7nwx995saWhos9Cc7tvgCsKaGXvFwfGrlREtEhsafb d5SeSLyax8ikdbdJXQL9NsWn0ijwAnQLtl2b0= Received: by 10.227.183.203 with SMTP id ch11mr13504322wbb.214.1294256886811; Wed, 05 Jan 2011 11:48:06 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id m10sm16204901wbc.22.2011.01.05.11.47.59 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 11:48:00 -0800 (PST) Sender: Andy Green Message-ID: <4D24CAEE.6060002@warmcat.com> Date: Wed, 05 Jan 2011 19:47:58 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adam Barth References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:46:04 -0000 On 01/05/11 19:26, Somebody in the thread at some point said: >> Security of these alleged intermediaries is out of scope for websockets >> because they remain as exploitable as they ever were for packets on both >> sides of them no matter what needless evasive action websockets takes. >> >> Over-engineering websockets to death over a non-reproducible problem that >> websockets can't fix is crazy. >> >> What's needed is to rule trying to solve the unsolveable out of scope and >> finish up any problems from the real world left with -03. > > The security goals of browser vendors are higher than that. As a > general rule, browser vendors do not kick the security can down the > road. The buck stops here. The last couple of months appear to me to have been wasted with navelgazing trying to secure undefined broken intermediaries from attack by websockets, when websockets is not required to attack them. In the meanwhile websockets are gone from Firefox by default exactly because the browser vendors don't want to be on the wrong side of security professionals finding they should have done something better and blaming them. Actual security can be quite slippery and requires it to be well defined what it is that is trying to be secured from which attacks at what cost. In this case, there is so much FUD about what the supposed problem is and what is needed to 'solve' it (again the problem is with the intermediary and cannot be solved by websockets; there is no definitive restestable problem scenario even) that the list appears to be reduced to a 'security jelly' talked into agreeing with the most forceful and aggressive-sounding proposals like AES munging. In fact if the problem is real and misunderstood, and 'fixed' in the wrong place, that can be worse than useless. From what I read I didn't see any real outstanding problem that is websocket business that -03 and maybe the HELLO thing, and for sure wss:// don't already solve. If you think that's incorrect, it should surely be possible to explain concisely what the problem is -- I mean really concisely -- and how it can be reproduced with normal, maintained and non-broken software in real use that makes it a websocket problem. -Andy From bruce@callenish.com Wed Jan 5 11:47:17 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B536E3A6C17 for ; Wed, 5 Jan 2011 11:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYeJwSLHm4Oi for ; Wed, 5 Jan 2011 11:47:16 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id CB6743A6A7F for ; Wed, 5 Jan 2011 11:47:16 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PaZMI-0007uw-Qi for hybi@ietf.org; Wed, 05 Jan 2011 11:49:23 -0800 Message-ID: <4D24CB44.4070709@callenish.com> Date: Wed, 05 Jan 2011 11:49:24 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <1293038752.2369.155.camel@ds9.ducksong.com> <4D24B8F0.9090404@callenish.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080309020008090706060909" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:47:17 -0000 This is a multi-part message in MIME format. --------------080309020008090706060909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 05/01/2011 10:35 AM, John Tamplin wrote: > AFAIK, there has been no discussion of allowing a server to initiate a > connection to the client. Ok, forget about server to browser. Sorry I mentioned it, since it complicates the question about peer to peer. > > In any case, it seems allowing such usage is beyond the current scope. It is fine if people want to declare that Websockets is a client/server protocol only. Like Scott, I would prefer to be able to reuse a Websockets library in peer to peer applications and have it take care of a bunch of details so I don't have to reinvent the wheel. But if you guys want to declare that Websockets is client/server only, then fine. I'll just have to find another bidirectional protocol to use. But I think a decision should be made whether to allow for peer to peer in the design because it has an effect on how this asymmetrical communication should be done. --------------080309020008090706060909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/01/2011 10:35 AM, John Tamplin wrote:
AFAIK, there has been no discussion of allowing a server to initiate a connection to the client.

Ok, forget about server to browser. Sorry I mentioned it, since it complicates the question about peer to peer.


In any case, it seems allowing such usage is beyond the current scope.

It is fine if people want to declare that Websockets is a client/server protocol only. Like Scott, I would prefer to be able to reuse a Websockets library in peer to peer applications and have it take care of a bunch of details so I don't have to reinvent the wheel. But if you guys want to declare that Websockets is client/server only, then  fine. I'll just have to find another bidirectional protocol to use.

But I think a decision should be made whether to allow for peer to peer in the design because it has an effect on how this asymmetrical communication should be done.

--------------080309020008090706060909-- From jmason@rim.com Wed Jan 5 11:48:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7BE3A6A7F for ; Wed, 5 Jan 2011 11:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syq2HuDxT3p4 for ; Wed, 5 Jan 2011 11:48:01 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 82F013A6C78 for ; Wed, 5 Jan 2011 11:48:01 -0800 (PST) X-AuditID: 0a401fcb-b7b7eae0000009ee-e2-4d24cb6f11c1 Received: from XHT109CNC.rim.net ( [10.65.12.218]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 78.B2.02542.F6BC42D4; Wed, 5 Jan 2011 14:50:07 -0500 (EST) Received: from XCH117CNC.rim.net ([fe80::b8df:541f:9d85:9909]) by XHT109CNC.rim.net ([fe80::8412:4d9e:eb55:2c7b%11]) with mapi; Wed, 5 Jan 2011 14:50:07 -0500 From: Joe Mason To: "hybi@ietf.org" Date: Wed, 5 Jan 2011 14:50:33 -0500 Thread-Topic: Unbounded buffers in -76 handshake Thread-Index: AcutEdB90tdmNIPqRNiwzNPET5Awtg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: dFg= AMSD BdtU Dy8X E30p FUmh FW6j FnOW HbMv IUAG IYmJ IkSE InzF Iv04 JRNG Kbfp; 1; aAB5AGIAaQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {3364C269-0CF0-4A76-806C-8813B3326C70}; agBtAGEAcwBvAG4AQAByAGkAbQAuAGMAbwBtAA==; Wed, 05 Jan 2011 19:50:33 GMT; VQBuAGIAbwB1AG4AZABlAGQAIABiAHUAZgBmAGUAcgBzACAAaQBuACAALQA3ADYAIABoAGEAbgBkAHMAaABhAGsAZQA= x-cr-puzzleid: {3364C269-0CF0-4A76-806C-8813B3326C70} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAZEXFZ3E Subject: [hybi] Unbounded buffers in -76 handshake X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:48:02 -0000 I know the -76 handshake is obsolete, but I'm trying to close off a simple b= ug in the existing WebKit implementation. According to http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76#= section-4.1, step 28, the client must: Read bytes from the server until either the connection closes, or a 0x0A by= te is read. Let /field/ be these bytes, including the 0x0A byte. This means a server can easily run a client out of memory by sending an unbo= unded string of bytes with no 0x0A. The client is, by a strict reading, req= uired to buffer all bytes received. (Actually it's simple to code an equiva= lent algorithm that only starts buffering after receiving 0x20, and buffers= at most 3 bytes, but let's stick with the algorithm as stated.) The easy fix is to suggest a max buffer length. (The spec already says, "Us= er agents may apply a timeout to this step, failing the WebSocket connection= if the server does not send back data in a suitable time period." A maximu= m number of bytes to read is a logical extension.) What would be a good val= ue for the max length? Is this worth adding to the spec as a quick fix whil= e we're still discussing the updated handshake? Joe ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From jat@google.com Wed Jan 5 12:06:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B2D3A6CEC for ; Wed, 5 Jan 2011 12:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.944 X-Spam-Level: X-Spam-Status: No, score=-103.944 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZnNmdSP+lRO for ; Wed, 5 Jan 2011 12:06:09 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8F7BB3A6A94 for ; Wed, 5 Jan 2011 12:06:09 -0800 (PST) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p05K8GAF024198 for ; Wed, 5 Jan 2011 12:08:16 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294258096; bh=zM5EuAj982BdZi/8ktOyC5Zdnww=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=JKcPzUatqLI8gmJt160rqJ8afSjY8YHUxkL2I3jBQgYrL0ydeg4A23KZ4BIZBEgFC 8dTXvEsTbFlbgm5fu7hkA== Received: from ywf9 (ywf9.prod.google.com [10.192.6.9]) by kpbe13.cbf.corp.google.com with ESMTP id p05K7okE010501 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 5 Jan 2011 12:08:15 -0800 Received: by ywf9 with SMTP id 9so6794044ywf.11 for ; Wed, 05 Jan 2011 12:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=oJxyTmjr2TZpN+i5TKtDUpzu0HWW4zy0Zq5LKjwy/eQ=; b=RPvuO5S/lePtCpW/jliOV3sy87Grbo6TY1BBXjM1wP2QtHfOFRL9WeGhvTi1G18zOM sMvbLL4QvaKfioJTrVrw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=p0mveFHV8jzU28lAIT0rolX73h9lcO2RK8nRbnb2S1PN60w/iBeRyxAuDPF/y4zW25 Nzr1EdX0KR2cGOBdg/0g== Received: by 10.151.85.10 with SMTP id n10mr22022234ybl.206.1294258094413; Wed, 05 Jan 2011 12:08:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Wed, 5 Jan 2011 12:07:54 -0800 (PST) In-Reply-To: <4D24CB44.4070709@callenish.com> References: <1293038752.2369.155.camel@ds9.ducksong.com> <4D24B8F0.9090404@callenish.com> <4D24CB44.4070709@callenish.com> From: John Tamplin Date: Wed, 5 Jan 2011 15:07:54 -0500 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=000e0cd56944f7168704991ef1af X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:06:10 -0000 --000e0cd56944f7168704991ef1af Content-Type: text/plain; charset=UTF-8 On Wed, Jan 5, 2011 at 2:49 PM, Bruce Atherton wrote: > It is fine if people want to declare that Websockets is a client/server > protocol only. Like Scott, I would prefer to be able to reuse a Websockets > library in peer to peer applications and have it take care of a bunch of > details so I don't have to reinvent the wheel. But if you guys want to > declare that Websockets is client/server only, then fine. I'll just have to > find another bidirectional protocol to use. > > But I think a decision should be made whether to allow for peer to peer in > the design because it has an effect on how this asymmetrical communication > should be done. > Since much of the contentious things about WebSockets comes about precisely because of its requirements of being used by browsers running untrusted code and reusing existing HTTP infrastructure, it seems unlikely you would want to use all of WebSockets for something that did not have those requirements. If you want to re-use the framing, that is fine, and you can simply say that you use the unmasked framing for both sides of your application. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd56944f7168704991ef1af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 5, 2011 at 2:49 PM, Bruce Atherton <= span dir=3D"ltr"><bruce@callenish= .com> wrote:
=20 =20 =20
It is fine if= people want to declare that Websockets is a client/server protocol only. Like Scott, I would prefer to be able to reuse a Websockets library in peer to peer applications and have it take care of a bunch of details so I don't have to reinvent the wheel. But if you guys want to declare that Websockets is client/server only, then=C2=A0 fine. I'll just have to find another bidirectional protocol to use.

But I think a decision should be made whether to allow for peer to peer in the design because it has an effect on how this asymmetrical communication should be done.

Since much of the contentious things about WebSockets comes about precise= ly because of its requirements of being used by browsers running untrusted = code and reusing existing HTTP infrastructure, it seems unlikely you would = want to use all of WebSockets for something that did not have those require= ments. =C2=A0If you want to re-use the framing, that is fine, and you can s= imply say that you use the unmasked framing for both sides of your applicat= ion.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd56944f7168704991ef1af-- From salvatore.loreto@ericsson.com Wed Jan 5 12:24:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1043A6CF0 for ; Wed, 5 Jan 2011 12:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9h9f6M1iEia for ; Wed, 5 Jan 2011 12:24:31 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id AF9643A6CEC for ; Wed, 5 Jan 2011 12:24:30 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-61-4d24d3fc724f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F0.6C.13987.CF3D42D4; Wed, 5 Jan 2011 21:26:36 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Wed, 5 Jan 2011 21:26:36 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3F8E92975 for ; Wed, 5 Jan 2011 22:26:36 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EDB6B500F8 for ; Wed, 5 Jan 2011 22:26:35 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8127C4FBC1 for ; Wed, 5 Jan 2011 22:26:35 +0200 (EET) Message-ID: <4D24D3FB.8040202@ericsson.com> Date: Wed, 5 Jan 2011 21:26:35 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> In-Reply-To: <4D245963.5030104@warmcat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:24:32 -0000 On 1/5/11 12:43 PM, Andy Green wrote: > On 01/05/11 09:57, Somebody in the thread at some point said: > > Hi - > >> My question is : why should we bother for those ? We're making a mess with >> the WebSocket protocol just because we suspect that there might exist some >> stupid developers who probably quickly wrote something they called a proxy >> in just an afternoon for their own use. If such products exist they surely >> are not waiting for WebSocket to be exploited (eg: chunked encoding or >> multiple content-lengths are even harder to get right than content-length). >> >> So couldn't we focus on more-or-less HTTP-compliant implementations only, >> cover a few implementation bugs and stop bothering about the most unlikely >> scenarii involving deliberate bugs ? At one point, we should not try to >> fix what people deliberately broke for their own use. > Couldn't agree more. > > Security of these alleged intermediaries is out of scope for websockets > because they remain as exploitable as they ever were for packets on both > sides of them no matter what needless evasive action websockets takes. > Over-engineering websockets to death over a non-reproducible problem > that websockets can't fix is crazy. here we are not talking of use WebSocket to fix the problems in the intermediaries, but to design the protocol in a way that can not be used to generate attacks against another resource. IETF encourages people "to consider security in their designs and to inform the reader of relevant security issues" ( http://www.ietf.org/rfc/rfc3552.txt ) /Sal -- Salvatore Loreto www.sloreto.com > What's needed is to rule trying to solve the unsolveable out of scope > and finish up any problems from the real world left with -03. > -Andy > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From andy.warmcat.com@googlemail.com Wed Jan 5 12:32:54 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3E53A6CF0 for ; Wed, 5 Jan 2011 12:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdK0zZ91MvSp for ; Wed, 5 Jan 2011 12:32:53 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DC0243A6C78 for ; Wed, 5 Jan 2011 12:32:52 -0800 (PST) Received: by wwa36 with SMTP id 36so15764014wwa.13 for ; Wed, 05 Jan 2011 12:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=F79oCaR7bXrBQCpdYWQDp3Jgi/5fIi+Pb18a7IUqM2Y=; b=P3nw0EYJGzjqBbWojEYBLVfRE9okBukv73VBIvBPwW6KwxtxjIQGIoapIP3kmU2hxi mhK8+v+shg/hma2LKMUYZyB0jA2DoKAbRV5rRT2KM+UeDV/kcWUPvN7EqXuvgKZR3b5m sOY+7pMHo3n3fwHuf4laoQRGC/suFjtSZh/Gs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=ZYXD/6Rby2tvYxAeGiefUoIYDmQn/P+2cn2FSH5hJnF82VM0eeDLVkbnctQ7Z4HNlM XPyzPm6KraFTLFXpdXoHGE37Vi28KqocOjq7FJVEYq7NYIrkPU4gBAl3VsZfQJW5F3Ac t9piyPvlkgtFnOf6GPUdyvWb69ZbH1G814K18= Received: by 10.227.98.94 with SMTP id p30mr5485191wbn.152.1294259685194; Wed, 05 Jan 2011 12:34:45 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id q18sm16232258wbe.5.2011.01.05.12.34.42 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 12:34:43 -0800 (PST) Sender: Andy Green Message-ID: <4D24D5E1.7070309@warmcat.com> Date: Wed, 05 Jan 2011 20:34:41 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Salvatore Loreto References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> In-Reply-To: <4D24D3FB.8040202@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:32:54 -0000 On 01/05/11 20:26, Somebody in the thread at some point said: > here we are not talking of use WebSocket to fix the problems in the > intermediaries, > but to design the protocol in a way that can not be used to generate > attacks against another resource. What exactly is the attack scenario that -03 is enabling? What is being attacked, how can I reproduce it? When I understood the mechanism, how can I satisfy myself that websockets was the right place to solve it when netcat and many other tools makes nice packets? Because it seems to me we have been sat here doing the equivalent of fixing the PHP bug for them by disallowing the literal 2.2250738585072011e-308 in websocket traffic, while inviting passers-by to "feel our security muscle". -Andy From jat@google.com Wed Jan 5 12:58:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3853A6C78 for ; Wed, 5 Jan 2011 12:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.626 X-Spam-Level: X-Spam-Status: No, score=-103.626 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBtaEgxQc+HO for ; Wed, 5 Jan 2011 12:58:35 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6852E3A6C15 for ; Wed, 5 Jan 2011 12:58:35 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p05L0fro020678 for ; Wed, 5 Jan 2011 13:00:41 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294261241; bh=Fq8cqV4UbGM7cYoBIgciWgDnqNY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Z6f1gGc8lnNDnvP46k0OzVo0ZGUdnA13ynGmGnTEQhNUsrl4aYFp1jFC76bfwASbp t9Xrpi9JBRKudoutP+JdQ== Received: from gxk28 (gxk28.prod.google.com [10.202.11.28]) by wpaz17.hot.corp.google.com with ESMTP id p05KxfRu023773 for ; Wed, 5 Jan 2011 13:00:40 -0800 Received: by gxk28 with SMTP id 28so7329583gxk.31 for ; Wed, 05 Jan 2011 13:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=ofBaSLkMFngOAHzBEQsGbm1Zoil2rrxqvy9qYf5LDxA=; b=IUkccDNT3kW7cICxi+wGESI2hjCslUA+yWI+rkM+ddludtEIguT91b97xlW7e50Rgx Nhvld0drD8ikaA5XodyQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=geW88fumdOxt9XZrAIU3K1oHUHdW6M/94FVvh8xFuh3hcwnD9W0xsZPzM7KeRLbjlL HRZWP0MRgiSFMwsIBB1g== Received: by 10.151.158.12 with SMTP id k12mr22238736ybo.377.1294261240312; Wed, 05 Jan 2011 13:00:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Wed, 5 Jan 2011 13:00:20 -0800 (PST) In-Reply-To: <4D24D5E1.7070309@warmcat.com> References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> From: John Tamplin Date: Wed, 5 Jan 2011 16:00:20 -0500 Message-ID: To: andy@warmcat.com Content-Type: multipart/alternative; boundary=00151750dd4279b35f04991fad00 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 20:58:36 -0000 --00151750dd4279b35f04991fad00 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 5, 2011 at 3:34 PM, Andy Green wrote: > On 01/05/11 20:26, Somebody in the thread at some point said: > > here we are not talking of use WebSocket to fix the problems in the >> intermediaries, >> but to design the protocol in a way that can not be used to generate >> attacks against another resource. >> > > What exactly is the attack scenario that -03 is enabling? What is being attacked, how can I reproduce it? When I understood the > mechanism, how can I satisfy myself that websockets was the right place to > solve it when netcat and many other tools makes nice packets? Because it seems to me we have been sat here doing the equivalent of fixing > the PHP bug for them by disallowing the literal 2.2250738585072011e-308 in > websocket traffic, while inviting passers-by to "feel our security muscle". I'll try and summarize -- if in doubt, read the full paper Adam posted a link to. An attacker controls a server and JS code running in the client. The JS code establishes a WebSocket connection to that server that happens to pass through a transparent HTTP proxy. After establishing the connection, the attacker sends WebSocket payload in each direction taking advantage of proxies which do not understand WebSockets (or even GET+Upgrade) and think the HTTP request is done when the server responds to the handshake, thus interpreting further contents on the connection as HTTP requests/responses. The attacker can then make use of tricks to get the proxy to store attacker-controlled data into its cache, which essentially creates an XSS attack against every user behind that proxy (for example, consider getting your contents returned for google.com/ga.js from the proxy). The paper does not demonstrate an attack against the -03 protocol, but it does raise enough questions about the possibility of such an attack that Firefox and Opera deemed it prudent to disable WebSockets until this is fixed. It is difficult to give you exact reproduction mechanisms, since by their nature transparent proxies are not directly visible and can not be communicated with directly. Since there are clearly some proxies which do not understand GET+Upgrade to be changing the type of the connection, the options are to not use it (CONNECT was suggested but there was substantial objection), create roadblocks in the handshake or framing and hope they are sufficient, or to prevent the attacker from controlling any payload bytes from the client (no masking is needed on the server since the attacker is already assumed to control it and can thus send anything it wants in response, including non-WebSocket messages). Option #1 seems unlikely to gain consensus, #2 seems hard to reason about how safe it is (since for example, such proxies might well skip garbage between HTTP messages), while #3 seems provably secure at relatively low cost. Hence, that is why we appear to be close to achieving consensus on masking the client->server frames. -- John A. Tamplin Software Engineer (GWT), Google --00151750dd4279b35f04991fad00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 5, 2011 at 3:34 PM, Andy Green <andy@warmcat.com&g= t; wrote:
On 01/05/11 20:26, Somebody in the thread at some point s= aid:

here we are not talking of use WebSocket to fix the problems in the
intermediaries,
but to design the protocol in a way that can not be used to generate
attacks against another resource.

What exactly is the attack scenario that -03 is enabling?=C2=A0=C2=A0
=C2=A0
What is being attacked, how can I reproduce it? =C2=A0When I understood the= mechanism, how can I satisfy myself that websockets was the right place to= solve it when netcat and many other tools makes nice packets?=C2=A0
=C2=A0
Because it seems to me we have been sat here doing the equivalent of fixing= the PHP bug for them by disallowing the literal 2.2250738585072011e-308 in= websocket traffic, while inviting passers-by to "feel our security mu= scle".
=C2=A0
I'll try and summarize -- i= f in doubt, read the full paper Adam posted a link to.=C2=A0

=
An attacker controls a server and JS code running in the client.= =C2=A0The JS code establishes a WebSocket connection to that server that h= appens to pass through a transparent HTTP proxy. =C2=A0After establishing t= he connection, the attacker sends WebSocket payload in each direction takin= g advantage of proxies which do not understand WebSockets (or even GET+Upgr= ade) and think the HTTP request is done when the server responds to the han= dshake, thus interpreting further contents on the connection as HTTP reques= ts/responses. =C2=A0The attacker can then make use of tricks to get the pro= xy to store attacker-controlled data into its cache, which essentially crea= tes an XSS attack against every user behind that proxy (for example, consid= er getting your contents returned for g= oogle.com/ga.js from the proxy).

The paper does not demonstrate an attack against the -0= 3 protocol, but it does raise enough questions about the possibility of suc= h an attack that Firefox and Opera deemed it prudent to disable WebSockets = until this is fixed. =C2=A0It is difficult to give you exact reproduction m= echanisms, since by their nature transparent proxies are not directly visib= le and can not be communicated with directly. =C2=A0Since there are clearly= some proxies which do not understand GET+Upgrade to be changing the type o= f the connection, the options are to not use it (CONNECT was suggested but = there was substantial objection), create roadblocks in the handshake or fra= ming and hope they are sufficient, or to prevent the attacker from controll= ing any payload bytes from the client (no masking is needed on the server s= ince the attacker is already assumed to control it and can thus send anythi= ng it wants in response, including non-WebSocket messages). =C2=A0Option #1= seems unlikely to gain consensus, #2 seems hard to reason about how safe i= t is (since for example, such proxies might well skip garbage between HTTP = messages), while #3 seems provably secure at relatively low cost. =C2=A0Hen= ce, that is why we appear to be close to achieving consensus on masking the= client->server frames.

--
John A. Tamplin
Software Engineer (GWT), Google
--00151750dd4279b35f04991fad00-- From andy.warmcat.com@googlemail.com Wed Jan 5 13:10:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2833A6D0E for ; Wed, 5 Jan 2011 13:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAPGzRDvMeDU for ; Wed, 5 Jan 2011 13:10:31 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id CCF5A3A6D0D for ; Wed, 5 Jan 2011 13:10:30 -0800 (PST) Received: by wyf23 with SMTP id 23so16452826wyf.31 for ; Wed, 05 Jan 2011 13:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4fVDupK6IOuYUKrmGQYxaW/lC0OIb1Pmgz45nmCopcg=; b=sys0byRr26hT6eo0QXVp/4azhmbvUBd71KZZy+m39ErJrntaIFNWBpt1gGhvqBWGWJ WSPNh4qPzJh96nPeV21jUoxXxicTftqc2A5nbh44UlL7ZaIhxELo5mS+NuGvEEV7YSRc zEAv8rU9U497FX5LJyUC7fKPCAYw+zEtuAkR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=CZqMIoG8djkyW8T+QvvrIOV5EQ8BhKMrDnBoXSJ+lNrMze7cTFZrhN/0aVutXWfNAs A5ADy7uhRctWF/GpwBYNdX2aSW4SMHMFGY/Z24s/MZq+sb7qnOiCGHQAc8qwkIXyh5k+ VkdWavcugje5baNXDUB3MTfv7TyuDur6A2l2c= Received: by 10.227.177.15 with SMTP id bg15mr1971670wbb.150.1294261938226; Wed, 05 Jan 2011 13:12:18 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id 11sm16257440wbj.13.2011.01.05.13.12.15 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 13:12:16 -0800 (PST) Sender: Andy Green Message-ID: <4D24DEAE.8070007@warmcat.com> Date: Wed, 05 Jan 2011 21:12:14 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Tamplin References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:10:32 -0000 On 01/05/11 21:00, Somebody in the thread at some point said: >> What exactly is the attack scenario that -03 is enabling? > connection, the attacker sends WebSocket payload in each direction > taking advantage of proxies which do not understand WebSockets (or even > GET+Upgrade) and think the HTTP request is done when the server responds Understood. But just like the PHP bug, what is the point of 'solving' this in websocket protocol? The proxy is still sat there allegedly open to poisoning from similar-looking non-websocket packets, just like the PHP server is still sitting there waiting for something else to send it the constant of death. Nothing is made "more secure" by having websockets in particular escape the equivalent of the PHP floating point constant. In short, why is it a websocket problem when the attacker who controls the server can have it send other kinds of scripts that can open sockets and do the same attack? The only solution is to close the hole in the proxy and fix the thing that is broken because it will otherwise remain broken and open to abuse no matter what websockets did. > provably secure at relatively low cost. Hence, that is why we appear to > be close to achieving consensus on masking the client->server frames. No, nothing got made "provably secure". The proxy is allegedly still sat there waiting to be poisoned because it is supposedly still as broken as it ever was awaiting exploitation. You can say, "that's not our problem" and you'd be right, none of it is a websocket issue including the proposed pointless munging action. It's an alleged 'broken exploitable proxy' issue. -Andy From jat@google.com Wed Jan 5 13:32:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BFD3A6E12 for ; Wed, 5 Jan 2011 13:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.532 X-Spam-Level: X-Spam-Status: No, score=-104.532 tagged_above=-999 required=5 tests=[AWL=-2.556, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtkbUBncBWx7 for ; Wed, 5 Jan 2011 13:32:00 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 5CB733A6DDB for ; Wed, 5 Jan 2011 13:31:59 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p05LY5nS029693 for ; Wed, 5 Jan 2011 13:34:05 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294263245; bh=ldAnDm5bjjVNZ80eEdvK8UQ02EE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=t8R4xYYDZ+ztqpsyL4crmVUpgEiC2N22qmStnyPFGWA1SkepNsK8ErcjuTrA9Wow5 kWlNhMRWrvpJSsPXyrjng== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by wpaz13.hot.corp.google.com with ESMTP id p05LXfnK023446 for ; Wed, 5 Jan 2011 13:34:04 -0800 Received: by gwj20 with SMTP id 20so6674568gwj.36 for ; Wed, 05 Jan 2011 13:34:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=XCZ3UnfOojjnKr03PB4zsEn9ekE9irCNUTx8dkUFtuM=; b=Q1WAv/CFgSDwxSVvX1rFU26hEXRasaefS9Q5ScaVOXRlN0G/u2yEa3zMuReYzhq9FA n5AncOfqDN2eC27wsHeg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=vVN/RLUT9iQ5lqjo9LteVRU1ORpM20C7Em25H7P+hAOFqQHL1/LLAmRu9fcYiuB/wo RlrSB8h01Qk+XcXvZLdA== Received: by 10.150.192.12 with SMTP id p12mr22946374ybf.263.1294263243499; Wed, 05 Jan 2011 13:34:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Wed, 5 Jan 2011 13:33:42 -0800 (PST) In-Reply-To: <4D24DEAE.8070007@warmcat.com> References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> From: John Tamplin Date: Wed, 5 Jan 2011 16:33:42 -0500 Message-ID: To: andy@warmcat.com Content-Type: multipart/alternative; boundary=000e0cd6b11cdfe96d0499202439 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:32:01 -0000 --000e0cd6b11cdfe96d0499202439 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 5, 2011 at 4:12 PM, Andy Green wrote: > Understood. But just like the PHP bug, what is the point of 'solving' this > in websocket protocol? The proxy is still sat there allegedly open to > poisoning from similar-looking non-websocket packets, just like the PHP > server is still sitting there waiting for something else to send it the > constant of death. Nothing is made "more secure" by having websockets in > particular escape the equivalent of the PHP floating point constant. > The browser does not currently allow arbitrary traffic in a non-HTTP framing, which WebSockets does. Sure, if you can convince a client to download your code that does that and run it locally (which is essentially how Flash/Java were also exploitable for this exact problem and why there was a delay in releasing the details), then you can perform this (and many other) attacks. However, you don't do that by just browsing to a web site. > In short, why is it a websocket problem when the attacker who controls the > server can have it send other kinds of scripts that can open sockets and do > the same attack? The only solution is to close the hole in the proxy and > fix the thing that is broken because it will otherwise remain broken and > open to abuse no matter what websockets did. If WebSockets were using HTTP framing throughout (such as chunked encoding in both directions), then yes that would be the case -- but it isn't, which means that WebSockets as of -03 opens new attack vectors that are not there by other current means. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd6b11cdfe96d0499202439 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 5, 2011 at 4:12 PM, Andy Green <andy@warmcat.com&g= t; wrote:
Understood. =C2=A0But just like the PHP bug, what is the = point of 'solving' this in websocket protocol? =C2=A0The proxy is s= till sat there allegedly open to poisoning from similar-looking non-websock= et packets, just like the PHP server is still sitting there waiting for som= ething else to send it the constant of death. =C2=A0Nothing is made "m= ore secure" by having websockets in particular escape the equivalent o= f the PHP floating point constant.

The browser does not currently allow arbit= rary traffic in a non-HTTP framing, which WebSockets does. =C2=A0Sure, if y= ou can convince a client to download your code that does that and run it lo= cally (which is essentially how Flash/Java were also exploitable for this e= xact problem and why there was a delay in releasing the details), then you = can perform this (and many other) attacks. =C2=A0However, you don't do = that by just browsing to a web site.
=C2=A0
In short, why is it a websocket problem when the attacker who controls the = server can have it send other kinds of scripts that can open sockets and do= the same attack? =C2=A0The only solution is to close the hole in the proxy= and fix the thing that is broken because it will otherwise remain broken a= nd open to abuse no matter what websockets did.

If WebSockets were using HTTP framing throughout (such = as chunked encoding in both directions), then yes that would be the case --= but it isn't, which means that WebSockets as of -03 opens new attack v= ectors that are not there by other current means.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd6b11cdfe96d0499202439-- From jat@google.com Wed Jan 5 13:33:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792713A6DDB for ; Wed, 5 Jan 2011 13:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.488 X-Spam-Level: X-Spam-Status: No, score=-104.488 tagged_above=-999 required=5 tests=[AWL=-2.512, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7laVzqaQQdV for ; Wed, 5 Jan 2011 13:33:29 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 651853A6D28 for ; Wed, 5 Jan 2011 13:33:29 -0800 (PST) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p05LZZ1A017833 for ; Wed, 5 Jan 2011 13:35:35 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294263335; bh=jiD6KXuJwNALQ/4srC63bmvKEH4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=eKmRHAmvhdp4AyhfyCj87y0GRJtNBfEluUHXzeNZ6MHjpfXhRskUXNFTyvZai8ozT d62+/vPp6ZevOAbDAmJZA== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by hpaq13.eem.corp.google.com with ESMTP id p05LZY4k005798 for ; Wed, 5 Jan 2011 13:35:34 -0800 Received: by gwb11 with SMTP id 11so7365644gwb.11 for ; Wed, 05 Jan 2011 13:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=FPh4QJJb3prIcejxZf3xh57yeGcBFKa+w41aOd+k/M0=; b=uffFJs2CnZBVoVJ36aQspW1C4T+PYOWeWYUfcd7F+BfrHnEXo6IYJlyMF8J4vDETr8 8MEZEe7txpQ/FmSquGDw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=jqNYXCQIDbdTs8btO4/7kILWKIwd4uUutc/S3a3fK+4uyTtPd3qXr0Ms/F/oXBqGoI YpHJpjGLj1tG3hqlTYZA== Received: by 10.151.85.10 with SMTP id n10mr22137949ybl.206.1294263333910; Wed, 05 Jan 2011 13:35:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Wed, 5 Jan 2011 13:35:13 -0800 (PST) In-Reply-To: <4D24DEAE.8070007@warmcat.com> References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> From: John Tamplin Date: Wed, 5 Jan 2011 16:35:13 -0500 Message-ID: To: andy@warmcat.com Content-Type: multipart/alternative; boundary=000e0cd5694443779e0499202a43 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 21:33:30 -0000 --000e0cd5694443779e0499202a43 Content-Type: text/plain; charset=UTF-8 [sent too soon] On Wed, Jan 5, 2011 at 4:12 PM, Andy Green wrote: > No, nothing got made "provably secure". The proxy is allegedly still sat > there waiting to be poisoned because it is supposedly still as broken as it > ever was awaiting exploitation. You can say, "that's not our problem" and > you'd be right, none of it is a websocket issue including the proposed > pointless munging action. It's an alleged 'broken exploitable proxy' issue. > If the attacker cannot control the bytes of the WebSocket payload, the attacker cannot exploit it by including fake HTTP messages. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd5694443779e0499202a43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[sent too soon]
=
On Wed, Jan 5, 2011 at 4:12 PM, Andy G= reen <andy@warmcat= .com> wrote:
No, nothing got made &quo= t;provably secure". =C2=A0The proxy is allegedly still sat there waiti= ng to be poisoned because it is supposedly still as broken as it ever was a= waiting exploitation. =C2=A0You can say, "that's not our problem&q= uot; and you'd be right, none of it is a websocket issue including the = proposed pointless munging action. =C2=A0It's an alleged 'broken ex= ploitable proxy' issue.

If the attacker cannot control the bytes of the WebS= ocket payload, the attacker cannot exploit it by including fake HTTP messag= es.

--
John A. Tamplin
Software Engineer (GWT),= Google
--000e0cd5694443779e0499202a43-- From bruce@callenish.com Wed Jan 5 16:24:23 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98663A6DC6 for ; Wed, 5 Jan 2011 16:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kETpZMwdovv4 for ; Wed, 5 Jan 2011 16:24:22 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id C52663A6D79 for ; Wed, 5 Jan 2011 16:24:22 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PadgS-0007Xk-Jg for hybi@ietf.org; Wed, 05 Jan 2011 16:26:28 -0800 Message-ID: <4D250C37.4040505@callenish.com> Date: Wed, 05 Jan 2011 16:26:31 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <1293038752.2369.155.camel@ds9.ducksong.com> <4D24B8F0.9090404@callenish.com> <4D24CB44.4070709@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 00:24:23 -0000 On 05/01/2011 12:07 PM, John Tamplin wrote: > > Since much of the contentious things about WebSockets comes about > precisely because of its requirements of being used by browsers > running untrusted code and reusing existing HTTP infrastructure, it > seems unlikely you would want to use all of WebSockets for something > that did not have those requirements. If you want to re-use the > framing, that is fine, and you can simply say that you use the > unmasked framing for both sides of your application. Unfortunately, as I said before, that is fine if you control your infrastructure. But not all of us are deploying in environments that are set up by design to allow the free exchange of protobufs. A bastardized version of Websockets will not pass through any intermediaries that unmask and remask, and will fill the error logs of any that peek into the frames to do things like analytics or logging or filtering. It sounds like there is a laser focus of scope for the hybi working group on just the interactions between browser and server, and that any other usecase need not apply. If that is the case, I will stop bringing up considerations of other situations such as standalone clients, the server being the client to another server, or two peers communicating with Websockets, since they all appear to be out of scope for the WG. From ietf@adambarth.com Wed Jan 5 20:11:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C319D3A6EBC for ; Wed, 5 Jan 2011 20:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=-1.522, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZDOIyaVIrZZ for ; Wed, 5 Jan 2011 20:11:04 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id CC07A3A6EBA for ; Wed, 5 Jan 2011 20:11:03 -0800 (PST) Received: by yie19 with SMTP id 19so4802281yie.31 for ; Wed, 05 Jan 2011 20:13:10 -0800 (PST) Received: by 10.150.50.6 with SMTP id x6mr22372926ybx.381.1294287190224; Wed, 05 Jan 2011 20:13:10 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id p32sm11934693ybk.8.2011.01.05.20.13.08 (version=SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 20:13:09 -0800 (PST) Received: by iyi42 with SMTP id 42so15833938iyi.31 for ; Wed, 05 Jan 2011 20:13:07 -0800 (PST) Received: by 10.231.85.137 with SMTP id o9mr7839774ibl.27.1294287187923; Wed, 05 Jan 2011 20:13:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Wed, 5 Jan 2011 20:12:37 -0800 (PST) In-Reply-To: <4D24CAEE.6060002@warmcat.com> References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24CAEE.6060002@warmcat.com> From: Adam Barth Date: Wed, 5 Jan 2011 20:12:37 -0800 Message-ID: To: andy@warmcat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 04:11:05 -0000 On Wed, Jan 5, 2011 at 11:47 AM, Andy Green wrote: > On 01/05/11 19:26, Somebody in the thread at some point said: >>> Security of these alleged intermediaries is out of scope for websockets >>> because they remain as exploitable as they ever were for packets on bot= h >>> sides of them no matter what needless evasive action websockets takes. >>> >>> Over-engineering websockets to death over a non-reproducible problem th= at >>> websockets can't fix is crazy. >>> >>> What's needed is to rule trying to solve the unsolveable out of scope a= nd >>> finish up any problems from the real world left with -03. >> >> The security goals of browser vendors are higher than that. =A0As a >> general rule, browser vendors do not kick the security can down the >> road. =A0The buck stops here. > > The last couple of months appear to me to have been wasted with navelgazi= ng > trying to secure undefined broken intermediaries from attack by websocket= s, > when websockets is not required to attack them. =A0In the meanwhile webso= ckets > are gone from Firefox by default exactly because the browser vendors don'= t > want to be on the wrong side of security professionals finding they shoul= d > have done something better and blaming them. > > Actual security can be quite slippery and requires it to be well defined > what it is that is trying to be secured from which attacks at what cost. = =A0In > this case, there is so much FUD about what the supposed problem is and wh= at > is needed to 'solve' it (again the problem is with the intermediary and > cannot be solved by websockets; there is no definitive restestable proble= m > scenario even) that the list appears to be reduced to a 'security jelly' > talked into agreeing with the most forceful and aggressive-sounding > proposals like AES munging. We know several approaches for fixing the problem. The working group has been discussing the trade-offs involved. IMHO, the straw poll is showing that there's generally broad support for Pat's proposal. Adam > In fact if the problem is real and misunderstood, and 'fixed' in the wron= g > place, that can be worse than useless. > > From what I read I didn't see any real outstanding problem that is websoc= ket > business that -03 and maybe the HELLO thing, and for sure wss:// don't > already solve. > > If you think that's incorrect, it should surely be possible to explain > concisely what the problem is -- I mean really concisely -- and how it ca= n > be reproduced with normal, maintained and non-broken software in real use > that makes it a websocket problem. > > -Andy > From gregw@intalio.com Thu Jan 6 01:41:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28FB73A6ED4 for ; Thu, 6 Jan 2011 01:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i69jKkICeMig for ; Thu, 6 Jan 2011 01:41:34 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 95DE33A6C50 for ; Thu, 6 Jan 2011 01:41:33 -0800 (PST) Received: by qyk34 with SMTP id 34so18379745qyk.10 for ; Thu, 06 Jan 2011 01:43:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.87.13 with SMTP id u13mr20450537qcl.55.1294307019860; Thu, 06 Jan 2011 01:43:39 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Thu, 6 Jan 2011 01:43:39 -0800 (PST) In-Reply-To: <4D250C37.4040505@callenish.com> References: <1293038752.2369.155.camel@ds9.ducksong.com> <4D24B8F0.9090404@callenish.com> <4D24CB44.4070709@callenish.com> <4D250C37.4040505@callenish.com> Date: Thu, 6 Jan 2011 10:43:39 +0100 X-Google-Sender-Auth: XV9F41Kpu8MpK4byb_i7EWYXWHE Message-ID: From: Greg Wilkins To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 09:41:38 -0000 On 6 January 2011 01:26, Bruce Atherton wrote: > It sounds like there is a laser focus of scope for the hybi working group on > just the interactions between browser and server, and that any other usecase > need not apply. If that is the case, I will stop bringing up considerations > of other situations such as standalone clients, the server being the client > to another server, or two peers communicating with Websockets, since they > all appear to be out of scope for the WG. Bruce, a difficulty of this working group is that we were never able to even agree on a requirement document as the various constituencies suspected each other of steering the requirements towards their own use-cases. Hence it is difficult to really say what is in scope or out of scope. But I for one certainly appreciate you raising cases that push the boundaries of this WG's scope, as good design results from consideration of edge cases. My own work with cometd certainly already has peer to peer usage, we have a sub-project called the Oort cloud that links up cometd servers into a cluster. Currently this uses our long polling transport, but once we implement WS support in our java client, then WS would be a much better choice. We also have many examples in the cometd project of standalone (non browser) clients being written - in phones and on desktop applications. Again most of these would benefit from a WS transport. Neither of these use-cases run potentially hostile 3rd party code (as browsers do), so are at much less risk from injection of HTTP-like content. While I dubious about the actual level of threat posed by vulnerable intermediaries, I fully support the browser vendors interest in avoiding the issue and believe that mandatory masking is a good solution for the browsers. I just don't understand why that means that masking must be made mandatory for all other use cases. If browsers don't want the ability to switch it off - then don't write your code so that it can be switched off. regards From andy.warmcat.com@googlemail.com Thu Jan 6 03:14:33 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC90A3A6D1F for ; Thu, 6 Jan 2011 03:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAw1EfeWYaNr for ; Thu, 6 Jan 2011 03:14:32 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 0D0223A6D17 for ; Thu, 6 Jan 2011 03:14:31 -0800 (PST) Received: by wyf23 with SMTP id 23so17019572wyf.31 for ; Thu, 06 Jan 2011 03:16:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=STmMEu7YhlaF+wL9P5OriC+WQiphPEGOvVk3+vOy3kE=; b=lpMk+jdbXwc/HyaPsHQwIVM7ua0fY6xct9bCVVbmPBUO43+zDKFSe51I0SIMAdlOyF LtXd3EqTMyBlwRDuPnBZzZoEk0Ur5cuSE3G0zgI1DVtkFIGsEXY2FJ+T/auDnKQXvVA6 0eXBXkqkAyg49dH+7ALQAu1ctA2Sifc8PNAj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=nlQqHJ+EoiMdQI/ZKJgSBXr1TCUHrmzyBGWqXrHZXEety9s9oHZj2RI8z00tiaYv18 c0Zz26c5fxyYztPEKegypvbVcc2rHAbMUJrP5LbusWyOJ79xF4MQtvPtQZWVSFKYOlzQ 5p96yefGZJEsRUHmXb8PJnlhJjasiLd8xbaQE= Received: by 10.227.129.71 with SMTP id n7mr14164892wbs.7.1294312598348; Thu, 06 Jan 2011 03:16:38 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id m13sm16706817wbz.21.2011.01.06.03.16.35 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 03:16:35 -0800 (PST) Sender: Andy Green Message-ID: <4D25A492.20701@warmcat.com> Date: Thu, 06 Jan 2011 11:16:34 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Tamplin References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 11:14:33 -0000 On 01/05/11 21:33, Somebody in the thread at some point said: > On Wed, Jan 5, 2011 at 4:12 PM, Andy Green > wrote: > > Understood. But just like the PHP bug, what is the point of > 'solving' this in websocket protocol? The proxy is still sat there > allegedly open to poisoning from similar-looking non-websocket > packets, just like the PHP server is still sitting there waiting for > something else to send it the constant of death. Nothing is made > "more secure" by having websockets in particular escape the > equivalent of the PHP floating point constant. > > > The browser does not currently allow arbitrary traffic in a non-HTTP > framing, which WebSockets does. Sure, if you can convince a client to It is not a raw socket though, it has handshaking to get it into that mode which is compatible with HTTP using upgrade. The handshaking takes care to confirm that it is talking to a partner that understands websocket framing and is willing to talk it using that. It is not at all like websockets is the new LOIC. There is a vanishingly narrow story for things that can be attacked, broken intermediaries that don't understand upgrade and stay in HTTP mode. And if they exist, they can be fixed. > download your code that does that and run it locally (which is > essentially how Flash/Java were also exploitable for this exact problem I take your point about the one-stop-shop if there are things that do bad things seeing websocket protocol. But nobody has shown one of these supposed buggy intermediaries or describe how to reproduce a failure involving one. AFAIK because the failure mode is just inferred, nobody has confirmed that whatever was done to Flash and Java in the name of "security" closed any actual holes. Maybe some intermediaries are buggy and never saw a websocket handshake until now... that state of affairs won't continue if websockets is a success. > If WebSockets were using HTTP framing throughout (such as chunked > encoding in both directions), then yes that would be the case -- but it > isn't, which means that WebSockets as of -03 opens new attack vectors > that are not there by other current means. It uses upgrade which should be enough if the intermediary is complaint. And if it's not compliant and does bad things when sent upgrade and other packets, that is not going to be solved by eliminating one source of upgrade and other packets. From the other mail -> >> No, nothing got made "provably secure". The proxy is allegedly >> still sat there waiting to be poisoned because it is supposedly still >> as broken as it ever was awaiting exploitation. You can say, "that's >> not our problem" and you'd be right, none of it is a websocket issue >> including the proposed pointless munging action. It's an alleged >> 'broken exploitable proxy' issue. > If the attacker cannot control the bytes of the WebSocket payload, > the attacker cannot exploit it by including fake HTTP messages. What do you think got made "provably secure" and against what? Websockets protocol itself is made no more secure against eavesdropping by addition of AES munging that has the keys on the wire. The handshake scheme seems secure enough already against accidentally talking to a partner that won't be able to talk websockets properly; payload munging won't add to that. What you mean is that you think it will be 'proven' that an undefined intermediary that doesn't understand websockets will act securely when we spam gigabytes of /dev/random-ish 8-bit data with what you previously called "non HTTP framing" (despite Upgrade) at it. Because we accept to shadow-box with supposedly broken-but-unknown and unfixable intermediaries that can have any response to anything and that is meant to be a websocket problem, in fact you can't prove anything about a system involving such an unknowable black box. As soon as you accept the unknown broken-ness of the supposed intermediary being a websocket problem you are just reliant on agreement with the people playing 'broken intermediary devil's advocate' when they feel like it or tire of the game. That's not proving anything. From what I can see, including the bad-tempered Opera thread, websockets is out by default now as much from exhaustion with tracking a spec that isn't converging as intermediary FUD: I don't know why else wss:// is pulled along with ws://. Actually -03 is a really nice spec already if we stop trying to solve the unsolveable as well. -Andy From andy.warmcat.com@googlemail.com Thu Jan 6 03:18:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2383A6D17 for ; Thu, 6 Jan 2011 03:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ1TwrKdiOmK for ; Thu, 6 Jan 2011 03:18:51 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 9AD4E3A6B72 for ; Thu, 6 Jan 2011 03:18:51 -0800 (PST) Received: by wwa36 with SMTP id 36so16322138wwa.13 for ; Thu, 06 Jan 2011 03:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=o7G+BjbNWji6MbONGayKkOCQcvd4CdAUoPD5y9mpv1s=; b=WlrckcbhSKb6F/n+ecXmfm4eLvAm0fPkJ3oXy4xywPzReZc+VW2apxfIX5cYXP2lkK 1BC4RyOwujjbvMhwqMpU1026rQqpFkeefyFEbuKvMESuBzXUF4YJ0LP+YAEwDY30z5lT riAKre+cr39AvcXfZT+66V4cxbqsaNkKHic8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=kaKWKiJcLM1686Ev5WFW/uLg4QHkg8/jAhpJ/GJ7/Wv+Y5yvFBBI8TXfP0T87n79cQ gKddjRXrnEcQa1OIYPuVB4T7CYBO5Hx1n1BeknoHoFYRP2OZOLZwiwQyJuJS9Dv9NbP/ j5p6gAo9wzj4Qh9W9sO4F4k9CynUtrejbjmOY= Received: by 10.227.159.68 with SMTP id i4mr7308488wbx.176.1294312857838; Thu, 06 Jan 2011 03:20:57 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id m13sm16709861wbz.21.2011.01.06.03.20.56 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 03:20:57 -0800 (PST) Sender: Andy Green Message-ID: <4D25A598.8060406@warmcat.com> Date: Thu, 06 Jan 2011 11:20:56 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adam Barth References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24CAEE.6060002@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 11:18:53 -0000 On 01/06/11 04:12, Somebody in the thread at some point said: >> Actual security can be quite slippery and requires it to be well defined >> what it is that is trying to be secured from which attacks at what cost. In >> this case, there is so much FUD about what the supposed problem is and what >> is needed to 'solve' it (again the problem is with the intermediary and >> cannot be solved by websockets; there is no definitive restestable problem >> scenario even) that the list appears to be reduced to a 'security jelly' >> talked into agreeing with the most forceful and aggressive-sounding >> proposals like AES munging. > > We know several approaches for fixing the problem. The working group > has been discussing the trade-offs involved. IMHO, the straw poll is > showing that there's generally broad support for Pat's proposal. What exactly do you mean, "fix the problem"? The "problem" is ultimately a supposedly broken intermediary, right? NOTHING is going to FIX the supposed vulnerability that creates except fixing the intermediary itself. Everything else, any amount of "working group discussion", is just leaving the thing wide open to attack from any other direction, but not websockets, no sir. -Andy From dave@cridland.net Thu Jan 6 04:53:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1963A6BB5 for ; Thu, 6 Jan 2011 04:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1kVMIF4z6-A for ; Thu, 6 Jan 2011 04:53:58 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 2F4273A6EFE for ; Thu, 6 Jan 2011 04:53:58 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 140D71168117; Thu, 6 Jan 2011 12:56:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F2skQxm97rb; Thu, 6 Jan 2011 12:55:55 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id BC17411680FB; Thu, 6 Jan 2011 12:55:55 +0000 (GMT) References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> In-Reply-To: <4D25A492.20701@warmcat.com> MIME-Version: 1.0 Message-Id: <10468.1294318555.770054@puncture> Date: Thu, 06 Jan 2011 12:55:55 +0000 From: Dave Cridland To: Andy Green , Server-Initiated HTTP , John Tamplin Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 12:53:59 -0000 On Thu Jan 6 11:16:34 2011, Andy Green wrote: > But nobody has shown one of these supposed buggy intermediaries or > describe how to reproduce a failure involving one. AFAIK because > the failure mode is just inferred, nobody has confirmed that > whatever was done to Flash and Java in the name of "security" > closed any actual holes. No, it was demonstrated that a strong potential exists, modulo the effects of framing (which are pretty unpredictable). It was also shown that all affected intermediaries ceased to be viable as an attack surface given a CONNECT. The entire discussion on masking is a red herring, given the experimental data suggests that 50,000 random beds were looked under, and no monsters were found. You statement above, in any case, simply implies that as long as WebSockets prevent the vast majority of attacks (easy - include something that looks like a CONNECT at some point in the flow), then any would-be attacker will move onto Java and Flash instead, and - if we want to make the obvious cynical observation - either drive websocket adoption or encourage intermediaries to be fixed. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From andy.warmcat.com@googlemail.com Thu Jan 6 05:12:25 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7BF3A6F00 for ; Thu, 6 Jan 2011 05:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRSvEITLMG9d for ; Thu, 6 Jan 2011 05:12:24 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id EC3993A6CAA for ; Thu, 6 Jan 2011 05:12:23 -0800 (PST) Received: by wyf23 with SMTP id 23so17116859wyf.31 for ; Thu, 06 Jan 2011 05:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=h0q5T8D6tqg/Fa4IT3exvlA+hcS1IbJ4M4+HCfs5Sco=; b=m55gMNo0NQP1BSlkgnQHhl6Uxr/EZNGYrel6GlqKT+tR+SM7ndD7xE996Hfw2oLFEo j6Fyie+PvRvM/dj8VJRvX/HjInShFFXEmYwmKPT1JkSy4Tmujmza0qdpR6J1HlGUEst5 fUBr960wFTAUzOdihvtJCMtWzK4mYyEI4gm4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=t+pd1VrDNhVSjMwgD3p/D+6jhOPjpoSvmTb/erk6lAgAu5PltIaFBaYe06thuAp4ik C5co1c+KSL3eB5djMQNTbPoAegu6o1GZGr1fKR6bkQHAphoMz9Dp9SAEOcAGCYQ0uUxG EwQq5tIgq4zzgVTh9o4JfHH63N0GMbLrkxKQk= Received: by 10.227.183.203 with SMTP id ch11mr14241563wbb.214.1294319670167; Thu, 06 Jan 2011 05:14:30 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id m13sm16786918wbz.15.2011.01.06.05.14.28 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 05:14:29 -0800 (PST) Sender: Andy Green Message-ID: <4D25C033.3010501@warmcat.com> Date: Thu, 06 Jan 2011 13:14:27 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Cridland References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> In-Reply-To: <10468.1294318555.770054@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 13:12:25 -0000 On 01/06/11 12:55, Somebody in the thread at some point said: > On Thu Jan 6 11:16:34 2011, Andy Green wrote: >> But nobody has shown one of these supposed buggy intermediaries or >> describe how to reproduce a failure involving one. AFAIK because the >> failure mode is just inferred, nobody has confirmed that whatever was >> done to Flash and Java in the name of "security" closed any actual holes. > > No, it was demonstrated that a strong potential exists, modulo the > effects of framing (which are pretty unpredictable). It was also shown > that all affected intermediaries ceased to be viable as an attack > surface given a CONNECT. If I understood it, the presence of vulnerable intermediaries was inferred by a client script doing something or not. Because it was done via advertising and not under repeatable conditions that are open to analysis, the reason the script may have appeared to stop doing something is open to interpretation since the whole stack between the client and attack sensor is unknown, uncontrolled and unrepeatable. That's why I asked yesterday --> "If you think that's incorrect, it should surely be possible to explain concisely what the problem is -- I mean really concisely -- and how it can be reproduced with normal, maintained and non-broken software in real use that makes it a websocket problem." > The entire discussion on masking is a red herring, given the > experimental data suggests that 50,000 random beds were looked under, > and no monsters were found. > > You statement above, in any case, simply implies that as long as > WebSockets prevent the vast majority of attacks (easy - include > something that looks like a CONNECT at some point in the flow), then any > would-be attacker will move onto Java and Flash instead, and - if we > want to make the obvious cynical observation - either drive websocket > adoption or encourage intermediaries to be fixed. To be clear websocket masking does nothing to fix the allegedly broken and vulnerable intermediary which remains listening on a socket and willing to do whatever it does if you feed it the right packets by any means. The only way to fix that is identify and fix the broken intermediary that is alleged to exist, not bend every client out of shape just in case. Completely agree that masking websockets is needless. Even if an actual broken intermediary is identified with this behaviour, that just leads to the thing being fixed and masking is still doing nothing. -Andy From dave@cridland.net Thu Jan 6 05:58:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408B33A6F02 for ; Thu, 6 Jan 2011 05:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X2KzwY4huGc for ; Thu, 6 Jan 2011 05:58:00 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 1BBD43A6E28 for ; Thu, 6 Jan 2011 05:58:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 90AED116811D; Thu, 6 Jan 2011 14:00:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVSIzxQO+72m; Thu, 6 Jan 2011 13:59:57 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id DD75E11680FB; Thu, 6 Jan 2011 13:59:56 +0000 (GMT) References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> In-Reply-To: <4D25C033.3010501@warmcat.com> MIME-Version: 1.0 Message-Id: <10468.1294322396.906068@puncture> Date: Thu, 06 Jan 2011 13:59:56 +0000 From: Dave Cridland To: Andy Green , Server-Initiated HTTP , John Tamplin Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 13:58:02 -0000 On Thu Jan 6 13:14:27 2011, Andy Green wrote: > On 01/06/11 12:55, Somebody in the thread at some point said: >> On Thu Jan 6 11:16:34 2011, Andy Green wrote: >>> But nobody has shown one of these supposed buggy intermediaries or >>> describe how to reproduce a failure involving one. AFAIK because >>> the >>> failure mode is just inferred, nobody has confirmed that whatever >>> was >>> done to Flash and Java in the name of "security" closed any >>> actual holes. >> >> No, it was demonstrated that a strong potential exists, modulo the >> effects of framing (which are pretty unpredictable). It was also >> shown >> that all affected intermediaries ceased to be viable as an attack >> surface given a CONNECT. > > If I understood it, the presence of vulnerable intermediaries was > inferred by a client script doing something or not. Because it was > done via advertising and not under repeatable conditions that are > open to analysis, the reason the script may have appeared to stop > doing something is open to interpretation since the whole stack > between the client and attack sensor is unknown, uncontrolled and > unrepeatable. > > I think that's an unhelpful stance. The general description of the experiment conducted is sufficient to repeat it, but by its nature it selected a largely random set of intermediaries. That's enough to satisfy me that it's essentially valid. > That's why I asked yesterday --> "If you think that's incorrect, it > should surely be possible to explain concisely what the problem is > -- I mean really concisely -- and how it can be reproduced with > normal, maintained and non-broken software in real use that makes > it a websocket problem." > > Streams of data that *look* like HTTP requests sent *after* a supposedly successful Websocket handshake (of the Upgrade type) are known to be interpreted as HTTP requests on some intermediaries. This leads to one of three problems: a) An attacker can access data within the firewall. b) An attacker can poison the intermediary's cache for third-party URIs, leading to the potential case where the Google Analytics script, for example, is poisoned to include script code of the attacker's choice. c) The intermediary fails to pass websocket data flows. However, neither (a) nor (b) was found when CONNECT was used as the sole handshake. (CONNECT has other problems, such as removing semantic transparency of intermediaries, but that's why I suggested using it following an Upgrade). Even occurances of (c) were found to be miniscule. > Completely agree that masking websockets is needless. Even if an > actual broken intermediary is identified with this behaviour, that > just leads to the thing being fixed and masking is still doing > nothing. Right. And I should point out that the paper that first proposed masking also describes an experiment that found it to be worthless given certain precautions. Given the facts, I'm at a loss as to why this particular bandwagon has been so thoroughly jumped upon. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From brofield@gmail.com Thu Jan 6 06:22:50 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E153A6E3C for ; Thu, 6 Jan 2011 06:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFml++OGNsOI for ; Thu, 6 Jan 2011 06:22:42 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B4A7A3A6D3C for ; Thu, 6 Jan 2011 06:22:41 -0800 (PST) Received: by qyj19 with SMTP id 19so17783306qyj.10 for ; Thu, 06 Jan 2011 06:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1vEAxZgxAYS6I2yMzc+5Z4XAIVfQobb+WUUeydzX0qc=; b=qz8tjUbosfqHwETufxuJJE0Iy4kTxtQkVR3+oqO6JDS11Hvv2rYRH1xCj9olrbXmSG UPieL7jUFZNmYY2yEyWID/j0A6+bDF59m3tSg/lKHa8TZ/hL7MdmuaQh1dvYVAZYrX2J t8AC+5WUFNFwekjnIAs+0fVo1lzpASc/HZhI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Iv37iL1TZmytKLUwIEXnpqLv9X0BTYVeStSB71sBySL+n779kS/TaRd/QFMMJSxwxu 9sNJW6KZxt3ZR9fKLkf6+5nhTPz2rsEzYxKg3vjxIOwAvCe3pkT978N2sz6BVIMpZMXe lKoOrloJ4iDOjKMkBpj/e85zFzaNqN7EAXffQ= MIME-Version: 1.0 Received: by 10.229.229.200 with SMTP id jj8mr11349629qcb.74.1294323887504; Thu, 06 Jan 2011 06:24:47 -0800 (PST) Sender: brofield@gmail.com Received: by 10.229.84.66 with HTTP; Thu, 6 Jan 2011 06:24:47 -0800 (PST) In-Reply-To: References: <1293038752.2369.155.camel@ds9.ducksong.com> <4D24B8F0.9090404@callenish.com> <4D24CB44.4070709@callenish.com> <4D250C37.4040505@callenish.com> Date: Fri, 7 Jan 2011 00:24:47 +1000 X-Google-Sender-Auth: 4EQKlQ0rGFbNLVr9gR9vAD5ekTM Message-ID: From: Brodie Thiesfield To: Greg Wilkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 14:22:50 -0000 Opera already support peer to peer HTTP (or peer-proxy-peer) via Unite. I would think that it is a small logical step for them to implement peer to peer websocket as well. http://unite.opera.com/develop/faq/ Peer to peer websocket would enable a whole range of interesting applications, and I don't think that it is that far fetched that it cannot be imagined in the future. Regards, Brodie On Thu, Jan 6, 2011 at 7:43 PM, Greg Wilkins wrote: > On 6 January 2011 01:26, Bruce Atherton wrote: >> It sounds like there is a laser focus of scope for the hybi working grou= p on >> just the interactions between browser and server, and that any other use= case >> need not apply. If that is the case, I will stop bringing up considerati= ons >> of other situations such as standalone clients, the server being the cli= ent >> to another server, or two peers communicating with Websockets, since the= y >> all appear to be out of scope for the WG. > > Bruce, > > a difficulty of this working group is that we were never able to even > agree on a requirement document as the various constituencies > suspected each other of steering the requirements towards their own > use-cases. Hence it is difficult to really say what is in scope or out > of scope. > > But I for one certainly appreciate you raising cases that push the > boundaries of this WG's scope, as good design results from > consideration of edge cases. > > My own work with cometd certainly already has peer to peer usage, we > have a sub-project called the Oort cloud that links up cometd servers > into a cluster. =A0Currently this uses our long polling transport, but > once we implement WS support in our java client, then WS would be a > much better choice. > > We also have many examples in the cometd project of standalone (non > browser) clients being written - in phones and on desktop > applications. =A0Again most of these would benefit from a WS transport. > > Neither of these use-cases run potentially hostile 3rd party code (as > browsers do), so are at much less risk from injection of HTTP-like > content. > > While I dubious about the actual level of threat posed by vulnerable > intermediaries, I fully support the browser vendors interest in > avoiding the issue and believe that mandatory masking is a good > solution for the browsers. =A0 I just don't understand why that means > that masking must be made mandatory for all other use cases. =A0If > browsers don't want the ability to switch it off - then don't write > your code so that it can be switched off. > > regards > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From w@1wt.eu Thu Jan 6 06:39:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489D03A6F17 for ; Thu, 6 Jan 2011 06:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayLy2DOMWXfL for ; Thu, 6 Jan 2011 06:39:57 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id C47783A6F16 for ; Thu, 6 Jan 2011 06:39:56 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p06EfpsF026114; Thu, 6 Jan 2011 15:41:51 +0100 Date: Thu, 6 Jan 2011 15:41:51 +0100 From: Willy Tarreau To: Dave Cridland Message-ID: <20110106144151.GZ15851@1wt.eu> References: <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10468.1294322396.906068@puncture> User-Agent: Mutt/1.4.2.3i Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 14:39:58 -0000 On Thu, Jan 06, 2011 at 01:59:56PM +0000, Dave Cridland wrote: > On Thu Jan 6 13:14:27 2011, Andy Green wrote: > >On 01/06/11 12:55, Somebody in the thread at some point said: > >>On Thu Jan 6 11:16:34 2011, Andy Green wrote: > >>>But nobody has shown one of these supposed buggy intermediaries or > >>>describe how to reproduce a failure involving one. AFAIK because > >>>the > >>>failure mode is just inferred, nobody has confirmed that whatever > >>>was > >>>done to Flash and Java in the name of "security" closed any > >>>actual holes. > >> > >>No, it was demonstrated that a strong potential exists, modulo the > >>effects of framing (which are pretty unpredictable). It was also > >>shown > >>that all affected intermediaries ceased to be viable as an attack > >>surface given a CONNECT. > > > >If I understood it, the presence of vulnerable intermediaries was > >inferred by a client script doing something or not. Because it was > >done via advertising and not under repeatable conditions that are > >open to analysis, the reason the script may have appeared to stop > >doing something is open to interpretation since the whole stack > >between the client and attack sensor is unknown, uncontrolled and > >unrepeatable. > > > > > I think that's an unhelpful stance. The general description of the > experiment conducted is sufficient to repeat it, but by its nature it > selected a largely random set of intermediaries. That's enough to > satisfy me that it's essentially valid. > > > >That's why I asked yesterday --> "If you think that's incorrect, it > >should surely be possible to explain concisely what the problem is > >-- I mean really concisely -- and how it can be reproduced with > >normal, maintained and non-broken software in real use that makes > >it a websocket problem." > > > > > Streams of data that *look* like HTTP requests sent *after* a > supposedly successful Websocket handshake (of the Upgrade type) are > known to be interpreted as HTTP requests on some intermediaries. We only know that in the case where the stream corresponds to a 100% valid HTTP request. I don't believe a minute that such intermediaries will skip all bytes and magically resync on the ones that look like a known method to them. As Bjoern suggested it, we could think about the laziest implementation. A lazy implementation would very possibly consider the stream as the method till the next space. That will not make this method eligible for caching though. Please note that I find your method consisting in emitting a CONNECT efficient against this type of failure. Anyway, now we're going to have masking on by default. Once again, I think it's not a big trouble for browser->server communications, but as some people have raised it here, browsers are not the only HTTP clients, so there is no reason they are the only WebSocket clients. Look at the success of WebServices. They rely on HTTP just like us and they're used between servers. I think that clean WebSocket implementations could very well replace ICAP or simple transaction based protocols which exchange very few data. In all of these situations, masking has a cost and offers no benefit. That's why I'm re-iterating that we should consider the option of disabling masking, but not for browsers. The sole reason we proposed masking is because we suspect that some broken and uncontrolled intermediaries on the net might be vulnerable, and that browsers could become a nice vector to attack them. Within internal networks, there is no such issue and that's where we'd like to save useful CPU cycles and bytes on the wire, so disabling masking there would really make sense. That would also satisfy the needs of those who want to implement border WS gateways which will decode the stream and pass it unencoded to next servers (think about smart load balancers for instance). We're complying with a well-established protocol. We should use the workarounds only when we fear the underlying protocol might not be reliable. But if it is, we should not have to fall back to workarounds. Regards, Willy From andy.warmcat.com@googlemail.com Thu Jan 6 06:54:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83B53A6BAF for ; Thu, 6 Jan 2011 06:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhzH5uTnHVlo for ; Thu, 6 Jan 2011 06:54:39 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 21BBA3A6A0C for ; Thu, 6 Jan 2011 06:54:38 -0800 (PST) Received: by wwa36 with SMTP id 36so16506249wwa.13 for ; Thu, 06 Jan 2011 06:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KLhQgbmztUy+Sgbc8kzbF47xVRXl6agqIPIsEfiOjC0=; b=weuwAGvEzmZygJsltQuQ2Lni2A5HjzPaw3c4hY39cGdkNFpbImd2UsvnmI2mY9dYZY SDdc3i20DfFCY7G8wglbYMtfkjdNnecLmfisgjbKKsH+isHzDNi0LWGz/3X240YMsWUC ocpmGD//kdCyTMhef5BIHyQKdcsSVDmdXAsqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=r1xb8VT7aQ+hvdKNmodaIM+J0XOP7ZN1AmQX7K64gDXjS9JnLXzq0Z/gES9WzL9Bm2 maI+t+rkIHJM4gVFPXXIoQtG56u8n/L3xQQXfLcQXfYJCjvoPfiLBxl172WvbRz2LTdZ cLcg1bmmOLmPTbvAYYIJdcQZYkWCcBd/pp214= Received: by 10.227.155.145 with SMTP id s17mr14757584wbw.29.1294325804862; Thu, 06 Jan 2011 06:56:44 -0800 (PST) Received: from [192.168.1.70] (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id m13sm16861687wbz.3.2011.01.06.06.56.42 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 06:56:43 -0800 (PST) Sender: Andy Green Message-ID: <4D25D82A.8070302@warmcat.com> Date: Thu, 06 Jan 2011 14:56:42 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Cridland References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> In-Reply-To: <10468.1294322396.906068@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 14:54:40 -0000 On 01/06/11 13:59, Somebody in the thread at some point said: > On Thu Jan 6 13:14:27 2011, Andy Green wrote: >> On 01/06/11 12:55, Somebody in the thread at some point said: >>> On Thu Jan 6 11:16:34 2011, Andy Green wrote: >>>> But nobody has shown one of these supposed buggy intermediaries or >>>> describe how to reproduce a failure involving one. AFAIK because the >>>> failure mode is just inferred, nobody has confirmed that whatever was >>>> done to Flash and Java in the name of "security" closed any actual >>>> holes. >>> >>> No, it was demonstrated that a strong potential exists, modulo the >>> effects of framing (which are pretty unpredictable). It was also shown >>> that all affected intermediaries ceased to be viable as an attack >>> surface given a CONNECT. >> >> If I understood it, the presence of vulnerable intermediaries was >> inferred by a client script doing something or not. Because it was >> done via advertising and not under repeatable conditions that are open >> to analysis, the reason the script may have appeared to stop doing >> something is open to interpretation since the whole stack between the >> client and attack sensor is unknown, uncontrolled and unrepeatable. >> > I think that's an unhelpful stance. The general description of the > experiment conducted is sufficient to repeat it, but by its nature it > selected a largely random set of intermediaries. That's enough to > satisfy me that it's essentially valid. There is no evidence at the end of the claims made, no proxy we can look at exhibiting the behaviour and confirm the mechanism, no way to verify that it is fixed or worked around. No way to even zero in on the network or proxy that they claim showed the behaviour. There's no way to close the circle between the observed results and the claimed interpretation of them considering the implementation and the uncontrolled test networks. For example, we might expect to see a POC trashing a particular build of a particular proxy using -76 that is out there. Such an issue can be reproduced, verified, understood, resolved (by updating that proxy), closed. It seems to me that it is quite hard to distinguish the claims in the paper from pure FUD considering the above. >> That's why I asked yesterday --> "If you think that's incorrect, it >> should surely be possible to explain concisely what the problem is -- >> I mean really concisely -- and how it can be reproduced with normal, >> maintained and non-broken software in real use that makes it a >> websocket problem." >> > Streams of data that *look* like HTTP requests sent *after* a supposedly > successful Websocket handshake (of the Upgrade type) are known to be > interpreted as HTTP requests on some intermediaries. This leads to one > of three problems: Yeah I read the same. I'm still waiting to hear how do I reproduce that "with normal, maintained and non-broken software in real use that makes it a websocket problem." When I do hear the exact software that is broken, it becomes a "fix and update your broken proxy" problem with a specific vendor, nothing to do with websockets. We only feel it may be a websocket problem because of this perfect lack of information about what this broken intermediary is and the details how it acts. -Andy From gregw@intalio.com Thu Jan 6 08:34:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001DA3A6D14 for ; Thu, 6 Jan 2011 08:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQyhMjWuhyE4 for ; Thu, 6 Jan 2011 08:34:41 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 0DC863A6C4F for ; Thu, 6 Jan 2011 08:34:40 -0800 (PST) Received: by qyk34 with SMTP id 34so18760556qyk.10 for ; Thu, 06 Jan 2011 08:36:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.53.213 with SMTP id n21mr22904730qag.399.1294331807686; Thu, 06 Jan 2011 08:36:47 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Thu, 6 Jan 2011 08:36:47 -0800 (PST) In-Reply-To: <4D25D82A.8070302@warmcat.com> References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> Date: Thu, 6 Jan 2011 17:36:47 +0100 X-Google-Sender-Auth: 69Qk9TxSc-wSxfl9tKZmO1oGqBA Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:34:42 -0000 So we have one camp that strongly believes that vulnerable intermediaries are our concern and that masking is a credible defence. We have another camp that strongly believes that vulnerable intermediaries, if they exist, are not our concerns and masking is a waste of time. We have a smattering of opinions in between. So we can keep going hammer and tong at each other trying to break down the strongly held views of the other camp.... OR we can find a compromise. Both camps need to accept that the concerns of the other camp are at least valid for them - even if they are dubious if they are real technical concerns or just political/stylistic concerns. Telling somebody: "these are not the concerns you should be worried about" is not very helpful (unless the concerns are about droids and you are obe-wan kenobi). So I think we all have to accept that some want masking and some don't. So surely given this divide, making masking an extension is the reasonable and pragmatic way forward. The browser vendors who appear most concerned about this issue can make the extension mandatory, those that don't want masking in their particular deployment can opt out (so long as they are not using browser). The arguments against masking as an extension are: + it could be turned off. Well then don't implement it as an optional extension! don't allow it to be turned off in vulnerable deployments. + extension mechanism is not up to the task. Well we'd better fix it then, because masking is not that complex and if we can't handle that we have problems. + There may be some attacks that apply to servers from non-WS clients which can have masking turned off. Well if that ever becomes a problem, then those servers can also make the masking extension mandatory. + Complexity of negotiating the extension. Then make it a default extension and you have to negotiate not to have it. It was really great to see some progress towards consensus around Upgrade+Masking. It would be a great pity to see that stalled because of either insistence on a specific style of masking or refusal to accept that some really want to have masking. regards From toni.ruottu@gmail.com Thu Jan 6 09:37:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5FD3A6BC5 for ; Thu, 6 Jan 2011 09:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg8iAyN++Im8 for ; Thu, 6 Jan 2011 09:37:07 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id EF0393A68D5 for ; Thu, 6 Jan 2011 09:37:06 -0800 (PST) Received: by yie19 with SMTP id 19so5040235yie.31 for ; Thu, 06 Jan 2011 09:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=XPgCVGterXujPiSqYWXGRC8DtwISrGzfzH3EgP7iBaU=; b=aP09obTu9Cx80W6geJOZaqObHN/h3S7gDJEepbOIRMrggs09UFb3gPiIBiBq8yYk/w pk58vsk9FPQQlygNDy17ol4BVhU7mLA+gbnLtRgvEJNpXze1vla07yUf7KbfY49i8931 pfdctH+hvJwxspjVmSL88gR7IgH7eiN4sDDiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=j/0zs+b3W6nosMkvGiMwqBALejMlwrqhGb2+xYadl9LzbsHisWIs31ADijxzMY0RAA kCubdZB2AtmEuSLJO0HugCkJoLkuUvRztfRROQaTXuKnhHUr+cM5KAMa+/2D66CmbeNt 15nhYeEIACA5KJyNG9yFqvDOBON9O3w/CaBB0= MIME-Version: 1.0 Received: by 10.90.92.5 with SMTP id p5mr1377105agb.123.1294335553614; Thu, 06 Jan 2011 09:39:13 -0800 (PST) Sender: toni.ruottu@gmail.com Received: by 10.90.25.7 with HTTP; Thu, 6 Jan 2011 09:39:13 -0800 (PST) In-Reply-To: References: <1293038752.2369.155.camel@ds9.ducksong.com> <4D24B8F0.9090404@callenish.com> <4D24CB44.4070709@callenish.com> <4D250C37.4040505@callenish.com> Date: Thu, 6 Jan 2011 19:39:13 +0200 X-Google-Sender-Auth: DNECCYJTlbW9ia1ebElmrULUnxU Message-ID: From: Toni Ruottu To: Brodie Thiesfield Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:37:08 -0000 Greetings. I work for the University of Helsinki. We have drafted an API for embedding WebSocket servers in web pages, and implemented the draft in a Firefox extension. See http://browsersocket.org/ for details. --Toni On Thu, Jan 6, 2011 at 4:24 PM, Brodie Thiesfield wro= te: > Opera already support peer to peer HTTP (or peer-proxy-peer) via > Unite. I would think that it is a small logical step for them to > implement peer to peer websocket as well. > http://unite.opera.com/develop/faq/ > > Peer to peer websocket would enable a whole range of interesting > applications, and I don't think that it is that far fetched that it > cannot be imagined in the future. > > Regards, > Brodie > > > > On Thu, Jan 6, 2011 at 7:43 PM, Greg Wilkins wrote: >> On 6 January 2011 01:26, Bruce Atherton wrote: >>> It sounds like there is a laser focus of scope for the hybi working gro= up on >>> just the interactions between browser and server, and that any other us= ecase >>> need not apply. If that is the case, I will stop bringing up considerat= ions >>> of other situations such as standalone clients, the server being the cl= ient >>> to another server, or two peers communicating with Websockets, since th= ey >>> all appear to be out of scope for the WG. >> >> Bruce, >> >> a difficulty of this working group is that we were never able to even >> agree on a requirement document as the various constituencies >> suspected each other of steering the requirements towards their own >> use-cases. Hence it is difficult to really say what is in scope or out >> of scope. >> >> But I for one certainly appreciate you raising cases that push the >> boundaries of this WG's scope, as good design results from >> consideration of edge cases. >> >> My own work with cometd certainly already has peer to peer usage, we >> have a sub-project called the Oort cloud that links up cometd servers >> into a cluster. =A0Currently this uses our long polling transport, but >> once we implement WS support in our java client, then WS would be a >> much better choice. >> >> We also have many examples in the cometd project of standalone (non >> browser) clients being written - in phones and on desktop >> applications. =A0Again most of these would benefit from a WS transport. >> >> Neither of these use-cases run potentially hostile 3rd party code (as >> browsers do), so are at much less risk from injection of HTTP-like >> content. >> >> While I dubious about the actual level of threat posed by vulnerable >> intermediaries, I fully support the browser vendors interest in >> avoiding the issue and believe that mandatory masking is a good >> solution for the browsers. =A0 I just don't understand why that means >> that masking must be made mandatory for all other use cases. =A0If >> browsers don't want the ability to switch it off - then don't write >> your code so that it can be switched off. >> >> regards >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From w@1wt.eu Thu Jan 6 10:44:06 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9479A3A6F46 for ; Thu, 6 Jan 2011 10:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18PhDnvu6hiI for ; Thu, 6 Jan 2011 10:44:05 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 45E8A3A6F43 for ; Thu, 6 Jan 2011 10:44:04 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p06Ik7wO027218; Thu, 6 Jan 2011 19:46:07 +0100 Date: Thu, 6 Jan 2011 19:46:07 +0100 From: Willy Tarreau To: Greg Wilkins Message-ID: <20110106184607.GB27099@1wt.eu> References: <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:44:06 -0000 Hi Greg, On Thu, Jan 06, 2011 at 05:36:47PM +0100, Greg Wilkins wrote: > So I think we all have to accept that some want masking and some > don't. So surely given this divide, making masking an extension is > the reasonable and pragmatic way forward. That's pretty much the point I was making as my first response to Sal' poll : have the masking mandatory for browsers but ensure that it's easy to make the protocol work without it so that implementations that don't need/want it can get rid of it. > The browser vendors who > appear most concerned about this issue can make the extension > mandatory, those that don't want masking in their particular > deployment can opt out (so long as they are not using browser). In my opinion it should work this way : - client sends handshake to server - server may announce in the first hello frame its masking capabilities and its intent to work with/without masking - browsers just have to refuse the non-masking mode - other clients can safely adapt to the server's capabilities That may even make it possible to support AES-CTR or anything else if some users find it more suited for their task. > The arguments against masking as an extension are: > > + it could be turned off. Well then don't implement it as an > optional extension! don't allow it to be turned off in vulnerable > deployments. > + extension mechanism is not up to the task. Well we'd better fix it > then, because masking is not that complex and if we can't handle that > we have problems. > + There may be some attacks that apply to servers from non-WS clients > which can have masking turned off. Well if that ever becomes a > problem, then those servers can also make the masking extension > mandatory. > + Complexity of negotiating the extension. Then make it a default > extension and you have to negotiate not to have it. I agree with the points above. > It was really great to see some progress towards consensus around > Upgrade+Masking. It would be a great pity to see that stalled > because of either insistence on a specific style of masking or refusal > to accept that some really want to have masking. Once again, I agree with the principle of masking provided it's optional. What annoys me is that every time some progress is made, some unneeded complexity is added somewhere (eg: HMAC to get a random key for each block). All this complexity piling up comes at a substantial cost for those who are not subject at all to the risks it is meant to address. And I'm still thinking about the ability to build WS accelerators, which would simply decode the traffic on the entry point, and use multiplexing to forward it to a bunch of servers. Those severs will have no use of the encoding at all, all they'll want is a low number of threads, file descriptors, and CPU usage. It would be a pity if the front accelerator has to compute an HMAC for every few characters forwarded from a client to a server... Regards, Willy From ekr@rtfm.com Thu Jan 6 10:50:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B48C3A6F3C for ; Thu, 6 Jan 2011 10:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD1geeC6-1td for ; Thu, 6 Jan 2011 10:50:11 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 02CAE3A6CC6 for ; Thu, 6 Jan 2011 10:50:10 -0800 (PST) Received: by yie19 with SMTP id 19so5067826yie.31 for ; Thu, 06 Jan 2011 10:52:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.26.24 with SMTP id d24mr2347850agj.160.1294339937683; Thu, 06 Jan 2011 10:52:17 -0800 (PST) Received: by 10.90.154.19 with HTTP; Thu, 6 Jan 2011 10:52:17 -0800 (PST) In-Reply-To: <20110106184607.GB27099@1wt.eu> References: <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> Date: Thu, 6 Jan 2011 10:52:17 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=001485f9a68c3448dd04993200fb Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:50:12 -0000 --001485f9a68c3448dd04993200fb Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 10:46 AM, Willy Tarreau wrote: > > Once again, I agree with the principle of masking provided it's optional. > What annoys me is that every time some progress is made, some unneeded > complexity is added somewhere (eg: HMAC to get a random key for each > block). I don't recall anyone suggesting that. Certainly, it's not necessary. What's necessary is that the CTR IV for each block be random. Can you point to the message where someone suggested that? -Ekr --001485f9a68c3448dd04993200fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 6, 2011 at 10:46 AM, Willy Tarre= au <w@1wt.eu> wrote:

Once again, I agree with the principle of masking provided it's o= ptional.
What annoys me is that every time some progress is made, some unneeded
complexity is added somewhere (eg: HMAC to get a random key for each
block).

I don't recall anyone suggesti= ng that. Certainly, it's not necessary. What's necessary
= is that the CTR IV for each block be random. Can you point to the message w= here
someone suggested that?

-Ekr


=A0

--001485f9a68c3448dd04993200fb-- From w@1wt.eu Thu Jan 6 14:12:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F5D3A6B9E for ; Thu, 6 Jan 2011 14:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-DOiryHIovD for ; Thu, 6 Jan 2011 14:12:23 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 9FF793A6F48 for ; Thu, 6 Jan 2011 14:12:21 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p06MEQ9V028400; Thu, 6 Jan 2011 23:14:26 +0100 Date: Thu, 6 Jan 2011 23:14:26 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110106221426.GA28367@1wt.eu> References: <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 22:12:24 -0000 On Thu, Jan 06, 2011 at 10:52:17AM -0800, Eric Rescorla wrote: > On Thu, Jan 6, 2011 at 10:46 AM, Willy Tarreau wrote: > > > > > Once again, I agree with the principle of masking provided it's optional. > > What annoys me is that every time some progress is made, some unneeded > > complexity is added somewhere (eg: HMAC to get a random key for each > > block). > > > I don't recall anyone suggesting that. Certainly, it's not necessary. What's > necessary > is that the CTR IV for each block be random. Can you point to the message > where > someone suggested that? It was yourself as a response to John :-) right here : http://www.ietf.org/mail-archive/web/hybi/current/msg05425.html He was suggesting : "... To send a frame, the client performs the following steps: - chooses a random per-frame-key (size TBD based on brute force attacks against the key, but likely 4-8 bytes) - computes the 20-byte SHA1 of the string "WebSocket", server-nonce, client-nonce, per-frame-key (in that order) - send the per-frame-key - XORs each byte in the frame, including headers and after compression if any, with successive bytes of the SHA1 hash and sends them ..." and you replied : "A few comments as token crypto-oriented guy: (1) I'd prefer a UUID to the WebSocket string. (2) I'd prefer HMAC to SHA-1..." Regards, Willy From ekr@rtfm.com Thu Jan 6 15:35:21 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF3C3A6D23 for ; Thu, 6 Jan 2011 15:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTF6FC7S5MaA for ; Thu, 6 Jan 2011 15:35:20 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 211B93A6F7C for ; Thu, 6 Jan 2011 15:35:20 -0800 (PST) Received: by yie19 with SMTP id 19so5162053yie.31 for ; Thu, 06 Jan 2011 15:37:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.232.6 with SMTP id e6mr27519330agh.52.1294357046714; Thu, 06 Jan 2011 15:37:26 -0800 (PST) Received: by 10.90.154.19 with HTTP; Thu, 6 Jan 2011 15:37:26 -0800 (PST) In-Reply-To: <20110106221426.GA28367@1wt.eu> References: <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> Date: Thu, 6 Jan 2011 15:37:26 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=001636284f60fb61b7049935fb4a Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 23:35:21 -0000 --001636284f60fb61b7049935fb4a Content-Type: text/plain; charset=ISO-8859-1 My bad, I misunderstood the context: 1. Yes, I think you should generate completely fresh keystream for each record. 2. We had originally talked about using AES-CTR for this, but it's possible that for export reasons people might prefer HMAC-SHA1. This isn't some piece of new complexity: it's been part of the proposed masking since the very beginning. The only difference is that HMAC-SHA1 is being suggested as an AES-CTR replacement. I realize that you don't think this is necessary, and I guess I might be willing to live with a simpler mechanism, but it's not, as you suggest, something that just appeared when we were starting to make progress. -Ekr On Thu, Jan 6, 2011 at 2:14 PM, Willy Tarreau wrote: > On Thu, Jan 06, 2011 at 10:52:17AM -0800, Eric Rescorla wrote: > > On Thu, Jan 6, 2011 at 10:46 AM, Willy Tarreau wrote: > > > > > > > > Once again, I agree with the principle of masking provided it's > optional. > > > What annoys me is that every time some progress is made, some unneeded > > > complexity is added somewhere (eg: HMAC to get a random key for each > > > block). > > > > > > I don't recall anyone suggesting that. Certainly, it's not necessary. > What's > > necessary > > is that the CTR IV for each block be random. Can you point to the message > > where > > someone suggested that? > > It was yourself as a response to John :-) right here : > > http://www.ietf.org/mail-archive/web/hybi/current/msg05425.html > > He was suggesting : > "... > To send a frame, the client performs the following steps: > - chooses a random per-frame-key (size TBD based on brute force > attacks against the key, but likely 4-8 bytes) > - computes the 20-byte SHA1 of the string "WebSocket", server-nonce, > client-nonce, per-frame-key (in that order) > - send the per-frame-key > - XORs each byte in the frame, including headers and after compression > if any, with successive bytes of the SHA1 hash and sends them > ..." > > and you replied : > > "A few comments as token crypto-oriented guy: > (1) I'd prefer a UUID to the WebSocket string. > (2) I'd prefer HMAC to SHA-1..." > > Regards, > Willy > > --001636284f60fb61b7049935fb4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My bad, I misunderstood the context:

1. Yes, I think you= should generate completely fresh keystream for each record.
2. W= e had originally talked about using AES-CTR for this, but it's possible= that for
export reasons people might prefer HMAC-SHA1.

This isn't some piece of new complexity: it's been part of the pro= posed masking
since the very beginning. The only difference is th= at HMAC-SHA1 is being suggested as
an AES-CTR replacement. I realize that you don't think this is nec= essary, and I guess
I might be willing to live with a simpler mec= hanism, but it's not, as you suggest, something
that just app= eared when we were starting to make progress.

-Ekr

On Thu, Jan 6, 2011 at 2:14 PM, Willy Tarreau <w@1wt.eu> wrote:
On Thu, Jan 06, 2011 at 10:52:17AM -0800,= Eric Rescorla wrote:
> On Thu, Jan 6, 2011 at 10:46 AM, Willy Tarreau <w@1wt.eu> wrote:
>
> >
> > Once again, I agree with the principle of masking provided it'= ;s optional.
> > What annoys me is that every time some progress is made, some unn= eeded
> > complexity is added somewhere (eg: HMAC to get a random key for e= ach
> > block).
>
>
> I don't recall anyone suggesting that. Certainly, it's not nec= essary. What's
> necessary
> is that the CTR IV for each block be random. Can you point to the mess= age
> where
> someone suggested that?

It was yourself as a response to John :-) right here :

=A0 http://www.ietf.org/mail-archive/web/hybi/current/m= sg05425.html

He was suggesting :
=A0 "...
=A0 =A0To send a frame, the client performs the following steps:
=A0 =A0- chooses a random per-frame-key (size TBD based on brute force
=A0 =A0 =A0attacks against the key, but likely 4-8 bytes)
=A0 =A0- computes the 20-byte SHA1 of the string "WebSocket", se= rver-nonce,
=A0 =A0 =A0client-nonce, per-frame-key (in that order)
=A0 =A0- send the per-frame-key
=A0 =A0- XORs each byte in the frame, including headers and after compress= ion
=A0 =A0 =A0if any, with successive bytes of the SHA1 hash and sends them =A0 =A0..."

and you replied :

=A0 "A few comments as token crypto-oriented guy:
=A0 =A0(1) I'd prefer a UUID to the WebSocket string.
=A0 =A0(2) I'd prefer HMAC to SHA-1..."

Regards,
Willy


--001636284f60fb61b7049935fb4a-- From bruce@callenish.com Thu Jan 6 16:14:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91533A6F6B for ; Thu, 6 Jan 2011 16:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7L3UbxcE7o2 for ; Thu, 6 Jan 2011 16:14:04 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id F37603A6F3E for ; Thu, 6 Jan 2011 16:14:03 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pb001-0006jU-MF for hybi@ietf.org; Thu, 06 Jan 2011 16:16:09 -0800 Message-ID: <4D265B4F.2080007@callenish.com> Date: Thu, 06 Jan 2011 16:16:15 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110105095727.GE15851@1wt.eu> <4D245963.5030104@warmcat.com> <4D24D3FB.8040202@ericsson.com> <4D24D5E1.7070309@warmcat.com> <4D24DEAE.8070007@warmcat.com> <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 00:14:04 -0000 On 06/01/2011 8:36 AM, Greg Wilkins wrote: > Both camps need to accept that the concerns of the other camp are at > least valid for them - even if they are dubious if they are real > technical concerns or just political/stylistic concerns. Telling > somebody: "these are not the concerns you should be worried about" is > not very helpful (unless the concerns are about droids and you are > obe-wan kenobi). This is a really important point. The reality is that just because something is not your fault does not mean it is not your problem. I'm sure we have all experienced situations where that is true. For browser developers, just having the browser involved in an attack results in fingers being pointed at them. Masking gives them a simple story to tell about how to prevent a large number of potential attacks and will let them sleep better at night knowing it is less likely that they will have to pull all-nighters to work around some bizarre hack that isn't even their fault. Why not let them have it? Besides, supporting mandatory masking in browsers will be beneficial even to those who don't see the need because it will make future decisions concerning the protocol much easier to make. By limiting attacker control of bits on the wire to just a URL, all kinds of debate about the impact of a change to the Websocket protocol becomes simplified. Just look at how it simplified the GET+Upgrade vs. CONNECT debate. As I've said before, even if you don't personally understand why a group on this list wants something, you should trust them enough to allow that they probably have a good reason for wanting it. > + Complexity of negotiating the extension. Then make it a default > extension and you have to negotiate not to have it. I think this point nicely deals with the asymmetric nature of the client/server behaviour I have an issue with. Imagine if the spec indicates that browsers will only send masked data but will accept either masked or unmasked data back from the server. Then simple servers that didn't fully implement extensions would just mask by default, and those that wanted to efficiently sendfile() or turn off masking in a trusted environment would have to deal with the added complexity of implementing the "nomask" extension, as would clients or peers that wanted no masking. From bruce@callenish.com Thu Jan 6 16:35:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C183A6F63 for ; Thu, 6 Jan 2011 16:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFF+qvWzDHdd for ; Thu, 6 Jan 2011 16:35:35 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id E65C73A6D01 for ; Thu, 6 Jan 2011 16:35:35 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pb0Kr-0003vx-OZ for hybi@ietf.org; Thu, 06 Jan 2011 16:37:41 -0800 Message-ID: <4D26605B.1090409@callenish.com> Date: Thu, 06 Jan 2011 16:37:47 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 00:35:38 -0000 On 06/01/2011 1:43 AM, Greg Wilkins wrote: > > a difficulty of this working group is that we were never able to even > agree on a requirement document as the various constituencies > suspected each other of steering the requirements towards their own > use-cases. Hence it is difficult to really say what is in scope or out > of scope. Thanks for the explanation, Greg. That explains a lot about why this group is so dysfunctional. If you haven't agreed on what your goal is, no wonder you are all pulling in different directions. A trade-off that seems obvious to someone with a specific goal in mind will seem insensible to another person with a different goal. Should the design of Websockets consider uses of peer-to-peer? Should it give consideration to issues that are specific to Intranet use? Should designers of the spec worry about non-browser clients like custom written Websocket clients and Websocket servers that act as clients to other servers? Or is the only thing that really matters when designing Websockets the browser and server interactions, and any other use that happens to work is just gravy? I think that agreeing on these basic questions will likely eliminate a lot of the conflict on this list. Also, as a potential customer of this specification it would be very useful to me to have a clear understanding of what the intended uses for Websockets are, so that I can better understand where I am supposed to be applying it in my future designs. So far it appears that Greg, Brodie, Jerod, and I favour including peer-to-peer design considerations in the spec. I am not sure, but it sounds like John considers it out of scope and Scott considers it in scope. What about the rest of you? From jat@google.com Thu Jan 6 17:22:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5862C3A6BA8 for ; Thu, 6 Jan 2011 17:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.903 X-Spam-Level: X-Spam-Status: No, score=-103.903 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF45Kizt5fzH for ; Thu, 6 Jan 2011 17:22:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 308D13A69C9 for ; Thu, 6 Jan 2011 17:22:14 -0800 (PST) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p071OKYX017616 for ; Thu, 6 Jan 2011 17:24:20 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294363460; bh=6IP7JNZtMc7HFWTjfJzSFokg8wI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=jdhzTvASudAM13jtJDlWv8vgbjacuPtSBbJX9ufzbEbfnC2TEkhetvqtGfQfWza4X ig7ncuISRv3YgxTn0QfTw== Received: from gxk20 (gxk20.prod.google.com [10.202.11.20]) by hpaq13.eem.corp.google.com with ESMTP id p071OIA8009785 for ; Thu, 6 Jan 2011 17:24:18 -0800 Received: by gxk20 with SMTP id 20so7210525gxk.6 for ; Thu, 06 Jan 2011 17:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=Ijp7S6MKXFWWK6S7JAhuwObqFIfbjQocbGcqnjn7jYU=; b=EZMqXGfuLjyYCq3F6mZmVPe05+QY/zUa1PJ2nTkxy7VPzFOTRRY1mz2IbjBZv7APqS mUi63qdXvjXjasqkX4lQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=TaIfNQvShPIH95BlblNp0u7YUesElCYbiiPsSx/3LopPGrslH5wqRd6ChmnoQ6jli1 /oIDEmJtT6anoERrbA7Q== Received: by 10.150.228.1 with SMTP id a1mr7554250ybh.434.1294363457491; Thu, 06 Jan 2011 17:24:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Thu, 6 Jan 2011 17:23:57 -0800 (PST) In-Reply-To: <4D26605B.1090409@callenish.com> References: <4D26605B.1090409@callenish.com> From: John Tamplin Date: Thu, 6 Jan 2011 20:23:57 -0500 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=000e0cd4040e1811b00499377ab1 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 01:22:15 -0000 --000e0cd4040e1811b00499377ab1 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton wrote: > So far it appears that Greg, Brodie, Jerod, and I favour including > peer-to-peer design considerations in the spec. I am not sure, but it sounds > like John considers it out of scope and Scott considers it in scope. What > about the rest of you? > I am not opposed to it exactly, but given how long everything has taken I am keen to keep the base protocol minimal so we can actually get something out the door. Just like when we were discussing compression, multiplexing, and metadata during the design of the basic framing, we weren't getting anywhere until we stripped it down to the minimum. To overcome objections about stripping out too much, I wrote up examples of how the base framing could be extended in a compatible fashion to incorporate those use-cases and we were able to agree on the base framing. If you think peer-to-peer WebSockets is important, I suggest talking about specific things that need to be represented in the base protocol in order to allow that be added at a later time. So far the suggestion has been that masking is mandatory and an extension could be defined in the future to remove it has been met with skepticism that people who build infrastructure pieces will build in that extensibility (if I am mis-stating the objections, please correct me). I'm not sure this is any different than the compression/mux/metadata cases we already dealt with, and my feeling is if such equipment has to be upgraded later to support new things so be it. I personally am fine with adding language into the spec saying what things are expected to be changed so implementors should be prepared to update the handling if that helps address the concern. However, I am really loathe to try and define peer-to-peer operation in the base spec because I think it will unreasonably extend the process of getting the base protocol out the door. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd4040e1811b00499377ab1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton <= span dir=3D"ltr"><bruce@callenish= .com> wrote:
So far it appears that Greg, Brodie, Jerod, and I favour = including peer-to-peer design considerations in the spec. I am not sure, bu= t it sounds like John considers it out of scope and Scott considers it in s= cope. What about the rest of you?

I am not opposed to it exactly, but given = how long everything has taken I am keen to keep the base protocol minimal s= o we can actually get something out the door.

Just like when we were discussing compression, multiplexing, and metadata d= uring the design of the basic framing, we weren't getting anywhere unti= l we stripped it down to the minimum. =C2=A0To overcome objections about st= ripping out too much, I wrote up examples of how the base framing could be = extended in a compatible fashion to incorporate those use-cases and we were= able to agree on the base framing.

If you think peer-to-peer WebSockets is important, I su= ggest talking about specific things that need to be represented in the base= protocol in order to allow that be added at a later time. =C2=A0So far the= suggestion has been that masking is mandatory and an extension could be de= fined in the future to remove it has been met with=C2=A0skepticism=C2=A0tha= t people who build infrastructure pieces will build in that extensibility (= if I am mis-stating the objections, please correct me). =C2=A0I'm not s= ure this is any different than the compression/mux/metadata cases we alread= y dealt with, and my feeling is if such equipment has to be upgraded later = to support new things so be it. =C2=A0I personally am fine with adding lang= uage into the spec saying what things are expected to be changed so impleme= ntors should be prepared to update the handling if that helps address the c= oncern. =C2=A0However, I am really loathe to try and define peer-to-peer op= eration in the base spec because I think it will unreasonably extend the pr= ocess of getting the base protocol out the door.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd4040e1811b00499377ab1-- From gmonte@microsoft.com Thu Jan 6 17:41:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7158E3A6C9E for ; Thu, 6 Jan 2011 17:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.472 X-Spam-Level: X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoZYzeAND0Kd for ; Thu, 6 Jan 2011 17:41:57 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 57D193A6BA8 for ; Thu, 6 Jan 2011 17:41:57 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 6 Jan 2011 17:43:57 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.255.3; Thu, 6 Jan 2011 17:43:57 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 6 Jan 2011 17:43:57 -0800 From: Gabriel Montenegro To: John Tamplin , Bruce Atherton Thread-Topic: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? Thread-Index: AQHLrgmq/w4+Ld5wRUKExWVhu67oqJPEu34w Date: Fri, 7 Jan 2011 01:44:30 +0000 Message-ID: References: <4D26605B.1090409@callenish.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C110FCFEC82TK5EX14MBXW604w_" MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 01:41:58 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C110FCFEC82TK5EX14MBXW604w_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpKb2huIFRhbXBsaW4gd3JvdGU6DQrigKYgIEhvd2V2ZXIsIEkgYW0gcmVhbGx5IGxvYXRoZSB0 byB0cnkgYW5kIGRlZmluZSBwZWVyLXRvLXBlZXIgb3BlcmF0aW9uIGluIHRoZSBiYXNlIHNwZWMg YmVjYXVzZSBJIHRoaW5rIGl0IHdpbGwgdW5yZWFzb25hYmx5IGV4dGVuZCB0aGUgcHJvY2VzcyBv ZiBnZXR0aW5nIHRoZSBiYXNlIHByb3RvY29sIG91dCB0aGUgZG9vci4NCg0KW2dhYl0gSSBhZ3Jl ZS4gV0dzIGFyZSB0eXBpY2FsbHkgY2hhcnRlcmVkIHdpdGggYSBzcGVjaWZpYyBmb2N1cyBpbiBv cmRlciB0byBlYXNlIHByb2dyZXNzLiBUaGUgY2hhcnRlciBhcyBhcHByb3ZlZCBieSB0aGUgSUVT RyBpbmNsdWRlcyB0aGlzOg0KICBUaGUgSHlwZXJ0ZXh0LUJpZGlyZWN0aW9uYWwgKEh5QmkpIHdv cmtpbmcgZ3JvdXAgd2lsbCBzZWVrDQogIHN0YW5kYXJkaXphdGlvbiBvZiBvbmUgYXBwcm9hY2gg dG8gbWFpbnRhaW4gYmlkaXJlY3Rpb25hbA0KICBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIHRoZSBI VFRQIGNsaWVudCwgc2VydmVyIGFuZCBpbnRlcm1lZGlhdGUNCiAgZW50aXRpZXMsIHdoaWNoIHdp bGwgcHJvdmlkZSBtb3JlIGVmZmljaWVuY3kgY29tcGFyZWQgdG8gdGhlIGN1cnJlbnQNCiAgdXNl IG9mIGhhbmdpbmcgcmVxdWVzdHMuDQoNCg0KVGhpcyBwcm9taW5lbnRseSB0YWxrcyBhYm91dCBj bGllbnQtc2VydmVyIG5vdCBwZWVyLXRvLXBlZXIuICBXaGVuIHBlb3BsZSBoYXZlIGFza2VkIG1l IGlmIHAycCBpcyBpbiBzY29wZSwgSeKAmXZlIGFsd2F5cyBhbnN3ZXJlZCDigJxubywgYnkgY2hh cnRlcuKAnSBhcyB0aGF0IGlzIGhvdyBJ4oCZdmUgaW50ZXJwcmV0ZWQgdGhlIGFib3ZlLiBHaXZl biB0aGUgZGlmZmljdWx0aWVzIGluIHRoaXMgZ3JvdXAsIEkgYWdyZWUgdGhhdCBpcyBiZXN0IGxl ZnQgYWZ0ZXIgd2UgZGVsaXZlciBvbiB0aGUgY3VycmVudCBpdGVtcy4gV2UgY2FuIHRoZW4gdGFj a2xlIGEgcmUtY2hhcnRlcmluZyBvcGVyYXRpb24gYW5kIG1vdmUgb24gdG8gb3RoZXIgZWZmb3J0 cywgYnV0IGZvciBub3cgSSB0aGluayB0aGF0IGlzIG5vdCBvbmx5IG91dCBvZiBzY29wZSwgYnV0 IHdvdWxkIGRlbGF5IHVzIGV2ZW4gZnVydGhlci4NCg== --_000_CA566BAEAD6B3F4E8B5C5C4F61710C110FCFEC82TK5EX14MBXW604w_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7 DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hv IjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+Sm9obiBUYW1wbGluIHdyb3RlOjxicj48Yj48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+4oCmPC9zcGFuPjwvYj48L3NwYW4+ICZuYnNwO0hvd2V2ZXIsIEkg YW0gcmVhbGx5IGxvYXRoZSB0byB0cnkgYW5kIGRlZmluZSBwZWVyLXRvLXBlZXIgb3BlcmF0aW9u IGluIHRoZSBiYXNlIHNwZWMgYmVjYXVzZSBJIHRoaW5rIGl0IHdpbGwgdW5yZWFzb25hYmx5IGV4 dGVuZCB0aGUgcHJvY2VzcyBvZiBnZXR0aW5nIHRoZSBiYXNlIHByb3RvY29sIG91dCB0aGUgZG9v ci48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48Yj48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltnYWJdIDwvc3Bhbj48 L2k+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBhZ3JlZS4gV0dzIGFyZSB0eXBpY2FsbHkg Y2hhcnRlcmVkIHdpdGggYSBzcGVjaWZpYyBmb2N1cyBpbiBvcmRlciB0byBlYXNlIHByb2dyZXNz LiBUaGUgY2hhcnRlciBhcyBhcHByb3ZlZCBieSB0aGUgSUVTRyBpbmNsdWRlcyB0aGlzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqAgVGhlIEh5cGVydGV4dC1CaWRp cmVjdGlvbmFsIChIeUJpKSB3b3JraW5nIGdyb3VwIHdpbGwgc2VlazxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqAgc3RhbmRhcmRpemF0aW9uIG9mIG9uZSBhcHByb2Fj aCB0byBtYWludGFpbiBiaWRpcmVjdGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz7CoCBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIHRoZSBIVFRQIGNsaWVudCwgc2Vy dmVyIGFuZCBpbnRlcm1lZGlhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPsKgIGVudGl0aWVzLCB3aGljaCB3aWxsIHByb3ZpZGUgbW9yZSBlZmZpY2llbmN5IGNvbXBh cmVkIHRvIHRoZSBjdXJyZW50PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz7CoCB1c2Ugb2YgaGFuZ2luZyByZXF1ZXN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhpcyBwcm9taW5lbnRseSB0 YWxrcyBhYm91dCBjbGllbnQtc2VydmVyIG5vdCBwZWVyLXRvLXBlZXIuIMKgV2hlbiBwZW9wbGUg aGF2ZSBhc2tlZCBtZSBpZiBwMnAgaXMgaW4gc2NvcGUsIEnigJl2ZSBhbHdheXMgYW5zd2VyZWQg 4oCcbm8sIGJ5IGNoYXJ0ZXLigJ0gYXMgdGhhdCBpcyBob3cgSeKAmXZlIGludGVycHJldGVkIHRo ZSBhYm92ZS4gR2l2ZW4gdGhlIGRpZmZpY3VsdGllcyBpbiB0aGlzIGdyb3VwLCBJIGFncmVlIHRo YXQgaXMgYmVzdCBsZWZ0IGFmdGVyIHdlIGRlbGl2ZXIgb24gdGhlIGN1cnJlbnQgaXRlbXMuIFdl IGNhbiB0aGVuIHRhY2tsZSBhIHJlLWNoYXJ0ZXJpbmcgb3BlcmF0aW9uIGFuZCBtb3ZlIG9uIHRv IG90aGVyIGVmZm9ydHMsIGJ1dCBmb3Igbm93IEkgdGhpbmsgdGhhdCBpcyBub3Qgb25seSBvdXQg b2Ygc2NvcGUsIGJ1dCB3b3VsZCBkZWxheSB1cyBldmVuIGZ1cnRoZXIuPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_CA566BAEAD6B3F4E8B5C5C4F61710C110FCFEC82TK5EX14MBXW604w_-- From ferg@caucho.com Thu Jan 6 17:57:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F7C3A6E37 for ; Thu, 6 Jan 2011 17:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHkDJXAqHjjH for ; Thu, 6 Jan 2011 17:57:57 -0800 (PST) Received: from nm17-vm0.bullet.mail.ac4.yahoo.com (nm17-vm0.bullet.mail.ac4.yahoo.com [98.139.53.208]) by core3.amsl.com (Postfix) with SMTP id 898313A6D1C for ; Thu, 6 Jan 2011 17:57:57 -0800 (PST) Received: from [98.139.52.193] by nm17.bullet.mail.ac4.yahoo.com with NNFMP; 07 Jan 2011 02:00:01 -0000 Received: from [98.139.52.156] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 07 Jan 2011 02:00:01 -0000 Received: from [127.0.0.1] by omp1039.mail.ac4.yahoo.com with NNFMP; 07 Jan 2011 02:00:01 -0000 X-Yahoo-Newman-Id: 677754.75467.bm@omp1039.mail.ac4.yahoo.com Received: (qmail 909 invoked from network); 7 Jan 2011 02:00:01 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 06 Jan 2011 18:00:01 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: OyGkfYMVM1mT1ogWZM1N6NnzNDgfO7cch7IFIIL.mvtQUYy vTiALUOZCf9tnUKg8tRhoMzDYvjFPU19nidL4It40aduo6.GrBmX_b5hIS1C 6uZvBGonjwqy.iQ8WJZS_BDtVEW9AynF6ERF3G5YcO5BU8Fl.eNW.Tgro25l J51cPa7YBmuO7jea_LNkhoZ4Ng0cBxVeCnRDBWXwu8tnwxK4r92ukfB.or2P .FjzJn6wkKA51Aw1kIMIchZKuUQK.6Kls9cxtAFFuBD_RQCeT6rnDStemg7b s9UCO4G7B8O3ecjcQTXUv_KBhyducp0_Etc5AThv7PSSwDvL0uDcJhqN3.iW uflx39fMNGTTJSmuFTMTnAx1bui7aVpUu X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D2673A0.1080101@caucho.com> Date: Thu, 06 Jan 2011 18:00:00 -0800 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: John Tamplin References: <4D26605B.1090409@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 01:57:59 -0000 John Tamplin wrote: > On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton > wrote: > > So far it appears that Greg, Brodie, Jerod, and I favour including > peer-to-peer design considerations in the spec. I am not sure, but > it sounds like John considers it out of scope and Scott considers > it in scope. What about the rest of you? > > > I am not opposed to it exactly, but given how long everything has > taken I am keen to keep the base protocol minimal so we can actually > get something out the door. +1 > If you think peer-to-peer WebSockets is important, I suggest talking > about specific things that need to be represented in the base protocol > in order to allow that be added at a later time.... However, I am > really loathe to try and define peer-to-peer operation in the base > spec because I think it will unreasonably extend the process of > getting the base protocol out the door. +1 As long as the unmasked framing can be used for a clean peer-to-peer protocol, the WebSocket handshake/client-masking can be focused on the browser case. (It would be a problem if the client masking were to change the current framing significantly, but I don't think that kind of change has been proposed.) -- Scott > > -- > John A. Tamplin > Software Engineer (GWT), Google > ------------------------------------------------------------------------ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From ekr@rtfm.com Thu Jan 6 18:07:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C59B3A6E37 for ; Thu, 6 Jan 2011 18:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZruApoqdy0DB for ; Thu, 6 Jan 2011 18:07:14 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 2F9D83A6DD2 for ; Thu, 6 Jan 2011 18:07:14 -0800 (PST) Received: by ywk9 with SMTP id 9so7498000ywk.31 for ; Thu, 06 Jan 2011 18:09:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.83.18 with SMTP id k18mr2685428agl.79.1294366160680; Thu, 06 Jan 2011 18:09:20 -0800 (PST) Received: by 10.90.154.19 with HTTP; Thu, 6 Jan 2011 18:09:20 -0800 (PST) In-Reply-To: References: <4D26605B.1090409@callenish.com> Date: Thu, 6 Jan 2011 18:09:20 -0800 Message-ID: From: Eric Rescorla To: Gabriel Montenegro Content-Type: multipart/alternative; boundary=0016e6407c64377fe50499381b3c Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 02:07:15 -0000 --0016e6407c64377fe50499381b3c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree. This is clearly out of charter scope. Even were it not out of scope, the P2P problem is clearly distinct, for a number of reasons: 1. There is no expectation of being able to travel over an HTTP substrate, even initially. 2. The issue of NAT traversal must be addressed and turns out to require a confirmation handshake in any case. 3. Many of the most interesting cases involve UDP which raises another set of issues. As I said earlier, there is already an effort to address this, but it's not appropriate for this WG. -Ekr On Thu, Jan 6, 2011 at 5:44 PM, Gabriel Montenegro wr= ote: > > > John Tamplin wrote: > *=85* However, I am really loathe to try and define peer-to-peer operati= on > in the base spec because I think it will unreasonably extend the process = of > getting the base protocol out the door. > > > > *[gab] *I agree. WGs are typically chartered with a specific focus in > order to ease progress. The charter as approved by the IESG includes this= : > > The Hypertext-Bidirectional (HyBi) working group will seek > > standardization of one approach to maintain bidirectional > > communications between the HTTP client, server and intermediate > > entities, which will provide more efficiency compared to the current > > use of hanging requests. > > > > > > This prominently talks about client-server not peer-to-peer. When people > have asked me if p2p is in scope, I=92ve always answered =93no, by charte= r=94 as > that is how I=92ve interpreted the above. Given the difficulties in this > group, I agree that is best left after we deliver on the current items. W= e > can then tackle a re-chartering operation and move on to other efforts, b= ut > for now I think that is not only out of scope, but would delay us even > further. > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --0016e6407c64377fe50499381b3c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree. This is clearly out of charter scope.

Even were= it not out of scope, the P2P problem is clearly distinct, for a number of = reasons:

1. There is no expectation of being able = to travel over an HTTP substrate, even initially.
2. The issue of NAT traversal must be addressed and turns out to requi= re a confirmation handshake
=A0=A0 =A0in any case.
3. M= any of the most interesting cases involve UDP which raises another set of i= ssues.

As I said earlier, there is already an effort to addres= s this, but it's not appropriate for this WG.

= -Ekr




On Thu, Jan 6, 2011 at 5:44 PM, Gabriel Montenegro <gmonte@microsoft.com> w= rote:

=A0

John = Tamplin wrote:
=85 = =A0However, I am really loathe to try and define peer-to-peer operation in = the base spec because I think it will unreasonably extend the process of ge= tting the base protocol out the door.

=A0

[gab] I agree. WGs are typically chartered with a = specific focus in order to ease progress. The charter as approved by the IE= SG includes this:

=A0 The Hypertext-Bidirectional (HyBi) working group will = seek

=A0 standardization of one approach to main= tain bidirectional

=A0 communications between the HTTP client, server and int= ermediate

=A0 entities, which will provide more = efficiency compared to the current

=A0 use of hanging requests.

= =A0

=A0

This prominently talks about client-server not peer-to-peer. =A0When pe= ople have asked me if p2p is in scope, I=92ve always answered =93no, by cha= rter=94 as that is how I=92ve interpreted the above. Given the difficulties= in this group, I agree that is best left after we deliver on the current i= tems. We can then tackle a re-chartering operation and move on to other eff= orts, but for now I think that is not only out of scope, but would delay us= even further.


_________________________________________= ______
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--0016e6407c64377fe50499381b3c-- From jat@google.com Thu Jan 6 18:36:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119993A6E3B for ; Thu, 6 Jan 2011 18:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.887 X-Spam-Level: X-Spam-Status: No, score=-103.887 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6GbiMT9rzKb for ; Thu, 6 Jan 2011 18:36:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CDEDC3A6E28 for ; Thu, 6 Jan 2011 18:36:46 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p072crKD022521 for ; Thu, 6 Jan 2011 18:38:53 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294367933; bh=qWEQ1mTaYnfOhIfyEwC0aZ2GG48=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=mwKmqwW0qAGhOAyY0mVLm3rKvY/JhTTTT07/6qhNKoHElWDTPmEFEWnoXiICrSnAz IsyhsxPoBXPZXSqXZBCKQ== Received: from yib2 (yib2.prod.google.com [10.243.65.66]) by wpaz5.hot.corp.google.com with ESMTP id p072cqfK015467 for ; Thu, 6 Jan 2011 18:38:52 -0800 Received: by yib2 with SMTP id 2so4431559yib.8 for ; Thu, 06 Jan 2011 18:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=7Gz+OLqazjhn64Q6eUURF3tTzOVpD24kQ7Tlr9bKmp8=; b=EyE9949b1ldvDYIvpe5FajDQ1zwu1DH09aFXw4qUDOcORuIB6rtOVn7vzWMGwRtQOo /0ADq+5nljzNYGhmhU4Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=DeHrb6oLjRO17rK49nw5lrBQo7uL4a9F1cHyxLhHJCJWRLsfClEVdKbI8kNDt8kGDH kVeX3+l+nJc0VdsxDRGA== Received: by 10.151.158.12 with SMTP id k12mr24089584ybo.377.1294367930911; Thu, 06 Jan 2011 18:38:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Thu, 6 Jan 2011 18:38:30 -0800 (PST) In-Reply-To: References: From: John Tamplin Date: Thu, 6 Jan 2011 21:38:30 -0500 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 02:36:48 -0000 Ok, I understand your complaint about unlike SSL and other wrappers, the proposed masking means an observer can't tell frame boundaries without unmasking first. I am still not sure that is such a big deal considering the simplicity of the proposed masking relative to interpreting the framing anyway, but here is another attempt to satisfy all concerned: Since I don't want to renogiate anything we have already agreed in the base framing, that means that Extension Data can only have a non-zero length if we negotiate an extension, so that means we can't have masking be the default and define a new extension later to remove it. My proposal: 1) Define a new extension "clientmask" in the base spec, which specifies that client->server masking is present. An optional parameter "type" specifies the type of masking, and if not present defaults to "hmac-sha1". (this leave open the option of defining new masking methods in the future). 2) Any clients which make WebSocket connections at the request of untrusted code or entities and do not know for certain that the entire path to the ultimate server is trusted MUST request the clientmask extension and MUST fail the connection if the server does not accept the extension. 3) Any servers (or intermediaries acting as servers to the client) accepting a connection from an untrusted source MUST NOT accept a connection which does not request the clientmask extension. A server accepting a connection from a client that is known to transit only trusted networks MAY accept connections which do not request the clientmask extension. A server which allows connections without the clientmask extension SHOULD default to no trusted networks and be configurable as to which networks are allowed to connect without the clientmask extension. 4) If the clientmask extension is negotiated, the first n bytes of the extension data of client-server frames is a per-frame key defined by the masking type, and the remainder of the payload (including any further bytes of extension data and application data) are masked as defined by the masking type. 5) For clientmask type of "hmac-sha1", the per-frame key length shall be 4 bytes, and the remainder of the frame shall be masked according to the following algorithm: Let client-nonce and server-nonce be the respective nonces exchanged during the handshake. =C2=A0Let uid be a 20-byte constant defined in the standard, and per-frame-key be the masking key read from the extension data. // computed once during the handshake sessionKey =3D HMAC-SHA1(uid, client-nonce || server-nonce); for (int blockStart =3D 0; blockStart < remainingLength; blockStart += =3D 20) { =C2=A0mask =3D HMAC-SHA1(sessionKey, per-frame-key || blockStart); =C2=A0for (int i =3D 0; i < 20 && blockStart + i < remainingLength; ++= i) { =C2=A0 =C2=A0 remainingPayload[blockStart + i] ^=3D mask[i]; =C2=A0 } } The same operation is performed for masking and unmasking. The intent of #1 is to conform to requirements established in the current framing, in that Extension Data can only be used if an extension is negotiated, as well as allowing the masking algorithm to be refined in the future without defining a new extension. The intent of #2 & #3 is to allow the use-cases that have been brought up, where the safety provided by masking is not needed. -- John A. Tamplin Software Engineer (GWT), Google From Martin.Thomson@andrew.com Thu Jan 6 19:11:06 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4E13A6E28 for ; Thu, 6 Jan 2011 19:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaae4OzoOxkN for ; Thu, 6 Jan 2011 19:11:05 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 4DB313A6DF7 for ; Thu, 6 Jan 2011 19:11:01 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:31864 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S485828Ab1AGDNH (ORCPT ); Thu, 6 Jan 2011 21:13:07 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 6 Jan 2011 21:13:07 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 7 Jan 2011 11:13:04 +0800 From: "Thomson, Martin" To: John Tamplin , Greg Wilkins Date: Fri, 7 Jan 2011 11:13:02 +0800 Thread-Topic: [hybi] proposed masking Thread-Index: AcuuFDwRlkEUguIrQTyuEhtiTayDWwAAq8kw Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5258D4E@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Hybi Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 03:11:07 -0000 T24gMjAxMS0wMS0wNyBhdCAxMzozODozMCwgSm9obiBUYW1wbGluIHdyb3RlOg0KPiAgICAgLy8g Y29tcHV0ZWQgb25jZSBkdXJpbmcgdGhlIGhhbmRzaGFrZQ0KPiAgICAgc2Vzc2lvbktleSA9IEhN QUMtU0hBMSh1aWQsIGNsaWVudC1ub25jZSB8fCBzZXJ2ZXItbm9uY2UpOwkNCj4gDQo+ICAgICBm b3IgKGludCBibG9ja1N0YXJ0ID0gMDsgYmxvY2tTdGFydCA8IHJlbWFpbmluZ0xlbmd0aDsgYmxv Y2tTdGFydA0KPiArPSAyMCkgewkNCj4gICAgICDCoG1hc2sgPSBITUFDLVNIQTEoc2Vzc2lvbktl eSwgcGVyLWZyYW1lLWtleSB8fCBibG9ja1N0YXJ0KTsNCj4gICAgICDCoGZvciAoaW50IGkgPSAw OyBpIDwgMjAgJiYgYmxvY2tTdGFydCArIGkgPCByZW1haW5pbmdMZW5ndGg7ICsraSkgew0KPiAg ICAgwqAgIMKgIHJlbWFpbmluZ1BheWxvYWRbYmxvY2tTdGFydCArIGldIF49IG1hc2tbaV07DQo+ ICAgICDCoCB9DQo+ICAgICB9DQo+IA0KPiAgICAgVGhlIHNhbWUgb3BlcmF0aW9uIGlzIHBlcmZv cm1lZCBmb3IgbWFza2luZyBhbmQgdW5tYXNraW5nLg0KDQpDaGFuZ2luZyB0aGUgbWFzayBjb250 aW51b3VzbHkgaXMgb25seSBuZWNlc3NhcnkgaWYgdGhlIHJlY2lwaWVudCBjYW4gZ2V0IHRoZSBz ZW5kZXIgdG8gYWx0ZXIgd2hhdCB0aGV5IHNlbmQgbWlkLW1lc3NhZ2UuICBXaGV0aGVyIHRoYXQg aXMgZ29pbmcgdG8gYmUgbmVjZXNzYXJ5IGRlcGVuZHMgb24gdGhlIGludGVyZmFjZSBwcm92aWRl ZCB0byB0aGUgc2VuZGVyLg0KDQpJZiBhIGJyb3dzZXIgb25seSBvZmZlcnMgYW4gQVBJIHRoYXQg YWNjZXB0cyBlbnRpcmUgZnJhbWVzIGZvciBzZW5kaW5nLCB0aGUgc2VuZGVyIGRvZXNuJ3QgZ2V0 IGEgY2hhbmNlIHRvIG1vZGlmeSBmcmFtZSBjb250ZW50cyBvbiB0aGUgZmx5IGFuZCB0aGlzIGFs Z29yaXRobSBpcyBnb2luZyB0byBiZSBvdmVya2lsbC4gIEkgZG9uJ3Qga25vdyB3aGF0IHRoZSBp bXBhY3Qgd291bGQgYmUsIGJ1dCBpdCBkb2VzIHNlZW0gbGlrZSBhIHNhdmluZyB3b3J0aCBjb25z aWRlcmluZy4gIE1heWJlIGl0J3Mgb25seSBhbiBvcHRpb24sIGJ1dCB0aGUgY2xpZW50IChicm93 c2VyKSBpcyBpbiB0aGUgYmVzdCBwb3NpdGlvbiB0byBtYWtlIHRoYXQgZGV0ZXJtaW5hdGlvbi4N Cg0KVGhhdCBpczoNCg0KICAgICAgc2Vzc2lvbktleSA9IEhNQUModWlkLCBjbGllbnQtbm9uY2Ug fHwgc2VydmVyLW5vbmNlKTsNCiAgICAgIG1hc2sgPSBITUFDKHNlc3Npb25LZXksIHBlci1mcmFt ZS1rZXkpOw0KICAgICAgZm9yIChpbnQgaSA9IDA7IGkgPCBsZW5ndGg7ICsraSkgew0KICAgICAg ICAgcGF5bG9hZFtpJUhNQUNfTEVOXSBePSBtYXNrW2klSE1BQ19MRU5dOw0KICAgICAgfQ0KDQpJ ZiB0aGUgcGVyLWZyYW1lLWtleSBpcyBjaGFuZ2VkIG9uIGVhY2ggZnJhbWUsIHRoZW4gc3RyZWFt aW5nIGNhbiBzdGlsbCBiZSBkb25lIHdpdGggdGhpcyBtZWNoYW5pc20sIHlvdSBqdXN0IGhhdmUg dG8gYnVmZmVyIGFuIGVudGlyZSBmcmFtZSBiZWZvcmUgc2VuZGluZyBpdCBhbmQgdXNlIGNvbnRp bnVhdGlvbnMuDQoNCi0tTWFydGluDQo= From bruce@callenish.com Thu Jan 6 19:17:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B693A6C74 for ; Thu, 6 Jan 2011 19:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77kXZZ92iKLB for ; Thu, 6 Jan 2011 19:17:26 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id EC2583A677D for ; Thu, 6 Jan 2011 19:17:25 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pb2rP-0000VL-IE for hybi@ietf.org; Thu, 06 Jan 2011 19:19:29 -0800 Message-ID: <4D268644.9040800@callenish.com> Date: Thu, 06 Jan 2011 19:19:32 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <4D26605B.1090409@callenish.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070307040003060102050108" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 03:17:27 -0000 This is a multi-part message in MIME format. --------------070307040003060102050108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I am not talking about designing the specifics of peer to peer into the protocol. I am talking about everybody being clear on what they are designing. The question about peer to peer is just one of several in that vein. Perhaps you think that everybody is in agreement in their vision of Websockets, but it sure doesn't look that way to me, and I think that is where some of the polarization is coming from. If everyone agrees that design decisions should be based only on browser-server interaction, then there is no need to talk about optional masking. If peer to peer is out of scope, then there is no need to worry about the asymmetry of the client and server. Suddenly progress can be made much more easily because a lot of objections will simply disappear. When you introduce intermediaries it can get more complicated, depending on what you decide is in scope. Greg's muxer probably is. Willy's WS Accelerator and my usecases with servers acting as clients, perhaps or perhaps not. Which ones you include for consideration are going to have an impact on what issues should be given weight when designing the protocol. Correct me if I am wrong, but my understanding from what you have written is that you are principally concerned with browser to server interactions, and other scenarios that happen to work out are fine with you but need not be designed for. So it makes sense that you don't see a particular need for optional masking or have much concern about clients masking their frames and servers not. This view of the protocol is going to inform many more of your decisions as they come up. But it is clear from Greg's description that he has a very different vision of where he sees Websockets being used. You are designing a screwdriver and he is designing a drill that can hold screwdriver bits. Both are useful tools, but the trade-offs for each are going to be different. So all I'm suggesting is that you all clarify among yourselves what is in scope and what is not. That way, there is no need to argue about design decisions that impact uses that are out of scope. As a result, I would hope that progress would be sped up. On 06/01/2011 5:23 PM, John Tamplin wrote: > On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton > wrote: > > So far it appears that Greg, Brodie, Jerod, and I favour including > peer-to-peer design considerations in the spec. I am not sure, but > it sounds like John considers it out of scope and Scott considers > it in scope. What about the rest of you? > > > I am not opposed to it exactly, but given how long everything has > taken I am keen to keep the base protocol minimal so we can actually > get something out the door. > > Just like when we were discussing compression, multiplexing, and > metadata during the design of the basic framing, we weren't getting > anywhere until we stripped it down to the minimum. To overcome > objections about stripping out too much, I wrote up examples of how > the base framing could be extended in a compatible fashion to > incorporate those use-cases and we were able to agree on the base framing. > > If you think peer-to-peer WebSockets is important, I suggest talking > about specific things that need to be represented in the base protocol > in order to allow that be added at a later time. So far the > suggestion has been that masking is mandatory and an extension could > be defined in the future to remove it has been met > with skepticism that people who build infrastructure pieces will build > in that extensibility (if I am mis-stating the objections, please > correct me). I'm not sure this is any different than the > compression/mux/metadata cases we already dealt with, and my feeling > is if such equipment has to be upgraded later to support new things so > be it. I personally am fine with adding language into the spec saying > what things are expected to be changed so implementors should be > prepared to update the handling if that helps address the concern. > However, I am really loathe to try and define peer-to-peer operation > in the base spec because I think it will unreasonably extend the > process of getting the base protocol out the door. > > -- > John A. Tamplin > Software Engineer (GWT), Google --------------070307040003060102050108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I am not talking about designing the specifics of peer to peer into the protocol. I am talking about everybody being clear on what they are designing. The question about peer to peer is just one of several in that vein. Perhaps you think that everybody is in agreement in their vision of Websockets, but it sure doesn't look that way to me, and I think that is where some of the polarization is coming from.

If everyone agrees that design decisions should be based only on browser-server interaction, then there is no need to talk about optional masking. If peer to peer is out of scope, then there is no need to worry about the asymmetry of the client and server. Suddenly progress can be made much more easily because a lot of objections will simply disappear. When you introduce intermediaries it can get more complicated, depending on what you decide is in scope. Greg's muxer probably is. Willy's WS Accelerator and my usecases with servers acting as clients, perhaps or perhaps not. Which ones you include for consideration are going to have an impact on what issues should be given weight when designing the protocol.

Correct me if I am wrong, but my understanding from what you have written is that you are principally concerned with browser to server interactions, and other scenarios that happen to work out are fine with you but need not be designed for. So it makes sense that you don't see a particular need for optional masking or have much concern about clients masking their frames and servers not. This view of the protocol is going to inform many more of your decisions as they come up.

But it is clear from Greg's description that he has a very different vision of where he sees Websockets being used. You are designing a screwdriver and he is designing a drill that can hold screwdriver bits. Both are useful tools, but the trade-offs for each are going to be different.

So all I'm suggesting is that you all clarify among yourselves what is in scope and what is not. That way, there is no need to argue about design decisions that impact uses that are out of scope. As a result, I would hope that progress would be sped up.

On 06/01/2011 5:23 PM, John Tamplin wrote:
On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton <bruce@callenish.com> wrote:
So far it appears that Greg, Brodie, Jerod, and I favour including peer-to-peer design considerations in the spec. I am not sure, but it sounds like John considers it out of scope and Scott considers it in scope. What about the rest of you?

I am not opposed to it exactly, but given how long everything has taken I am keen to keep the base protocol minimal so we can actually get something out the door.

Just like when we were discussing compression, multiplexing, and metadata during the design of the basic framing, we weren't getting anywhere until we stripped it down to the minimum.  To overcome objections about stripping out too much, I wrote up examples of how the base framing could be extended in a compatible fashion to incorporate those use-cases and we were able to agree on the base framing.

If you think peer-to-peer WebSockets is important, I suggest talking about specific things that need to be represented in the base protocol in order to allow that be added at a later time.  So far the suggestion has been that masking is mandatory and an extension could be defined in the future to remove it has been met with skepticism that people who build infrastructure pieces will build in that extensibility (if I am mis-stating the objections, please correct me).  I'm not sure this is any different than the compression/mux/metadata cases we already dealt with, and my feeling is if such equipment has to be upgraded later to support new things so be it.  I personally am fine with adding language into the spec saying what things are expected to be changed so implementors should be prepared to update the handling if that helps address the concern.  However, I am really loathe to try and define peer-to-peer operation in the base spec because I think it will unreasonably extend the process of getting the base protocol out the door.

--
John A. Tamplin
Software Engineer (GWT), Google

--------------070307040003060102050108-- From bruce@callenish.com Thu Jan 6 19:20:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB073A6C74 for ; Thu, 6 Jan 2011 19:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSKqFbkm-U5B for ; Thu, 6 Jan 2011 19:20:56 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id C8EC33A677D for ; Thu, 6 Jan 2011 19:20:56 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pb2us-0004Zx-9m for hybi@ietf.org; Thu, 06 Jan 2011 19:23:02 -0800 Message-ID: <4D26871C.80000@callenish.com> Date: Thu, 06 Jan 2011 19:23:08 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <4D26605B.1090409@callenish.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070105050500090406040507" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 03:20:58 -0000 This is a multi-part message in MIME format. --------------070105050500090406040507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the reference, Gabriel. That is very helpful. In that case, I won't raise any more issues about design that impacts peer to peer scenarios. On 06/01/2011 5:44 PM, Gabriel Montenegro wrote: > > John Tamplin wrote: > *…* However, I am really loathe to try and define peer-to-peer > operation in the base spec because I think it will unreasonably extend > the process of getting the base protocol out the door. > > */[gab] /*I agree. WGs are typically chartered with a specific focus > in order to ease progress. The charter as approved by the IESG > includes this: > > The Hypertext-Bidirectional (HyBi) working group will seek > > standardization of one approach to maintain bidirectional > > communications between the HTTP client, server and intermediate > > entities, which will provide more efficiency compared to the current > > use of hanging requests. > > This prominently talks about client-server not peer-to-peer. When > people have asked me if p2p is in scope, I’ve always answered “no, by > charter†as that is how I’ve interpreted the above. Given the > difficulties in this group, I agree that is best left after we deliver > on the current items. We can then tackle a re-chartering operation and > move on to other efforts, but for now I think that is not only out of > scope, but would delay us even further. > --------------070105050500090406040507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Thanks for the reference, Gabriel. That is very helpful. In that case, I won't raise any more issues about design that impacts peer to peer scenarios.

On 06/01/2011 5:44 PM, Gabriel Montenegro wrote:

 

John Tamplin wrote:
…  However, I am really loathe to try and define peer-to-peer operation in the base spec because I think it will unreasonably extend the process of getting the base protocol out the door.

 

[gab] I agree. WGs are typically chartered with a specific focus in order to ease progress. The charter as approved by the IESG includes this:

  The Hypertext-Bidirectional (HyBi) working group will seek

  standardization of one approach to maintain bidirectional

  communications between the HTTP client, server and intermediate

  entities, which will provide more efficiency compared to the current

  use of hanging requests.

 

 

This prominently talks about client-server not peer-to-peer.  When people have asked me if p2p is in scope, I’ve always answered “no, by charter†as that is how I’ve interpreted the above. Given the difficulties in this group, I agree that is best left after we deliver on the current items. We can then tackle a re-chartering operation and move on to other efforts, but for now I think that is not only out of scope, but would delay us even further.


--------------070105050500090406040507-- From w@1wt.eu Thu Jan 6 21:32:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6603A6403 for ; Thu, 6 Jan 2011 21:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vRKLwxLkqby for ; Thu, 6 Jan 2011 21:32:08 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 0495C3A63D2 for ; Thu, 6 Jan 2011 21:32:07 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p075YACg030615; Fri, 7 Jan 2011 06:34:10 +0100 Date: Fri, 7 Jan 2011 06:34:10 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110107053410.GG28367@1wt.eu> References: <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 05:32:11 -0000 On Thu, Jan 06, 2011 at 03:37:26PM -0800, Eric Rescorla wrote: > My bad, I misunderstood the context: > > 1. Yes, I think you should generate completely fresh keystream for each > record. > 2. We had originally talked about using AES-CTR for this, but it's possible > that for export reasons people might prefer HMAC-SHA1. OK, I get it now. > This isn't some piece of new complexity: it's been part of the proposed > masking > since the very beginning. The only difference is that HMAC-SHA1 is being > suggested as > an AES-CTR replacement. I realize that you don't think this is necessary, > and I guess > I might be willing to live with a simpler mechanism, but it's not, as you > suggest, something > that just appeared when we were starting to make progress. OK. My concern is that it comes with a cost. I know a large site who is dealing with hundreds of thousands of concurrent chat connections. They're dealing with very small messages, a few bytes of payload at a time at best. You can certainly imagine the load on the servers if they have to compute an HMAC every two-three character typed on the keyboard! I understood your point with the random keys as a way to prevent the server from making the client emit predictable data. In my opinion, if the client generates the random key on its side without depending on anything and simply announces it, we can achieve the same result. We can *suggest* methods to help the client generate a random when it does not know how to do so, but I don't see a reason why it should depend on multiple parameters. Also the key does not need to be larger than the number of bytes to encode a frame length (7, 16, 63 bits), because what's important is that a message cannot span the entire keyspace. In theory, a simple 8-bit random could be enough for a message with a payload shorter than 128 bytes. However, having a variable length mask would only work if it's sent in the extension field, but that's probably something to think about. I would very well see something like this for the client : - generate a random of 8, 16 or 64 bits depending on the payload length. The larger ones should be strong enough and may involve hashing to avoid predictability. - announce the random in the extension data - XOR the application data with that random We could even make use of the RSV4 bit to indicate that the frame is encoded. It will result in all easily controllable bytes before the key to have the high bit set and would make it easy for the other side to decode the frames, because by design the key would be the same size as the payload length field. Regards, Willy From jat@google.com Thu Jan 6 21:39:33 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1DD73A677C for ; Thu, 6 Jan 2011 21:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.446 X-Spam-Level: X-Spam-Status: No, score=-104.446 tagged_above=-999 required=5 tests=[AWL=-2.469, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynzulToBKlKJ for ; Thu, 6 Jan 2011 21:39:33 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id CF6113A6405 for ; Thu, 6 Jan 2011 21:39:23 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p075fQbf006421 for ; Thu, 6 Jan 2011 21:41:27 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294378889; bh=wy7tJz+QyUBRywhHclc68Yqb4CA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=NDts8gldrqspV5ZEq3TtHSyPDlmMCSx1wYe9ov2AdyvVBedgDC+eErOXQ/xTUU7+o pqfpTGL0OKa6Wa3Z0/HxQ== Received: from gwaa18 (gwaa18.prod.google.com [10.200.27.18]) by kpbe12.cbf.corp.google.com with ESMTP id p075fPHY027932 for ; Thu, 6 Jan 2011 21:41:25 -0800 Received: by gwaa18 with SMTP id a18so8477921gwa.24 for ; Thu, 06 Jan 2011 21:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=U2hIgF4h1aZCp5M2o1NaqjQfm8yhZ+k4iIXJCa5pEcc=; b=mwE7nWSGG4nrOGPRLMNNeow2ZOeDMy1kCazM19JEtI7eR7GZ+V7LS3HZ0HXPgS/SkH fZ28o4IFAOevdRDDJ4nQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=qeLX72/Myb9orn6BQKiCzU5OuetaOPgWsLXeTo/QUke9WTUQxmYTROqTflRCtx3Cdc czr0zQIdF6yd4crmJoKw== Received: by 10.150.228.1 with SMTP id a1mr7754582ybh.434.1294378884969; Thu, 06 Jan 2011 21:41:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Thu, 6 Jan 2011 21:41:02 -0800 (PST) In-Reply-To: <4D268644.9040800@callenish.com> References: <4D26605B.1090409@callenish.com> <4D268644.9040800@callenish.com> From: John Tamplin Date: Fri, 7 Jan 2011 00:41:02 -0500 Message-ID: To: Bruce Atherton Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 05:39:34 -0000 On Thu, Jan 6, 2011 at 10:19 PM, Bruce Atherton wrote: > Correct me if I am wrong, but my understanding from what you have written is > that you are principally concerned with browser to server interactions, and > other scenarios that happen to work out are fine with you but need not be > designed for. So it makes sense that you don't see a particular need for > optional masking or have much concern about clients masking their frames and > servers not. This view of the protocol is going to inform many more of your > decisions as they come up. Mostly what I care about are achieving consensus and getting WebSockets deployed. I am not opposed to leaving extension hooks for other things if that helps us get consensus. > But it is clear from Greg's description that he has a very different vision > of where he sees Websockets being used. You are designing a screwdriver and > he is designing a drill that can hold screwdriver bits. Both are useful > tools, but the trade-offs for each are going to be different. As mentioned, there are some particular "bits" I want to add to the screwdriver later such as multiplexing and compression, and I made sure that the base screwdriver could be extended for those bits later. However, I don't want to have to design and get consensus on all those other bits now -- I just want to ship the screwdriver and one bit, and then we can worry about designing the other bits for it. -- John A. Tamplin Software Engineer (GWT), Google From ekr@rtfm.com Thu Jan 6 21:45:25 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A6B3A679C for ; Thu, 6 Jan 2011 21:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh9wWhFebaQO for ; Thu, 6 Jan 2011 21:45:24 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 808AA3A6784 for ; Thu, 6 Jan 2011 21:45:24 -0800 (PST) Received: by yxt33 with SMTP id 33so7533345yxt.31 for ; Thu, 06 Jan 2011 21:47:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.26.24 with SMTP id d24mr2881170agj.160.1294379250977; Thu, 06 Jan 2011 21:47:30 -0800 (PST) Received: by 10.90.154.19 with HTTP; Thu, 6 Jan 2011 21:47:30 -0800 (PST) In-Reply-To: <20110107053410.GG28367@1wt.eu> References: <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> Date: Thu, 6 Jan 2011 21:47:30 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=001485f9a68c758c4b04993b2750 Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 05:45:25 -0000 --001485f9a68c758c4b04993b2750 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 9:34 PM, Willy Tarreau wrote: > On Thu, Jan 06, 2011 at 03:37:26PM -0800, Eric Rescorla wrote: > > This isn't some piece of new complexity: it's been part of the proposed > > masking > > since the very beginning. The only difference is that HMAC-SHA1 is being > > suggested as > > an AES-CTR replacement. I realize that you don't think this is necessary, > > and I guess > > I might be willing to live with a simpler mechanism, but it's not, as you > > suggest, something > > that just appeared when we were starting to make progress. > > OK. My concern is that it comes with a cost. I know a large site who is > dealing with hundreds of thousands of concurrent chat connections. They're > dealing with very small messages, a few bytes of payload at a time at best. > You can certainly imagine the load on the servers if they have to compute > an HMAC every two-three character typed on the keyboard! Really? That's not the behavior I'm familar of with chat systems, where things are generally phrased in stanzas that are > 20 bytes longs. This is true of XMPP, for instance. What systems are you thinking of? That said, even if you have such a system, I'm not at particularly concerned about the load being prohibitive. Symmetric encryption is very fast (see Langley and Modadugu's velocity talk for reference on this). > Also the key does not need to be larger than the number of bytes to encode > a frame length (7, 16, 63 bits), because what's important is that a message > cannot span the entire keyspace. I don't know where you're getting this analysis, but it doesn't sound correct to me. The probability of guessing a valid key is 2^{-key size}. The liit you're talking about only applies if you want to be guaranteed you have a valid plaintext within a single frame. Even if you have a much larger mask, if you simply repeat it, there will be correlations with the mark when it repeats. I'm not aware of any attack on this, but it's also not demonstrably safe, whereas the technique I described is. -Ekr --001485f9a68c758c4b04993b2750 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 6, 2011 at 9:34 PM, Willy Ta= rreau <w@1wt.eu> wrote:
On Thu, Jan 06, 2011 at 03:37:26PM -0800, Eric Rescorla w= rote:
> This isn't some piece of new complexity: it's been part of the= proposed
> masking
> since the very beginning. The only difference is that HMAC-SHA1 is bei= ng
> suggested as
> an AES-CTR replacement. I realize that you don't think this is nec= essary,
> and I guess
> I might be willing to live with a simpler mechanism, but it's not,= as you
> suggest, something
> that just appeared when we were starting to make progress.

OK. My concern is that it comes with a cost. I know a large site who = is
dealing with hundreds of thousands of concurrent chat connections. They'= ;re
dealing with very small messages, a few bytes of payload at a time at best.=
You can certainly imagine the load on the servers if they have to compute an HMAC every two-three character typed on the keyboard!
<= br>
Really? That's not the behavior I'm familar of with c= hat systems, where things
are generally phrased in stanzas that a= re > 20 bytes longs. This is true of
XMPP, for instance. What systems are you thinking of?

That said, even if you have such a system, I'm not at particul= arly concerned about the
load being prohibitive. Symmetric encryp= tion is very fast (see Langley and Modadugu's
velocity talk for reference on this).


=A0
Also the key does not need to be larger than the number of bytes to encode<= br> a frame length (7, 16, 63 bits), because what's important is that a mes= sage
cannot span the entire keyspace.

I don'= ;t know where you're getting this analysis, but it doesn't sound co= rrect
to me. The probability of guessing a valid key is 2^{-key s= ize}. The liit
you're talking about only applies if you want to be guaranteed you= have
a valid plaintext within a single frame.

Even if you have a much larger mask, if you simply repeat it, there = will be
correlations with the mark when it repeats. I'm not aware of any a= ttack on this,
but it's also not demonstrably safe, whereas t= he technique I described is.

-Ekr

--001485f9a68c758c4b04993b2750-- From Martin.Thomson@andrew.com Thu Jan 6 21:46:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5893A679C for ; Thu, 6 Jan 2011 21:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lXYzuhralzt for ; Thu, 6 Jan 2011 21:46:27 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id BBB7C3A6784 for ; Thu, 6 Jan 2011 21:46:27 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:37238 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S41059068Ab1AGFse (ORCPT ); Thu, 6 Jan 2011 23:48:34 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 6 Jan 2011 23:48:34 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 7 Jan 2011 13:48:29 +0800 From: "Thomson, Martin" To: Willy Tarreau , Eric Rescorla Date: Fri, 7 Jan 2011 13:48:27 +0800 Thread-Topic: [hybi] A bit of pragmatism Thread-Index: AcuuLIuHzVxkZlPMTt2J7Fui/SatmgAAO3NA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5258D86@SISPE7MB1.commscope.com> References: <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> In-Reply-To: <20110107053410.GG28367@1wt.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 05:46:29 -0000 PiBBbHNvIHRoZSBrZXkgZG9lcyBub3QgbmVlZCB0byBiZSBsYXJnZXIgdGhhbiB0aGUgbnVtYmVy IG9mIGJ5dGVzIHRvDQo+IGVuY29kZQ0KPiBhIGZyYW1lIGxlbmd0aCAoNywgMTYsIDYzIGJpdHMp LCBiZWNhdXNlIHdoYXQncyBpbXBvcnRhbnQgaXMgdGhhdCBhDQo+IG1lc3NhZ2UNCj4gY2Fubm90 IHNwYW4gdGhlIGVudGlyZSBrZXlzcGFjZS4gSW4gdGhlb3J5LCBhIHNpbXBsZSA4LWJpdCByYW5k b20gY291bGQNCj4gYmUNCj4gZW5vdWdoIGZvciBhIG1lc3NhZ2Ugd2l0aCBhIHBheWxvYWQgc2hv cnRlciB0aGFuIDEyOCBieXRlcy4gSG93ZXZlciwNCj4gaGF2aW5nDQo+IGEgdmFyaWFibGUgbGVu Z3RoIG1hc2sgd291bGQgb25seSB3b3JrIGlmIGl0J3Mgc2VudCBpbiB0aGUgZXh0ZW5zaW9uDQo+ IGZpZWxkLA0KPiBidXQgdGhhdCdzIHByb2JhYmx5IHNvbWV0aGluZyB0byB0aGluayBhYm91dC4N Cj4gDQo+IEkgd291bGQgdmVyeSB3ZWxsIHNlZSBzb21ldGhpbmcgbGlrZSB0aGlzIGZvciB0aGUg Y2xpZW50IDoNCj4gICAtIGdlbmVyYXRlIGEgcmFuZG9tIG9mIDgsIDE2IG9yIDY0IGJpdHMgZGVw ZW5kaW5nIG9uIHRoZSBwYXlsb2FkDQo+ICAgICBsZW5ndGguIA0KDQpJIGRvbid0IHRoaW5rIHRo YXQgdGhpcyBsb2dpYyB3b3Jrcy4gIFRoZSByZWFzb24gZm9yIGhhdmluZyBtb3JlIHJhbmRvbW5l c3MgaXMgdG8gcmVkdWNlIHRoZSBwcm9iYWJpbGl0eSB0aGF0IHRoZSBzZXJ2ZXIgaXMgYWJsZSB0 byBndWVzcyB0aGUgcmFuZG9tIHZhbHVlLiAgWW91IGhhdmUgbGVzcyByYW5kb21uZXNzIGJlY2F1 c2UgeW91IHdhbnQgdG8gc2F2ZSBieXRlcy4gIA0KDQpUaGlzIGlzIG5vdCBhYm91dCByZWR1Y2lu ZyB0aGUgcHJvYmFiaWxpdHkgb2YgdGhlIGNsaWVudCBlbWl0dGluZyBkYXRhIHRoYXQgY291bGQg YmUgbWlzdW5kZXJzdG9vZCAtIHRoYXQgaXMgYSBmdW5jdGlvbiBvZiB0aGUgbGVuZ3RoIG9mIHRo ZSBtZXNzYWdlLCBpbmRlcGVuZGVudCBvZiB0aGUgYW1vdW50IG9mIHJhbmRvbW5lc3MgeW91IGFy ZSBwcm92aWRpbmcuICBBZGRpbmcgbW9yZSByYW5kb21uZXNzIGRvZXNuJ3QgcmVkdWNlIHRoZSBj aGFuY2Ugb2YgYSBtZXNzYWdlIGNvbnRhaW5pbmcgIkdFVCAvIEhUVFAvMS4xIiBvciBhbnkgb3Ro ZXIgc3VjaCBwb3RlbnRpYWxseSBkYW5nZXJvdXMgc3R1ZmYsIHlvdSBjYW4gb25seSBkbyB0aGF0 IGJ5IHNlbmRpbmcgbGVzcyBkYXRhLg0KDQo+ICAgICBUaGUgbGFyZ2VyIG9uZXMgc2hvdWxkIGJl IHN0cm9uZyBlbm91Z2ggYW5kIG1heSBpbnZvbHZlDQo+ICAgICBoYXNoaW5nIHRvIGF2b2lkIHBy ZWRpY3RhYmlsaXR5Lg0KDQpZb3Ugd2FudCBhIHNlY3VyZSByYW5kb20gbnVtYmVyIGdlbmVyYXRv ciBpZiB5b3VyIGdvYWwgaXMgdG8gYXZvaWQgc29tZW9uZSBwcmVkaWN0aW5nIHRoZSBvdXRjb21l IHNlZSBbUkZDNDA4Nl0uDQogDQo+ICAgLSBhbm5vdW5jZSB0aGUgcmFuZG9tIGluIHRoZSBleHRl bnNpb24gZGF0YQ0KPiANCj4gICAtIFhPUiB0aGUgYXBwbGljYXRpb24gZGF0YSB3aXRoIHRoYXQg cmFuZG9tDQoNClRoYXQgd291bGQgYmUgc3VmZmljaWVudCwganVzdCBkZWNpZGUgaG93IG11Y2gg cmFuZG9tbmVzcyBpcyBzdWZmaWNpZW50LiAgQSBmaXhlZCB2YWx1ZSBzaG91bGQgYmUgc3VmZmlj aWVudCwgYW5kIHdlIHNob3VsZCBiZSBhYmxlIHRvIGNvbWUgdXAgd2l0aCBhIHByb2JhYmlsaXR5 IHdlIGNhbiBhbGwgYWdyZWUgb24uDQoNCi0tTWFydGluDQo= From w@1wt.eu Thu Jan 6 21:50:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2B13A6407 for ; Thu, 6 Jan 2011 21:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TCEmx6odFzL for ; Thu, 6 Jan 2011 21:50:41 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id EB0AC3A6403 for ; Thu, 6 Jan 2011 21:50:40 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p075qiEc030682; Fri, 7 Jan 2011 06:52:44 +0100 Date: Fri, 7 Jan 2011 06:52:44 +0100 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20110107055244.GH28367@1wt.eu> References: <4D17B5FF.5060209@callenish.com> <41249E48-B17E-47C7-9340-6F95B85182CD@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41249E48-B17E-47C7-9340-6F95B85182CD@apple.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 05:50:42 -0000 On Mon, Dec 27, 2010 at 04:30:43PM -0800, Maciej Stachowiak wrote: > > But I'm strongly against masking the framing itself. Their is > > absolutely no reason for it other than to prevent the possibility of > > making it optional. > > That's not right. One reason for masking the framing is to make it impossible for hostile browser-hosted hosted code to pre-generate valid-looking frames. If you don't mask framing, then it is trivial to create valid-looking frames, even if the contents are scrambled. Depending on circumstances, this could still be a dangerous attack on integrity. No Maciej, it's not "trivial" to do that because if you look at the framing, very little of it is directly controlled by the application. As I suggested in another mail, if you use RSV4 to indicate masking is used and put the random key in extension data, that leaves you with : - first byte with MORE|RSV1|RSV2|RSV3|OPCODE = 1|XXX|OPCODE - second byte with RSV4|LENGTH = 1|LENGTH - 3rd-4th bytes corresponding to the low part of the payload length, only if previous byte is 0xFE/0xFF - 5-10th bytes corresponding to the high part of the payload length only if 2nd byte is 0xFF - random key the size of the payload length - application data The only controllable part here in which you might put an HTTP request is the key length. But even in order to write an HTTP/0.9 "GET /\n", you have to forge a message that is 0x54202F0A4745 bytes long, or 92 TeraBytes long. And if you need to start it at the beginning of a line, it becomes 0x4554202F0A0A47 which is 19 PetaBytes. By the time we get browsers able to construct that large messages, we won't bother anymore about the broken intermediaries. That's why I'm really considering masking the payload safe enough with regards to the risk we're trying to cover. Regards, Willy From Martin.Thomson@andrew.com Thu Jan 6 21:53:31 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DEA3A6407 for ; Thu, 6 Jan 2011 21:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crRFSPY0a5ul for ; Thu, 6 Jan 2011 21:53:30 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 58FB83A679C for ; Thu, 6 Jan 2011 21:53:30 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:31282 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S41059076Ab1AGFzh (ORCPT ); Thu, 6 Jan 2011 23:55:37 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 6 Jan 2011 23:55:36 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 7 Jan 2011 13:55:32 +0800 From: "Thomson, Martin" To: Eric Rescorla , Willy Tarreau Date: Fri, 7 Jan 2011 13:55:29 +0800 Thread-Topic: [hybi] A bit of pragmatism Thread-Index: AcuuLmqJVgrMk6q3Q5+x1cJVSRMmhAAAD4dg Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5258D8C@SISPE7MB1.commscope.com> References: <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 05:53:31 -0000 T24gMjAxMS0wMS0wNyBhdCAxNjo0NzozMCwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4gSSBkb24n dCBrbm93IHdoZXJlIHlvdSdyZSBnZXR0aW5nIHRoaXMgYW5hbHlzaXMsIGJ1dCBpdCBkb2Vzbid0 IHNvdW5kDQo+IGNvcnJlY3QNCj4gdG8gbWUuIFRoZSBwcm9iYWJpbGl0eSBvZiBndWVzc2luZyBh IHZhbGlkIGtleSBpcyAyXnsta2V5IHNpemV9LiBUaGUNCj4gbGlpdA0KPiB5b3UncmUgdGFsa2lu ZyBhYm91dCBvbmx5IGFwcGxpZXMgaWYgeW91IHdhbnQgdG8gYmUgZ3VhcmFudGVlZCB5b3UgaGF2 ZQ0KPiBhIHZhbGlkIHBsYWludGV4dCB3aXRoaW4gYSBzaW5nbGUgZnJhbWUuDQo+IA0KPiBFdmVu IGlmIHlvdSBoYXZlIGEgbXVjaCBsYXJnZXIgbWFzaywgaWYgeW91IHNpbXBseSByZXBlYXQgaXQs IHRoZXJlDQo+IHdpbGwgYmUNCj4gY29ycmVsYXRpb25zIHdpdGggdGhlIG1hcmsgd2hlbiBpdCBy ZXBlYXRzLiBJJ20gbm90IGF3YXJlIG9mIGFueSBhdHRhY2sNCj4gb24gdGhpcywNCj4gYnV0IGl0 J3MgYWxzbyBub3QgZGVtb25zdHJhYmx5IHNhZmUsIHdoZXJlYXMgdGhlIHRlY2huaXF1ZSBJIGRl c2NyaWJlZA0KPiBpcy4NCg0KRGVwZW5kcyBvbiB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIHByZXZl bnQuICBBcyBJIHVuZGVyc3RhbmQgaXQsIHlvdSBhcmUgdHJ5aW5nIHRvIHByZXZlbnQgdW50cnVz dGVkIGNvZGUgZnJvbSBiZWluZyBhYmxlIHRvIGRpcmVjdGx5IGNvbnRyb2wgd2hhdCBpcyBvbiB0 aGUgd2lyZS4gIFJlcGVhdGluZyB0aGUgbWFzayBpcyBzdGlsbCBzdWZmaWNpZW50OiAyXi1rIHBy b2JhYmlsaXR5LiAgSXQncyBub3QgbGlrZSB0aGUgc2VydmVyIGlzbid0IGdvaW5nIHRvIGhhdmUg dGhlIHZhbHVlLg0KDQpXZSBoYXZlIHRvIGFzc3VtZSB0aGF0IG9uY2UgdGhlIHNlcnZlciBzdGFy dHMgcmVjZWl2aW5nIGEgZnJhbWUgaXQgY2FuIHRlbGwgdGhlIHVudHJ1c3RlZCBjb2RlIHdoYXQg dGhlIG1hc2sgaXMuICBBRVMtQ1RSIGFuZCBITUFDIGJvdGggb25seSBpbmNyZWFzZSB0aGUgY29z dCBvZiBwcmVkaWN0aW9uIGF0IHRoYXQgcG9pbnQuICBZb3UgaGF2ZSB0byBwcmV2ZW50IHRoZSBz ZXJ2ZXIgZnJvbSBiZWluZyBhYmxlIHRvIGNsb3NlIHRoZSBsb29wIGJ5IG1ha2luZyBzdXJlIHRo YXQgeW91IGhhdmUgYWxsIHRoZSBkYXRhIGZvciBhIGZyYW1lIGJlZm9yZSB5b3Ugc3RhcnQgc2Vu ZGluZy4NCg0KLS1NYXJ0aW4NCg0KDQo= From ekr@rtfm.com Thu Jan 6 21:57:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF57E3A67A6 for ; Thu, 6 Jan 2011 21:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.305 X-Spam-Level: X-Spam-Status: No, score=-102.305 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaqY4uLSG8n7 for ; Thu, 6 Jan 2011 21:57:49 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id B906D3A67A4 for ; Thu, 6 Jan 2011 21:57:49 -0800 (PST) Received: by gxk28 with SMTP id 28so7920728gxk.31 for ; Thu, 06 Jan 2011 21:59:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.83.18 with SMTP id k18mr2829905agl.79.1294379996401; Thu, 06 Jan 2011 21:59:56 -0800 (PST) Received: by 10.90.154.19 with HTTP; Thu, 6 Jan 2011 21:59:56 -0800 (PST) In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F5258D8C@SISPE7MB1.commscope.com> References: <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258D8C@SISPE7MB1.commscope.com> Date: Thu, 6 Jan 2011 21:59:56 -0800 Message-ID: From: Eric Rescorla To: "Thomson, Martin" Content-Type: multipart/alternative; boundary=0016e6407c64e3d21404993b530b Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 05:57:51 -0000 --0016e6407c64e3d21404993b530b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 9:55 PM, Thomson, Martin wrote: > On 2011-01-07 at 16:47:30, Eric Rescorla wrote: > > I don't know where you're getting this analysis, but it doesn't sound > > correct > > to me. The probability of guessing a valid key is 2^{-key size}. The > > liit > > you're talking about only applies if you want to be guaranteed you have > > a valid plaintext within a single frame. > > > > Even if you have a much larger mask, if you simply repeat it, there > > will be > > correlations with the mark when it repeats. I'm not aware of any attack > > on this, > > but it's also not demonstrably safe, whereas the technique I described > > is. > > Depends on what you are trying to prevent. As I understand it, you are > trying to prevent untrusted code from being able to directly control what is > on the wire. Repeating the mask is still sufficient: 2^-k probability. > It's not like the server isn't going to have the value. With a repeating mask, the attacker can (for instance) ensure that byte i is the same as byte i+masklen, regardless of the mask value. As I said, I don't know how to exploit this, but I also have yet to see a demonstration that it's not exploitable. -Ekr --0016e6407c64e3d21404993b530b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 6, 2011 at 9:55 PM, Thomson,= Martin <= Martin.Thomson@andrew.com> wrote:
On 2011-01-07 at 16:47:30, Eric Rescorla wrote:
> I don't know where you're getting this analysis, but it doesn&= #39;t sound
> correct
> to me. The probability of guessing a valid key is 2^{-key size}. The > liit
> you're talking about only applies if you want to be guaranteed you= have
> a valid plaintext within a single frame.
>
> Even if you have a much larger mask, if you simply repeat it, there > will be
> correlations with the mark when it repeats. I'm not aware of any a= ttack
> on this,
> but it's also not demonstrably safe, whereas the technique I descr= ibed
> is.

Depends on what you are trying to prevent. =A0As I understand it, you= are trying to prevent untrusted code from being able to directly control w= hat is on the wire. =A0Repeating the mask is still sufficient: 2^-k probabi= lity. =A0It's not like the server isn't going to have the value.

With=A0a repeating mask, the attacker can (for instance= ) ensure=A0that byte i is the same
as byte i+masklen, regardless = of the mask value. As I said, I don't know how to exploit
thi= s, but I also have yet to see a demonstration that it's not exploitable= .

=A0-Ekr


--0016e6407c64e3d21404993b530b-- From w@1wt.eu Thu Jan 6 21:59:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58A43A67B5 for ; Thu, 6 Jan 2011 21:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSpj4p1vJriZ for ; Thu, 6 Jan 2011 21:59:24 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 75B0F3A67B4 for ; Thu, 6 Jan 2011 21:59:23 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0761Smr030723; Fri, 7 Jan 2011 07:01:28 +0100 Date: Fri, 7 Jan 2011 07:01:28 +0100 From: Willy Tarreau To: "Thomson, Martin" Message-ID: <20110107060128.GI28367@1wt.eu> References: <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258D86@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F5258D86@SISPE7MB1.commscope.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 05:59:24 -0000 On Fri, Jan 07, 2011 at 01:48:27PM +0800, Thomson, Martin wrote: > > Also the key does not need to be larger than the number of bytes to > > encode > > a frame length (7, 16, 63 bits), because what's important is that a > > message > > cannot span the entire keyspace. In theory, a simple 8-bit random could > > be > > enough for a message with a payload shorter than 128 bytes. However, > > having > > a variable length mask would only work if it's sent in the extension > > field, > > but that's probably something to think about. > > > > I would very well see something like this for the client : > > - generate a random of 8, 16 or 64 bits depending on the payload > > length. > > I don't think that this logic works. The reason for having more randomness is to reduce the probability that the server is able to guess the random value. You have less randomness because you want to save bytes. No, the randomness I'm talking about is to reduce the probability that the server will guess the key and exploit it. If the key is changed for each frame, the ability for the server to guess *and exploit* it depends on the message length too. The server does not have more chance to forge a correct message when it has 1/256 change to guess the key on a message that's 256 bytes long than when it has 1/65536 on a message that's 65536 bytes long. That said, we could probably have the minimum random size something like 32 bits for small payloads, it's not a big deal if the masking is optional. Regards, Willy From Martin.Thomson@andrew.com Thu Jan 6 22:00:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AF93A67B0 for ; Thu, 6 Jan 2011 22:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N42vlzjUlZHk for ; Thu, 6 Jan 2011 22:00:23 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 9DC143A67AE for ; Thu, 6 Jan 2011 22:00:22 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:62326 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S41059205Ab1AGGC2 (ORCPT ); Fri, 7 Jan 2011 00:02:28 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 7 Jan 2011 00:02:28 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 7 Jan 2011 14:02:24 +0800 From: "Thomson, Martin" To: Willy Tarreau , Maciej Stachowiak Date: Fri, 7 Jan 2011 14:02:16 +0800 Thread-Topic: [hybi] proposed masking Thread-Index: AcuuLyCC5Fg1kfcURLqObSUe7i/LjgAAPP9g Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5258D96@SISPE7MB1.commscope.com> References: <4D17B5FF.5060209@callenish.com> <41249E48-B17E-47C7-9340-6F95B85182CD@apple.com> <20110107055244.GH28367@1wt.eu> In-Reply-To: <20110107055244.GH28367@1wt.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "hybi@ietf.org" Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:00:27 -0000 T24gMjAxMS0wMS0wNyBhdCAxNjo1Mjo0NCwgV2lsbHkgVGFycmVhdSB3cm90ZToNCj4gVGhlIG9u bHkgY29udHJvbGxhYmxlIHBhcnQgaGVyZSBpbiB3aGljaCB5b3UgbWlnaHQgcHV0IGFuIEhUVFAg cmVxdWVzdA0KPiBpcw0KPiB0aGUga2V5IGxlbmd0aC4gQnV0IGV2ZW4gaW4gb3JkZXIgdG8gd3Jp dGUgYW4gSFRUUC8wLjkgIkdFVCAvXG4iLCB5b3UNCj4gaGF2ZQ0KPiB0byBmb3JnZSBhIG1lc3Nh Z2UgdGhhdCBpcyAweDU0MjAyRjBBNDc0NSBieXRlcyBsb25nLCBvciA5MiBUZXJhQnl0ZXMNCj4g bG9uZy4NCj4gQW5kIGlmIHlvdSBuZWVkIHRvIHN0YXJ0IGl0IGF0IHRoZSBiZWdpbm5pbmcgb2Yg YSBsaW5lLCBpdCBiZWNvbWVzDQo+IDB4NDU1NDIwMkYwQTBBNDcgd2hpY2ggaXMgMTkgUGV0YUJ5 dGVzLiBCeSB0aGUgdGltZSB3ZSBnZXQgYnJvd3NlcnMNCj4gYWJsZSB0bw0KPiBjb25zdHJ1Y3Qg dGhhdCBsYXJnZSBtZXNzYWdlcywgd2Ugd29uJ3QgYm90aGVyIGFueW1vcmUgYWJvdXQgdGhlIGJy b2tlbg0KPiBpbnRlcm1lZGlhcmllcy4NCg0KSWYgeW91IGRvbid0IGNhcmUgYWJvdXQgdGhlIG5v aXNlIGluIHRoZSBoZWFkZXIsIHlvdSBjYW4gY29uc3RydWN0IGEgcmVxdWVzdCB0aGF0IGNvbnRh aW5zIHRoYXQgNiBieXRlIG1lc3NhZ2UgaW4gdGhlIGJvZHkgYnkgc2VuZGluZyBhIG1lc3NhZ2Ug b2YgNioyXmsgYnl0ZXMgKGZvciA4IGJpdHMgb2YgcmFuZG9tIGtleSwgdGhhdCdzIG9ubHkgMS41 ayksIG5vdCBhbGxvd2luZyBmb3Igb3ZlcmxhcHBpbmcuDQoNCkFmdGVyIGFsbCB5b3UgaGF2ZSB0 byBoYXZlIHRoZSBpbml0aWFsIG5vaXNlIGJ5dGVzIGlnbm9yZWQsIHdoYXQncyBhbm90aGVyIDEw IG9yIHNvLi4uDQoNCjo6KQ0K From Martin.Thomson@andrew.com Thu Jan 6 22:02:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32A73A67B6 for ; Thu, 6 Jan 2011 22:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifEjHtYfVLPW for ; Thu, 6 Jan 2011 22:02:39 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 22B043A67AE for ; Thu, 6 Jan 2011 22:02:39 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:15226 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S532154Ab1AGGEp (ORCPT ); Fri, 7 Jan 2011 00:04:45 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 7 Jan 2011 00:04:45 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 7 Jan 2011 14:04:31 +0800 From: "Thomson, Martin" To: Eric Rescorla Date: Fri, 7 Jan 2011 14:04:27 +0800 Thread-Topic: [hybi] A bit of pragmatism Thread-Index: AcuuMDpASZwtTHz9RjKvud24HADRswAAET/w Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5258D97@SISPE7MB1.commscope.com> References: <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258D8C@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:02:40 -0000 T24gMjAxMS0wMS0wNyBhdCAxNjo1OTo1NiwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4gV2l0aCBh IHJlcGVhdGluZyBtYXNrLCB0aGUgYXR0YWNrZXIgY2FuIChmb3IgaW5zdGFuY2UpIGVuc3VyZSB0 aGF0IGJ5dGUNCj4gaSBpcyB0aGUgc2FtZQ0KPiBhcyBieXRlIGkrbWFza2xlbiwgcmVnYXJkbGVz cyBvZiB0aGUgbWFzayB2YWx1ZS4gQXMgSSBzYWlkLCBJIGRvbid0DQo+IGtub3cNCj4gaG93IHRv IGV4cGxvaXQNCj4gdGhpcywgYnV0IEkgYWxzbyBoYXZlIHlldCB0byBzZWUgYSBkZW1vbnN0cmF0 aW9uIHRoYXQgaXQncyBub3QNCj4gZXhwbG9pdGFibGUuDQoNCkknbGwgY29uY2VkZSB0aGF0LiAg SSdtIG5vdCBhd2FyZSBvZiBhbnkgcHJvdG9jb2wgdGhhdCByZWxpZXMgb24gcmVsYXRpdmUgdmFs dWVzIG9mIGJpdHMvYnl0ZXMgYXMgb3Bwb3NlZCB0byBhYnNvbHV0ZSB2YWx1ZXMsIGJ1dCB0aGVy ZSdzIGFsd2F5cyByb29tIGZvciBzdXJwcmlzZXMuDQoNCg0K From Martin.Thomson@andrew.com Thu Jan 6 22:06:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ECA23A67B4 for ; Thu, 6 Jan 2011 22:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTlctCM5Z464 for ; Thu, 6 Jan 2011 22:06:39 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 3BB9C3A67B1 for ; Thu, 6 Jan 2011 22:06:39 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:21626 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S41059250Ab1AGGIq (ORCPT ); Fri, 7 Jan 2011 00:08:46 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 7 Jan 2011 00:08:45 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 7 Jan 2011 14:08:44 +0800 From: "Thomson, Martin" To: Willy Tarreau Date: Fri, 7 Jan 2011 14:08:39 +0800 Thread-Topic: [hybi] A bit of pragmatism Thread-Index: AcuuMFV1srih1eeiSdOdvWa/+70HqwAAH3Tw Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5258D9A@SISPE7MB1.commscope.com> References: <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258D86@SISPE7MB1.commscope.com> <20110107060128.GI28367@1wt.eu> In-Reply-To: <20110107060128.GI28367@1wt.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:06:40 -0000 T24gMjAxMS0wMS0wNyBhdCAxNzowMToyOCwgV2lsbHkgVGFycmVhdSB3cm90ZToNCj4gTm8sIHRo ZSByYW5kb21uZXNzIEknbSB0YWxraW5nIGFib3V0IGlzIHRvIHJlZHVjZSB0aGUgcHJvYmFiaWxp dHkgdGhhdA0KPiB0aGUNCj4gc2VydmVyIHdpbGwgZ3Vlc3MgdGhlIGtleSBhbmQgZXhwbG9pdCBp dC4gSWYgdGhlIGtleSBpcyBjaGFuZ2VkIGZvcg0KPiBlYWNoDQo+IGZyYW1lLCB0aGUgYWJpbGl0 eSBmb3IgdGhlIHNlcnZlciB0byBndWVzcyAqYW5kIGV4cGxvaXQqIGl0IGRlcGVuZHMgb24NCj4g dGhlDQo+IG1lc3NhZ2UgbGVuZ3RoIHRvby4gVGhlIHNlcnZlciBkb2VzIG5vdCBoYXZlIG1vcmUg Y2hhbmNlIHRvIGZvcmdlIGENCj4gY29ycmVjdA0KPiBtZXNzYWdlIHdoZW4gaXQgaGFzIDEvMjU2 IGNoYW5nZSB0byBndWVzcyB0aGUga2V5IG9uIGEgbWVzc2FnZSB0aGF0J3MNCj4gMjU2DQo+IGJ5 dGVzIGxvbmcgdGhhbiB3aGVuIGl0IGhhcyAxLzY1NTM2IG9uIGEgbWVzc2FnZSB0aGF0J3MgNjU1 MzYgYnl0ZXMNCj4gbG9uZy4NCg0KWW91IG5lZWQgbW9yZSBzcGFjZSB0byBleHBsb2l0IGl0LCBz dXJlLg0KDQpCdXQgc2luY2Ugd2Ugd2VyZSB0YWxraW5nIGFib3V0IHByYWdtYXRpc20sIHdlIGhh dmUgdG8gZXhwZWN0IHRoYXQgdGhlIHByb2JhYmlsaXR5IG9mIGFuIGludGVybWVkaWFyeSBpZ25v cmluZyBub2lzZSBkZWNyZWFzZXMgYXMgdGhlIGFtb3VudCBvZiBub2lzZSBpbmNyZWFzZXMuICBZ b3UgY291bGQgYWxtb3N0IHNheSB0aGF0IHRoZSBmaXJzdCBieXRlcyBhcmUgZ29pbmcgdG8gYmUg dGhlIG1vc3QgY3J1Y2lhbC4gIEJ1dCB0aGF0IGRvZXNuJ3QgaGVscCBpZiB3ZSdyZSBoZWFkaW5n IGZvciBhbiBpcm9uY2xhZCwgcHJvdmFibGUgcHJvYmFiaWxpdHkuDQoNCg0K From w@1wt.eu Thu Jan 6 22:08:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814FE3A67B1 for ; Thu, 6 Jan 2011 22:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKIX88rSvCmZ for ; Thu, 6 Jan 2011 22:08:38 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 41E9B3A679F for ; Thu, 6 Jan 2011 22:08:38 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p076AhSp030771; Fri, 7 Jan 2011 07:10:43 +0100 Date: Fri, 7 Jan 2011 07:10:43 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110107061043.GJ28367@1wt.eu> References: <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:08:39 -0000 On Thu, Jan 06, 2011 at 09:47:30PM -0800, Eric Rescorla wrote: > On Thu, Jan 6, 2011 at 9:34 PM, Willy Tarreau wrote: > > > On Thu, Jan 06, 2011 at 03:37:26PM -0800, Eric Rescorla wrote: > > > This isn't some piece of new complexity: it's been part of the proposed > > > masking > > > since the very beginning. The only difference is that HMAC-SHA1 is being > > > suggested as > > > an AES-CTR replacement. I realize that you don't think this is necessary, > > > and I guess > > > I might be willing to live with a simpler mechanism, but it's not, as you > > > suggest, something > > > that just appeared when we were starting to make progress. > > > > OK. My concern is that it comes with a cost. I know a large site who is > > dealing with hundreds of thousands of concurrent chat connections. They're > > dealing with very small messages, a few bytes of payload at a time at best. > > You can certainly imagine the load on the servers if they have to compute > > an HMAC every two-three character typed on the keyboard! > > > Really? That's not the behavior I'm familar of with chat systems, where > things > are generally phrased in stanzas that are > 20 bytes longs. This is true of > XMPP, for instance. What systems are you thinking of? I was thinking about the short messages typed on the keyboard such as "lol" and smileys. But even if your stats indicate an average of 20 bytes, we're still smaller than the average IP+TCP header and we have to deal with one different message every few bytes of payload. That was my point. > That said, even if you have such a system, I'm not at particularly concerned > about the > load being prohibitive. Symmetric encryption is very fast (see Langley and > Modadugu's > velocity talk for reference on this). Well, at 1 million concurrent connections with a 5s think time, that's about 200k frames per second, it starts to be concerning even if it's cheap. > > Also the key does not need to be larger than the number of bytes to encode > > a frame length (7, 16, 63 bits), because what's important is that a message > > cannot span the entire keyspace. > > > I don't know where you're getting this analysis, but it doesn't sound > correct > to me. The probability of guessing a valid key is 2^{-key size}. The liit > you're talking about only applies if you want to be guaranteed you have > a valid plaintext within a single frame. That's my point. Otherwise the server has to make the client send on average 2^{key size} random messages to get what it's looking for. I agree I was wrong on one point, I assumed it meant that full-sized messages would have to be sent while this is not the case. We could make the client send lots of short messages get a valid one. But even a 32-bit minimum key size for small frames would seem far enough, don't you think ? > Even if you have a much larger mask, if you simply repeat it, there will be > correlations with the mark when it repeats. That's why I wanted to use larger masks for larger frames, in order to avoid those repetitions. > I'm not aware of any attack on > this, > but it's also not demonstrably safe, whereas the technique I described is. Regards, Willy From w@1wt.eu Thu Jan 6 22:13:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530693A67A8 for ; Thu, 6 Jan 2011 22:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LuwXT-Gwxp7 for ; Thu, 6 Jan 2011 22:13:27 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id A19113A67A5 for ; Thu, 6 Jan 2011 22:13:22 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p076FQ1o030787; Fri, 7 Jan 2011 07:15:26 +0100 Date: Fri, 7 Jan 2011 07:15:26 +0100 From: Willy Tarreau To: "Thomson, Martin" Message-ID: <20110107061525.GK28367@1wt.eu> References: <4D17B5FF.5060209@callenish.com> <41249E48-B17E-47C7-9340-6F95B85182CD@apple.com> <20110107055244.GH28367@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258D96@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F5258D96@SISPE7MB1.commscope.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:13:29 -0000 On Fri, Jan 07, 2011 at 02:02:16PM +0800, Thomson, Martin wrote: > On 2011-01-07 at 16:52:44, Willy Tarreau wrote: > > The only controllable part here in which you might put an HTTP request > > is > > the key length. But even in order to write an HTTP/0.9 "GET /\n", you > > have > > to forge a message that is 0x54202F0A4745 bytes long, or 92 TeraBytes > > long. > > And if you need to start it at the beginning of a line, it becomes > > 0x4554202F0A0A47 which is 19 PetaBytes. By the time we get browsers > > able to > > construct that large messages, we won't bother anymore about the broken > > intermediaries. > > If you don't care about the noise in the header, you can construct a request that contains that 6 byte message in the body by sending a message of 6*2^k bytes (for 8 bits of random key, that's only 1.5k), not allowing for overlapping. The 8 bit random key could not be used with 1.5k, it would be a 16 bit one, resulting in 6*2^16 => too large for this key size too, need a 63-bit one, resulting now in 6*2^63 bytes to forge the message. That was my point :-) Willy From ekr@rtfm.com Thu Jan 6 22:14:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9663A67A4 for ; Thu, 6 Jan 2011 22:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0XdPyqqUQHT for ; Thu, 6 Jan 2011 22:14:49 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 462313A679F for ; Thu, 6 Jan 2011 22:14:49 -0800 (PST) Received: by gwj17 with SMTP id 17so9167049gwj.31 for ; Thu, 06 Jan 2011 22:16:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.114.5 with SMTP id m5mr2854808agc.25.1294381015795; Thu, 06 Jan 2011 22:16:55 -0800 (PST) Received: by 10.90.154.19 with HTTP; Thu, 6 Jan 2011 22:16:55 -0800 (PST) In-Reply-To: <20110107061043.GJ28367@1wt.eu> References: <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> Date: Thu, 6 Jan 2011 22:16:55 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=0016361e84fca6882204993b90bd Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:14:51 -0000 --0016361e84fca6882204993b90bd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 10:10 PM, Willy Tarreau wrote: > On Thu, Jan 06, 2011 at 09:47:30PM -0800, Eric Rescorla wrote: > > On Thu, Jan 6, 2011 at 9:34 PM, Willy Tarreau wrote: > > > > > On Thu, Jan 06, 2011 at 03:37:26PM -0800, Eric Rescorla wrote: > > > > This isn't some piece of new complexity: it's been part of the > proposed > > > > masking > > > > since the very beginning. The only difference is that HMAC-SHA1 is > being > > > > suggested as > > > > an AES-CTR replacement. I realize that you don't think this is > necessary, > > > > and I guess > > > > I might be willing to live with a simpler mechanism, but it's not, as > you > > > > suggest, something > > > > that just appeared when we were starting to make progress. > > > > > > OK. My concern is that it comes with a cost. I know a large site who is > > > dealing with hundreds of thousands of concurrent chat connections. > They're > > > dealing with very small messages, a few bytes of payload at a time at > best. > > > You can certainly imagine the load on the servers if they have to > compute > > > an HMAC every two-three character typed on the keyboard! > > > > > > Really? That's not the behavior I'm familar of with chat systems, where > > things > > are generally phrased in stanzas that are > 20 bytes longs. This is true > of > > XMPP, for instance. What systems are you thinking of? > > I was thinking about the short messages typed on the keyboard such as "lol" > and smileys. But even if your stats indicate an average of 20 bytes, we're > still smaller than the average IP+TCP header and we have to deal with one > different message every few bytes of payload. That was my point. Yes, and the performance will be comparable to TLS. > > That said, even if you have such a system, I'm not at particularly > concerned > > about the > > load being prohibitive. Symmetric encryption is very fast (see Langley > and > > Modadugu's > > velocity talk for reference on this). > > Well, at 1 million concurrent connections with a 5s think time, that's > about > 200k frames per second, it starts to be concerning even if it's cheap. My dinky Macbook Air does one million SHA-1 ops/second on a single core. Again, see the Modadugu and Langley talk for real performance numbers. > > > I don't know where you're getting this analysis, but it doesn't sound > > correct > > to me. The probability of guessing a valid key is 2^{-key size}. The liit > > you're talking about only applies if you want to be guaranteed you have > > a valid plaintext within a single frame. > > That's my point. Otherwise the server has to make the client send on > average > 2^{key size} random messages to get what it's looking for. So? I have no idea why you think this is acceptable. But even a 32-bit minimum key size for small frames would seem far enough, > don't you think ? No. -Ekr --0016361e84fca6882204993b90bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 6, 2011 at 10:10 PM, Willy T= arreau <w@1wt.eu> wrote:
On Thu, Jan 06, 2011 at 09:47:30PM -0800, Eric Rescorla w= rote:
> On Thu, Jan 6, 2011 at 9:34 PM, Willy Tarreau <w@1wt.eu> wrote:
>
> > On Thu, Jan 06, 2011 at 03:37:26PM -0800, Eric Rescorla wrote: > > > This isn't some piece of new complexity: it's been p= art of the proposed
> > > masking
> > > since the very beginning. The only difference is that HMAC-S= HA1 is being
> > > suggested as
> > > an AES-CTR replacement. I realize that you don't think t= his is necessary,
> > > and I guess
> > > I might be willing to live with a simpler mechanism, but it&= #39;s not, as you
> > > suggest, something
> > > that just appeared when we were starting to make progress. > >
> > OK. My concern is that it comes with a cost. I know a large site = who is
> > dealing with hundreds of thousands of concurrent chat connections= . They're
> > dealing with very small messages, a few bytes of payload at a tim= e at best.
> > You can certainly imagine the load on the servers if they have to= compute
> > an HMAC every two-three character typed on the keyboard!
>
>
> Really? That's not the behavior I'm familar of with chat syste= ms, where
> things
> are generally phrased in stanzas that are > 20 bytes longs. This is= true of
> XMPP, for instance. What systems are you thinking of?

I was thinking about the short messages typed on the keyboard such as= "lol"
and smileys. But even if your stats indicate an average of 20 bytes, we'= ;re
still smaller than the average IP+TCP header and we have to deal with one different message every few bytes of payload. That was my point.

Yes, and the performance will be comparable to TLS.

=A0
> That said, even if you have such a system, I'm not at particularly= concerned
> about the
> load being prohibitive. Symmetric encryption is very fast (see Langley= and
> Modadugu's
> velocity talk for reference on this).

Well, at 1 million concurrent connections with a 5s think time, that&= #39;s about
200k frames per second, it starts to be concerning even if it's cheap.<= /blockquote>

My dinky Macbook Air does one million SHA-1= ops/second on a single core.

Again, see the Modad= ugu and Langley talk for real performance numbers.

=A0

> I don't know where you're getting this analysis, but it doesn&= #39;t sound
> correct
> to me. The probability of guessing a valid key is 2^{-key size}. The l= iit
> you're talking about only applies if you want to be guaranteed you= have
> a valid plaintext within a single frame.

That's my point. Otherwise the server has to make the client send= on average
2^{key size} random messages to get what it's looking for.
=

So? I have no idea why you think this is acceptable.



But even a 32-bit minimum key size for small frames would seem far enough,<= br> don't you think ?

No.=A0

=

-Ekr
=A0

--0016361e84fca6882204993b90bd-- From w@1wt.eu Thu Jan 6 22:25:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25E93A67B3 for ; Thu, 6 Jan 2011 22:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChuZFAP59b9g for ; Thu, 6 Jan 2011 22:25:24 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id BAEC63A67B4 for ; Thu, 6 Jan 2011 22:25:19 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p076RJsb030830; Fri, 7 Jan 2011 07:27:19 +0100 Date: Fri, 7 Jan 2011 07:27:19 +0100 From: Willy Tarreau To: Gabriel Montenegro Message-ID: <20110107062719.GM28367@1wt.eu> References: <4D26605B.1090409@callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:25:26 -0000 On Fri, Jan 07, 2011 at 01:44:30AM +0000, Gabriel Montenegro wrote: > > John Tamplin wrote: > ??? However, I am really loathe to try and define peer-to-peer operation in the base spec because I think it will unreasonably extend the process of getting the base protocol out the door. > > [gab] I agree. WGs are typically chartered with a specific focus in order to ease progress. The charter as approved by the IESG includes this: > The Hypertext-Bidirectional (HyBi) working group will seek > standardization of one approach to maintain bidirectional > communications between the HTTP client, server and intermediate > entities, which will provide more efficiency compared to the current > use of hanging requests. > > > This prominently talks about client-server not peer-to-peer. > When people have asked me if p2p is in scope, I???ve always answered ???no, by charter??? > as that is how I???ve interpreted the above. I agree with that but the term "p2p" can be vague in some circumstances, as it tends to be used in opposition with browser<->server. Some server to server architectures (such as webservices) are sometimes seen as p2p by some people because they don't understand that some of their servers can also be a client of another one. So I'd say no to the real p2p usage for now, but yes to the server-to-server (eg: have a front HTTP server use WS messages over a pool of established connections to validate auth tokens). This is indeed a client->server relation where the client here is not a browser. Probably that this part is not very clear in the current description as the work is mostly focused on browsers. Regards, Willy From w@1wt.eu Thu Jan 6 22:36:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B916D3A67C1 for ; Thu, 6 Jan 2011 22:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQYKrRqR50aL for ; Thu, 6 Jan 2011 22:36:49 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 16EB63A67B2 for ; Thu, 6 Jan 2011 22:36:48 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p076cspP030848; Fri, 7 Jan 2011 07:38:54 +0100 Date: Fri, 7 Jan 2011 07:38:54 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110107063854.GN28367@1wt.eu> References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 06:36:53 -0000 On Thu, Jan 06, 2011 at 10:16:55PM -0800, Eric Rescorla wrote: > > Well, at 1 million concurrent connections with a 5s think time, that's > > about > > 200k frames per second, it starts to be concerning even if it's cheap. > > My dinky Macbook Air does one million SHA-1 ops/second on a single core. That means a 20% CPU overhead imposed by masking then. > Again, see the Modadugu and Langley talk for real performance numbers. OK, will take a look. > But even a 32-bit minimum key size for small frames would seem far enough, > > don't you think ? > > > No. Then I don't follow you. If the server has to send on average 2^32 messages to have a chance to see "\nGET /\n", that's 28 GB of upstream traffic, or 52 GB with the framing and key. The client needs to be able to send it unnoticed by the user (52GB over ADSL...) and we must expect the broken intermediary to parse all that random crap without blinking an eye and suddenly spot our precious request. It will likely have spotted other ones as well before it BTW. That's why I was talking about pragmatism. We're trying to avoid some broken intermediaries to spot a valid request in the stream following the handshake and we consider that 52GB of random crap after the handshake it still represents a risk, and that's where I disagree :-/ Willy From gmonte@microsoft.com Thu Jan 6 23:16:30 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF583A67D1 for ; Thu, 6 Jan 2011 23:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnrfMa9KOTB2 for ; Thu, 6 Jan 2011 23:16:30 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 3EF133A67C2 for ; Thu, 6 Jan 2011 23:16:30 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 6 Jan 2011 23:18:30 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.255.3; Thu, 6 Jan 2011 23:18:30 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 6 Jan 2011 23:18:30 -0800 From: Gabriel Montenegro To: Willy Tarreau Thread-Topic: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? Thread-Index: AQHLrgmq/w4+Ld5wRUKExWVhu67oqJPEu34wgADWaYD//4dBsA== Date: Fri, 7 Jan 2011 07:18:57 +0000 Message-ID: References: <4D26605B.1090409@callenish.com> <20110107062719.GM28367@1wt.eu> In-Reply-To: <20110107062719.GM28367@1wt.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 07:16:31 -0000 > So I'd say no to the real p2p usage for now, but yes to the server-to-ser= ver > (eg: have a front HTTP server use WS messages over a pool of established > connections to validate auth tokens). This is indeed a client->server rel= ation > where the client here is not a browser. Probably that this part is not ve= ry clear in > the current description as the work is mostly focused on browsers. The charter is clear about HyBi targeting "clients other than Web Browsers"= , so this seems like a fine usage of client-server websockets. From gregw@intalio.com Fri Jan 7 00:40:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732723A67ED for ; Fri, 7 Jan 2011 00:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGfHk81HOFvj for ; Fri, 7 Jan 2011 00:40:15 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 950733A67E5 for ; Fri, 7 Jan 2011 00:40:15 -0800 (PST) Received: by qyk34 with SMTP id 34so218950qyk.10 for ; Fri, 07 Jan 2011 00:42:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.235.143 with SMTP id kg15mr21493940qcb.17.1294389741839; Fri, 07 Jan 2011 00:42:21 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Fri, 7 Jan 2011 00:42:21 -0800 (PST) In-Reply-To: <20110107063854.GN28367@1wt.eu> References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> Date: Fri, 7 Jan 2011 09:42:21 +0100 X-Google-Sender-Auth: YW3eUMGw19D9-v-5DFRBozWxKco Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 08:40:16 -0000 I really don't understand why we need to specify the algorithm to compute the masking key. Can't we just say that when masking is on, every frame has a random 32 byte mask which is applied with XOR to the payload. We can leave it to the client to generate the random mask with whatever algorithm using whatever salt that it likes. In fact, if we don't specify an algorithm, then there will be more natural variation in algorithms used and no systematic issues that will effect all clients. From andy.warmcat.com@googlemail.com Fri Jan 7 00:40:50 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BCF3A67E5 for ; Fri, 7 Jan 2011 00:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcVwk294o9A0 for ; Fri, 7 Jan 2011 00:40:48 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5159C3A67ED for ; Fri, 7 Jan 2011 00:40:48 -0800 (PST) Received: by wwa36 with SMTP id 36so17273495wwa.13 for ; Fri, 07 Jan 2011 00:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VbpGW5NGwgf4e3rDuJn1nVdYFjFPIOnxPGl4D2qbBFI=; b=nfIY1SuMABxi5ftvXH8tjxRq+Y7huDmdsOkN2z0Pwkp3E/RNObuxKnrwd9Mci2TX0X uSZmyvzvKkEWm+jHJixCqqCF4mn2Wxn3vLJYCTE8z5WBwSEiBp5sixkxVYab7m//AMq1 fgJ6/DrRzL1kURVADHRLTOkZ+a/+AoG8VRb/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=NRcT5Y4Pixup44d+bhFZ3BhfQGEDNQIaJ+huKXux17NvxE/6FWkLLQj5JR7twxZ95U HVfTxoefwC+SxdrFMGTg/1849pHg8RqwhNbpEGkx6A1kCr0A4QIpzlbDKph95VWs1715 bl6bitLsMK2fFCRiqB+5B7N7UOUcGkodYUPjU= Received: by 10.227.146.13 with SMTP id f13mr15134737wbv.133.1294389774685; Fri, 07 Jan 2011 00:42:54 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id 11sm17463664wbi.18.2011.01.07.00.42.53 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 00:42:53 -0800 (PST) Sender: Andy Green Message-ID: <4D26D20C.8030906@warmcat.com> Date: Fri, 07 Jan 2011 08:42:52 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> In-Reply-To: <20110107063854.GN28367@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 08:40:50 -0000 On 01/07/11 06:38, Somebody in the thread at some point said: >> But even a 32-bit minimum key size for small frames would seem far enough, >>> don't you think ? >> >> No. > That's why I was talking about pragmatism. We're trying to avoid > some broken intermediaries to spot a valid request in the stream If it really is the goal of websocket protocol is to disable any possible undefined attack on any possible undefined broken intermediary, broken in any possible combination of undefined ways, sure 32 bit key isn't enough; nothing's gonna be enough. How about some agreement first on what attacks it is that the crypto voodoo is trying to disable, and what it doesn't care about. For example, some arbitrarily broken intermediary may blow up if you send it an 0xff, we can all agree that's too broken to care about saving. There's some doubt that any real intermediary will sit through gigabytes of junk and then match on GET in the middle of it. Maybe we can agree that also would be an intermediary that is not worth the effort to protect. Are there any other cases we can agree are beyond saving and need not be considered? How many cases are disabled from attack if the websocket framing began always with the constant "\x0d\x0a\x0d\x0a", so you could never subsequently send data that could be interpreted as http headers or request? -Andy From gregw@intalio.com Fri Jan 7 00:55:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4695F3A67E5 for ; Fri, 7 Jan 2011 00:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtC1XWhezOKF for ; Fri, 7 Jan 2011 00:55:31 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 6DB053A67ED for ; Fri, 7 Jan 2011 00:55:31 -0800 (PST) Received: by vws7 with SMTP id 7so6913401vws.31 for ; Fri, 07 Jan 2011 00:57:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.187.132 with SMTP id cw4mr4866209vcb.25.1294390657748; Fri, 07 Jan 2011 00:57:37 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Fri, 7 Jan 2011 00:57:37 -0800 (PST) In-Reply-To: References: <4D26605B.1090409@callenish.com> <20110107062719.GM28367@1wt.eu> Date: Fri, 7 Jan 2011 09:57:37 +0100 X-Google-Sender-Auth: OCbmA0Oj8MoJG3hm6c3a_x7vUXM Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 08:55:32 -0000 I think the in-scope/out-of-scope issue comes back to the points made recently about flexibility. I think it is pretty clear that our charter is for a HTTP client (not necessarily a browser) talking to a server via intermediaries. But I think it is also very clear that there is demand for all sorts of different uses for a protocol like WS that can safely and standardly penetrate firewalls with bidirectional connections. So when we are faced with a choice between left or right, and there is no clear "winner" between the choices, then I think it is entirely valid to discuss potential out-of-scope use-cases like p2p to evaluate the choices. If left prohibits p2p use case, but right is useful for p2p, then I don't see why we cannot consider that for the sake of flexibility. I certainly hate the dismissal of concerns simply because they are out of scope. It is one thing to propose a whole bunch of mechanisms for p2p, and another thing entirely to note that some mechanisms being proposed will hinder out of scope usage. regards From andy.warmcat.com@googlemail.com Fri Jan 7 01:07:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C57E3A67E3 for ; Fri, 7 Jan 2011 01:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdDuqwOaaNN1 for ; Fri, 7 Jan 2011 01:07:14 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E35653A67EE for ; Fri, 7 Jan 2011 01:07:13 -0800 (PST) Received: by wyf23 with SMTP id 23so18078753wyf.31 for ; Fri, 07 Jan 2011 01:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OsZLv5jPj+R3e5M4EFkAglkB1dFPODhZyseFgy9TQDA=; b=JOHlqJOotEEPQ72if5ps0oXnPjx8/5w/K3ZViCEd97URZAYbcPj2FnCuIlKxoEaAeQ IPDPluusF75o7kbh/wGg8+2ydP3InU4XZYJ/mLkJYYpj4E9wkZNoyjQY+vRcP5NgtVfI q7t8ViLqGYY0aAAWt2mFXxajDOxxBHLmm5cGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=WCD0vQbNts6IsmIfxyq4KT1O1T4Gry0a6uQewUkK7KX/KHtdOV/igjREu17C6BAi1c WTd6AS0rldQ72G4kXKXnfRe97UyobLu2mNPkR3RFrPkZ8Xd4DoKHTwmqqN9ljzN1A/Z8 8J3PMBzF+iwRkPo25L0Ijh5o8UTvvZfGvvbE8= Received: by 10.227.141.137 with SMTP id m9mr15627322wbu.58.1294391360027; Fri, 07 Jan 2011 01:09:20 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id m13sm17473060wbz.9.2011.01.07.01.09.17 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 01:09:18 -0800 (PST) Sender: Andy Green Message-ID: <4D26D83D.3010101@warmcat.com> Date: Fri, 07 Jan 2011 09:09:17 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Greg Wilkins References: <4D26605B.1090409@callenish.com> <20110107062719.GM28367@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:07:15 -0000 On 01/07/11 08:57, Somebody in the thread at some point said: > I certainly hate the dismissal of concerns simply because they are out > of scope. It is one thing to propose a whole bunch of mechanisms for > p2p, and another thing entirely to note that some mechanisms being > proposed will hinder out of scope usage. If there's a smart way to integrate everything cleanly in a way that doesn't invalidate growth that's great. But otherwise you have to limit what is under consideration to get an actual result shipped. Or you end up with 80+ versions and a bunch of live competing specs for the same thing and no convergence, and no end to the disruptive demands rewriting even the most basic stuff from scratch. -Andy From dave@cridland.net Fri Jan 7 01:14:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB4E3A67E3 for ; Fri, 7 Jan 2011 01:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 013vWm8u8EmE for ; Fri, 7 Jan 2011 01:14:23 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id CDBCE3A67C1 for ; Fri, 7 Jan 2011 01:14:22 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 712101168117; Fri, 7 Jan 2011 09:16:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqoDwJyRE4We; Fri, 7 Jan 2011 09:16:23 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id B8A5B11680FB; Fri, 7 Jan 2011 09:16:23 +0000 (GMT) References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> In-Reply-To: <4D26D20C.8030906@warmcat.com> MIME-Version: 1.0 Message-Id: <10468.1294391783.740346@puncture> Date: Fri, 07 Jan 2011 09:16:23 +0000 From: Dave Cridland To: Andy Green , Server-Initiated HTTP , Willy Tarreau Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:14:24 -0000 On Fri Jan 7 08:42:52 2011, Andy Green wrote: > How many cases are disabled from attack if the websocket framing > began always with the constant "\x0d\x0a\x0d\x0a", so you could > never subsequently send data that could be interpreted as http > headers or request? We don't know, and can't tell without experiment. We can, however, say that we know due to such an experiment that no intermediaries are known to exist which interpret data in a dangerous way subsequent to a CONNECT - although this has only been tested as the first method used in a stream, to be precise. This implies that either of the original CONNECT-based handshake proposed, and my subsequent standards-conformant adaptation that (apparently) nobody likes, would be sufficient to reduce attacks to a percentage of intermediaries sufficiently small that none have been found to date. One may as well say that these intermediaries don't exist, and claim that proof because the invisible pink unicorn told us so, because it'll be just as easy to prove the non-existence of the IPU as to prove the non-existence of the intermediaries, and frankly as valid, given that experimental data at least supports the unicorn's statement. However, it seems that a very strong reality distortion field is in place in this working group - mere facts and experimental data are insufficient, and to be cast aside if they don't fit the theory, and we seem to have rechartered ourselves into a working group hell-bent on preventing any buggy third-party from being used as an attack surface in this or any possible parallel universe, past, present, or future. So we seem to be lumbering ourselves with some truly impressive baggage that future developers will either look upon aghast, or with amazement that we somehow predicted a sudden and uncharacteristic rise in vulnerable intermediaries - possibly even to measurable levels - despite all reasonable expectation to the contrary. I'm personally expecting the former - masking will become less and less relevant (and this is taking the generous step of assuming it has any relevance today), and we will be hamstrung with a protocol forcing us to mask every byte on the network for no reason whatsoever. Please, get off this bandwagon. The original paper which proposed masking as a side note also had an experimentally tested solution. Let's base our solution on that, and not go dashing off into theoretical weeds. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From salvatore.loreto@ericsson.com Fri Jan 7 01:28:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60BB73A67F4 for ; Fri, 7 Jan 2011 01:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpDnsirq9ocX for ; Fri, 7 Jan 2011 01:28:50 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2FBD63A67EE for ; Fri, 7 Jan 2011 01:28:49 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-10-4d26dd4f53a3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 02.91.13987.F4DD62D4; Fri, 7 Jan 2011 10:30:55 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Fri, 7 Jan 2011 10:30:55 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 40DC52980 for ; Fri, 7 Jan 2011 11:30:55 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0A4CF4F9E0 for ; Fri, 7 Jan 2011 11:30:55 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9379B4EE9D for ; Fri, 7 Jan 2011 11:30:54 +0200 (EET) Message-ID: <4D26DD4E.5070702@ericsson.com> Date: Fri, 7 Jan 2011 10:30:54 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4D26605B.1090409@callenish.com> In-Reply-To: <4D26605B.1090409@callenish.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:28:51 -0000 On 1/7/11 1:37 AM, Bruce Atherton wrote: > On 06/01/2011 1:43 AM, Greg Wilkins wrote: >> a difficulty of this working group is that we were never able to even >> agree on a requirement document as the various constituencies >> suspected each other of steering the requirements towards their own >> use-cases. Hence it is difficult to really say what is in scope or out >> of scope. > Thanks for the explanation, Greg. That explains a lot about why this > group is so dysfunctional. If you haven't agreed on what your goal is, > no wonder you are all pulling in different directions. A trade-off that > seems obvious to someone with a specific goal in mind will seem > insensible to another person with a different goal. > > Should the design of Websockets consider uses of peer-to-peer? Should it > give consideration to issues that are specific to Intranet use? Should > designers of the spec worry about non-browser clients like custom > written Websocket clients and Websocket servers that act as clients to > other servers? Or is the only thing that really matters when designing > Websockets the browser and server interactions, and any other use that > happens to work is just gravy? > > I think that agreeing on these basic questions will likely eliminate a > lot of the conflict on this list. Also, as a potential customer of this > specification it would be very useful to me to have a clear > understanding of what the intended uses for Websockets are, so that I > can better understand where I am supposed to be applying it in my future > designs. > > So far it appears that Greg, Brodie, Jerod, and I favour including > peer-to-peer design considerations in the spec. I am not sure, but it > sounds like John considers it out of scope and Scott considers it in > scope. What about the rest of you? as chair I have to say that at moment "peer to peer" is out of the scope as drafted in the charter: http://tools.ietf.org/wg/hybi/charters of course the charter is something that can be changed at anytime, if there is working group consensus on doing it. /Sal From salvatore.loreto@ericsson.com Fri Jan 7 01:32:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281A53A67F9 for ; Fri, 7 Jan 2011 01:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVb+gZpb+fhU for ; Fri, 7 Jan 2011 01:32:34 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5E0723A67EE for ; Fri, 7 Jan 2011 01:32:34 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-58-4d26de302107 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 21.12.13987.03ED62D4; Fri, 7 Jan 2011 10:34:40 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 7 Jan 2011 10:34:40 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DC2C62980 for ; Fri, 7 Jan 2011 11:34:38 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A5BAC4F9E0 for ; Fri, 7 Jan 2011 11:34:38 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3CBDA4EE9D for ; Fri, 7 Jan 2011 11:34:38 +0200 (EET) Message-ID: <4D26DE2D.5040901@ericsson.com> Date: Fri, 7 Jan 2011 10:34:37 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4D26605B.1090409@callenish.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030401060906050701090205" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:32:36 -0000 --------------030401060906050701090205 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 1/7/11 2:23 AM, John Tamplin wrote: > On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton > wrote: > > So far it appears that Greg, Brodie, Jerod, and I favour including > peer-to-peer design considerations in the spec. I am not sure, but > it sounds like John considers it out of scope and Scott considers > it in scope. What about the rest of you? > > > I am not opposed to it exactly, but given how long everything has > taken I am keen to keep the base protocol minimal so we can actually > get something out the door. I agree with John, lets keep the base protocol minimal at moment. Once we have reached consensus on the minimal base protocol we can start to add other stuff on top of the minimal base. If there is consensus in doing something in the future we can track it in the issue tracker so we won't forget. cheers /Sal -- Salvatore Loreto www.sloreto.com --------------030401060906050701090205 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit On 1/7/11 2:23 AM, John Tamplin wrote:
On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton <bruce@callenish.com> wrote:
So far it appears that Greg, Brodie, Jerod, and I favour including peer-to-peer design considerations in the spec. I am not sure, but it sounds like John considers it out of scope and Scott considers it in scope. What about the rest of you?

I am not opposed to it exactly, but given how long everything has taken I am keen to keep the base protocol minimal so we can actually get something out the door.
I agree with John,
lets keep the base protocol minimal at moment.
Once we have reached consensus on the minimal base protocol we can
start to add other stuff on top of the minimal base.

If there is consensus in doing something in the future we can track it in the issue tracker
so we won't forget.


cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com
--------------030401060906050701090205-- From gregw@intalio.com Fri Jan 7 01:33:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57BFA3A67F6 for ; Fri, 7 Jan 2011 01:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtCI-TXM8Sjj for ; Fri, 7 Jan 2011 01:33:33 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id B6E7B3A67EE for ; Fri, 7 Jan 2011 01:33:32 -0800 (PST) Received: by qyk34 with SMTP id 34so257416qyk.10 for ; Fri, 07 Jan 2011 01:35:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.53.213 with SMTP id n21mr23703198qag.399.1294392939084; Fri, 07 Jan 2011 01:35:39 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Fri, 7 Jan 2011 01:35:39 -0800 (PST) In-Reply-To: <4D26D20C.8030906@warmcat.com> References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> Date: Fri, 7 Jan 2011 10:35:39 +0100 X-Google-Sender-Auth: pyJQk7Bko10QQ5f13noY4j1uQ4A Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:33:36 -0000 On 7 January 2011 09:42, Andy Green wrote: > How many cases are disabled from attack if the websocket framing began > always with the constant "\x0d\x0a\x0d\x0a", so you could never subsequently > send data that could be interpreted as http headers or request? Andy, I think masking has been proposed as a way to get around the unprovables about the safety or otherwise of prefixes. There appears to be some who think a prefix of "CONNECT something HTTP/1.1\r\n\r\n" to a stream is sufficient protection. Yet there are also counter opinions that having a Hello frame at the start of the stream and every frame starting with a byte with the high bit set is insufficient. We iterated for a month or so trying to nail down exactly what was sufficient or insufficient and got no where. Masking appears the most popular solution because it avoids the need to decide what is sufficient or not - or so I thought. But now we are getting bogged arguing about if the masking algorithm is sufficiently strong or not. We are fighting over meta meta concerns! I'd like to propose the following: + The specification is updated so that extensions can use extension data with out using a reserved bit + A "masking" extension is defined that includes a 32bit masking key in the extension data of each frame. The key should be unpredictable, but the specification will not define how it is generated. + The masking key is applied with XOR to all extension data following the key. + The masking key is applied with XOR to all normal payload. + The masking extension is the default extension, so that if no extensions are negotiated it will be used from client->server + If other extensions are negotiated, then "masking" will need to be explicitly negotiated in the list of extensions. + We also define the "identity" extension, which is a do nothing extension. If both ends negotiate to use the "identity" extension only, then only the do nothing extension is applied and masking is not used. + Browsers or any client that executes 3rd party code, MUST NOT accept connections with identity only extension. While I'm sure you all have better proposals that this, the problem is everybody has different better proposals. So my question is would such a proposal be a show stopper for anybody? regards From andy.warmcat.com@googlemail.com Fri Jan 7 01:40:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D093A67FD for ; Fri, 7 Jan 2011 01:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKKJ5RtjdVvy for ; Fri, 7 Jan 2011 01:40:35 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 20EE63A6803 for ; Fri, 7 Jan 2011 01:40:34 -0800 (PST) Received: by wwa36 with SMTP id 36so17310893wwa.13 for ; Fri, 07 Jan 2011 01:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VkZfU002S+WfSziTFlOE2NtmWhBFNE7jMiJrqnQI3Pc=; b=WWQXqC4mgciYWQNJvLPXdUyrWEjsHug9hktpD38CMfn5+Tgj9vkbwDX25c+OTPVGvN HcsQuytFyyWSiMvbpBL3kA4fJxFrlWT6dz8Z2tkP9p97J1NOyQ+IgoVBxTv3Kq1cxhL5 ptJgzSRbCC8Z8WPgkrY9zAvRF+fdWXlaznlG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=fanCv6DJ0DI+n1H6IraGoJVQ4TxhIYabCjYvw/GpuokkNabH8eLw24jJgUQ3HgGj8w uxMXRiFgIhO4T5w7GtIbDV1kWRwG++UVmaf2OOtnESuTByWT+HZpOoOv6PKGO6TwSk2N grw1kE/G5XNHCMkc0rjJnbnIxhrof5Ea7MC+E= Received: by 10.227.138.76 with SMTP id z12mr15406779wbt.27.1294393361344; Fri, 07 Jan 2011 01:42:41 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id q18sm17513526wbe.23.2011.01.07.01.42.39 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 01:42:39 -0800 (PST) Sender: Andy Green Message-ID: <4D26E00E.10106@warmcat.com> Date: Fri, 07 Jan 2011 09:42:38 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Cridland References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> In-Reply-To: <10468.1294391783.740346@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:40:37 -0000 On 01/07/11 09:16, Somebody in the thread at some point said: > On Fri Jan 7 08:42:52 2011, Andy Green wrote: >> How many cases are disabled from attack if the websocket framing began >> always with the constant "\x0d\x0a\x0d\x0a", so you could never >> subsequently send data that could be interpreted as http headers or >> request? > > We don't know, and can't tell without experiment. I take your point but actually if we first agreed exactly what possible vulnerabilities we cared about, and they were few in number and well-defined, it would be possible to determine that one workaround or another would definitively disable possibility of those attacks without experiment. Experiment would tell us if any intermediaries could actually be found in the field with that vulnerability, but the corner we are backed into now with websockets disabled in two main browsers because of "security", reality is no longer the issue if it ever was. The issue now is finding a way to save face for them so they can re-enable websockets in their browser consistent with having shut it off over claims that have not yet delivered a broken piece of intermediary software for us to poke at and fix. > We can, however, say that we know due to such an experiment that no > intermediaries are known to exist which interpret data in a dangerous > way subsequent to a CONNECT - although this has only been tested as the Did you identify what that intermediary is with that behaviour, or find a way to make the problem repeatable for others? It's one thing to say n% of a random and unrepeatable test did this or that it's much more effective to announce "squid 3.1.9 in transparent breaks on websocket without CONNECT"... that will lead to reproduction, and squid getting fixed and solving it that way without websockets needing to do anything. > However, it seems that a very strong reality distortion field is in > place in this working group - mere facts and experimental data are > insufficient, and to be cast aside if they don't fit the theory, and we > seem to have rechartered ourselves into a working group hell-bent on > preventing any buggy third-party from being used as an attack surface in > this or any possible parallel universe, past, present, or future. So we lol Completely agree > Please, get off this bandwagon. The original paper which proposed > masking as a side note also had an experimentally tested solution. Let's > base our solution on that, and not go dashing off into theoretical weeds. Munging payload makes no sense to me in case you got the idea I am on that bandwagon. If CONNECT or some CRLFs in the framing allow the browsers to re-enable websockets without munging, so we can go on, that's a price worth paying IMO (even though I think all of it is pointless and a problem to be solved at the intermediary only). -Andy From gregw@intalio.com Fri Jan 7 01:53:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DD93A6800 for ; Fri, 7 Jan 2011 01:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd4nEYENnSxs for ; Fri, 7 Jan 2011 01:53:27 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id EA64C3A6807 for ; Fri, 7 Jan 2011 01:53:26 -0800 (PST) Received: by qwi2 with SMTP id 2so1840704qwi.31 for ; Fri, 07 Jan 2011 01:55:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.214.71 with SMTP id gz7mr10161726qab.349.1294394133292; Fri, 07 Jan 2011 01:55:33 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Fri, 7 Jan 2011 01:55:33 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Jan 2011 10:55:33 +0100 X-Google-Sender-Auth: bz7OykDpC62cRz-tMCcUFVDNaqs Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:53:28 -0000 On 7 January 2011 03:38, John Tamplin wrote: > My proposal: > 1) Define a new extension "clientmask" in the base spec, which > =A0 specifies that client->server masking is present. =A0An optional > =A0 parameter "type" specifies the type of masking, and if not > =A0 present defaults to "hmac-sha1". > =A0(this leave open the option > =A0of defining new masking methods in the future). > 2) Any clients which make WebSocket connections at the > =A0 request of untrusted code or entities and do not know for > =A0 certain that the entire path to the ultimate server is trusted > =A0 MUST request the clientmask extension and MUST fail the > =A0 connection if the server does not accept the extension. > 3) Any servers (or intermediaries acting as servers to the client) > =A0 accepting a connection from an untrusted source MUST NOT > =A0 accept a connection which does not request the clientmask > =A0 extension. =A0A server accepting a connection from a client that > =A0 is known to transit only trusted networks MAY accept > =A0 connections which do not request the clientmask extension. > =A0 A server which allows connections without the clientmask > =A0 extension SHOULD default to no trusted networks and be > =A0 configurable as to which networks are allowed to connect > =A0 without the clientmask extension. > 4) If the clientmask extension is negotiated, the first n bytes of > =A0 the extension data of client-server frames is a per-frame key > =A0 defined by the masking type, and the remainder of the payload > =A0 (including any further bytes of extension data and application > =A0 data) are masked as defined by the masking type. > 5) For clientmask type of "hmac-sha1", the per-frame key length > =A0 shall be 4 bytes, and the remainder of the frame shall be masked > =A0 according to the following algorithm: John, oops I missed this proposal before sending my own in another thread. I think your proposal is substantially the same as mine. A few notes: 1. I'm still dubious about the benefit of specifying a masking type other than XORing of a random per frame key. Any algorithm chosen appears vulnerable to accusations of "too expensive for client/intermediary/server of type X". 2. I'm happy either to have a default extension (as per my proposal) or to require browsers to use the clientmask extension. Whatever the browser folks think is simplest. 3. I think this one will be hard to implement/enforce. But maybe some verbiage recommending servers consider using clientmask if there is doubt about the path. 4. Perfect! 5. I really do not see the need for mixing in the nonces, thus making the masking non self describing and making it impossible to decode frames from mid stream. It strikes me as overkill and with significant consequences. Other than the masking algorithm, I think we are in agreement. Your masking algorithm is not a total show stopper for me, but I fear that specifying any moderately complex masking algorithm is just going the raise the hackles of those that are entirely unconvinced that masking is needed in the first place. To merge the two threads, my proposal was: + The specification is updated so that extensions can use extension data with out using a reserved bit + A "masking" extension is defined that includes a 32bit masking key in the extension data of each frame. The key should be unpredictable, but the specification will not define how it is generated. + The masking key is applied with XOR to all extension data following the k= ey. + The masking key is applied with XOR to all normal payload. + The masking extension is the default extension, so that if no extensions are negotiated it will be used from client->server + If other extensions are negotiated, then "masking" will need to be explicitly negotiated in the list of extensions. + We also define the "identity" extension, which is a do nothing extension. If both ends negotiate to use the "identity" extension only, then only the do nothing extension is applied and masking is not used. + Browsers or any client that executes 3rd party code, MUST NOT accept connections with identity only extension. cheers From andy.warmcat.com@googlemail.com Fri Jan 7 01:57:20 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E672D3A6808 for ; Fri, 7 Jan 2011 01:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QULdm1BGb5xq for ; Fri, 7 Jan 2011 01:57:19 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 958443A6807 for ; Fri, 7 Jan 2011 01:57:19 -0800 (PST) Received: by wyf23 with SMTP id 23so18116440wyf.31 for ; Fri, 07 Jan 2011 01:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XGC3PtCBWFRgyeszLZZssFAK/QAPCxZTAnCzD/y6UWo=; b=NPqF3LHhDQN0BXmeL9Dp+R6BbOhtVaFNlScvyFkkCKHPnyy7EnI9AcN01yqCON6f5+ lhDUyGm/ZvXs/p9ln1Y5U16ZWVk++WBApOVPB5LC6wBmH6MlrRfO+eQw40CXnK+gJWC5 1vtpYLfPLDGb7zdYXiNFpC/djSgsWOyRolvSk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Ufy9bcjBK+K9WbsT8FqG7mf8J43lRrciAB78CDu+axRbg3+RD5RmOBFIkuYh2cwpoP tERTkjdnyrjXY8L48MhIjHl/YzDconiE9LKqr5XnH1SMuPsropzKUd8DuX3cKYdK7vLp ++9BTLM5utp0Pb57wyjhjT0e7ezUZT+WxQyG8= Received: by 10.227.138.21 with SMTP id y21mr15440421wbt.212.1294394365653; Fri, 07 Jan 2011 01:59:25 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id q18sm17513807wbe.17.2011.01.07.01.59.24 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 01:59:25 -0800 (PST) Sender: Andy Green Message-ID: <4D26E3FB.6050206@warmcat.com> Date: Fri, 07 Jan 2011 09:59:23 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Greg Wilkins References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:57:21 -0000 On 01/07/11 09:35, Somebody in the thread at some point said: > I think masking has been proposed as a way to get around the > unprovables about the safety or otherwise of prefixes. > > There appears to be some who think a prefix of "CONNECT something > HTTP/1.1\r\n\r\n" to a stream is sufficient protection. Yet there are > also counter opinions that having a Hello frame at the start of the > stream and every frame starting with a byte with the high bit set is > insufficient. We iterated for a month or so trying to nail down > exactly what was sufficient or insufficient and got no where. It's because there is no central definition of which intermediary attacks we are trying to disable. Each person is making his case for a solution with his private ideas of what the goal is. > Masking appears the most popular solution because it avoids the need > to decide what is sufficient or not - or so I thought. But now we are > getting bogged arguing about if the masking algorithm is sufficiently > strong or not. We are fighting over meta meta concerns! Yeah, masking seems to people to be the strongest possible medicine for disabling attacks, so in the vacuum of any definition of what they are trying to achieve with it, people who think something should be achieved gravitate towards that. But like I said, actually with the goal of having masking undefined, unbounded, no medicine is actually going to be shown to be strong enough, not even if Eric gets tired fighting that corner and names some specific algorithm and key size as 'enough' (for what?). So I don't think we can talk sense and arrive at a technically reasoned consensus about disabling attacks until we make a set of attacks that we accept need to be disabled by the solution, and all other attacks are not our problem. > I'd like to propose the following: > > + The specification is updated so that extensions can use extension > data with out using a reserved bit I see what you're trying to do there with squeezing out the detail that will be debated while establishing munging, but I ask you is it a good idea to add this into a specification when you cannot actually describe in all honesty exactly what it is trying to achieve and why it is sufficient to achieve it? -Andy From w@1wt.eu Fri Jan 7 02:01:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331E43A680F for ; Fri, 7 Jan 2011 02:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5g2C8AKaSyn for ; Fri, 7 Jan 2011 02:01:11 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id ADDA13A6811 for ; Fri, 7 Jan 2011 02:01:10 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p07A3Dxr031676; Fri, 7 Jan 2011 11:03:13 +0100 Date: Fri, 7 Jan 2011 11:03:13 +0100 From: Willy Tarreau To: Dave Cridland Message-ID: <20110107100313.GO28367@1wt.eu> References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10468.1294391783.740346@puncture> User-Agent: Mutt/1.4.2.3i Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:01:12 -0000 On Fri, Jan 07, 2011 at 09:16:23AM +0000, Dave Cridland wrote: > On Fri Jan 7 08:42:52 2011, Andy Green wrote: > >How many cases are disabled from attack if the websocket framing > >began always with the constant "\x0d\x0a\x0d\x0a", so you could > >never subsequently send data that could be interpreted as http > >headers or request? > > We don't know, and can't tell without experiment. In fact, starting with CRLF should not change anything because HTTP recommends that implementations skip over CRLFs in request in order to accomodate for broken clients that used to send CRLFs after POST requests. Also, I think the smallest request we could fear would be the HTTP/0.9 "GET /\n". It's 6 bytes long. Whatever crypto algorithm is used, it will always be enough to send 6*256^6 bytes (about 1600 TB) to make it appear in the stream, and some clever constructs might be able to make it appear in only 256^6. That also means that any key larger than 6 bytes (48 bits) is pointless to protect against this request, whether we use a simple XOR or a cryptographically strong algorithm. In practice, it could happen a lot earlier because the key might just itself contain the pattern we're trying to avoid. > We can, however, say that we know due to such an experiment that no > intermediaries are known to exist which interpret data in a dangerous > way subsequent to a CONNECT - although this has only been tested as > the first method used in a stream, to be precise. This implies that > either of the original CONNECT-based handshake proposed, and my > subsequent standards-conformant adaptation that (apparently) nobody > likes, I disagree with these last few words, because I said that I liked the principle because eventhough it's dirty, it's a way to force some broken intermediaries to act in a more or less deterministic way. > would be sufficient to reduce attacks to a percentage of > intermediaries sufficiently small that none have been found to date. Please note that none intermediaries vulnerable to what we're trying to fix have been found to date either. > One may as well say that these intermediaries don't exist, and claim > that proof because the invisible pink unicorn told us so, because > it'll be just as easy to prove the non-existence of the IPU as to > prove the non-existence of the intermediaries, and frankly as valid, > given that experimental data at least supports the unicorn's > statement. You got me lost there. > However, it seems that a very strong reality distortion field is in > place in this working group - mere facts and experimental data are > insufficient, and to be cast aside if they don't fit the theory, and > we seem to have rechartered ourselves into a working group hell-bent > on preventing any buggy third-party from being used as an attack > surface in this or any possible parallel universe, past, present, or > future. So we seem to be lumbering ourselves with some truly > impressive baggage that future developers will either look upon > aghast, or with amazement that we somehow predicted a sudden and > uncharacteristic rise in vulnerable intermediaries - possibly even to > measurable levels - despite all reasonable expectation to the > contrary. The rise of vulnerable intermediaries will probably happen, because Adam and Eric's experiment showed that intermediaries vulnerable to HTTP do exist. The same that have been abused by their experiment might still be in the wild since nobody knows which ones were abused, and we know it only requires a shared hosting service to exploit them. The client may be anyone with an internet connection as it only requires the ability to forge an HTTP request. (In fact, I even hope that those crappy intermediaries will quickly be uncovered, that will make the net a cleaner place). But we've not got any evidence of an intermediary that is able to spot something looking like a valid request after the framing and we're several ones to have strong doubts about that. I'm not saying we should avoid masking, having it mandatory for the browsers will help us sleep in peace. But I sometimes would like to remind what we're trying to protect against vs what it costs to do it. When I'm saying that an attacker needs to send 52 GB of WS messages with 32bit keys to have "GET /\n" sent over the wire, hoping for an intermediary to pick it, while it would only have required a telnet to port 80 to reliably send it, I think we have a strong enough balance so that WS is not a usable attack vector anymore. > I'm personally expecting the former - masking will become less and > less relevant (and this is taking the generous step of assuming it > has any relevance today), and we will be hamstrung with a protocol > forcing us to mask every byte on the network for no reason whatsoever. I don't think that masking is that much relevant, it's just that it saves us from verifying hypothesis. That's a choice that was proposed to move forward, as all hypothesis of supposed vulnerabilities have remained unverified and unverifiable. > Please, get off this bandwagon. The original paper which proposed > masking as a side note also had an experimentally tested solution. > Let's base our solution on that, and not go dashing off into > theoretical weeds. I think that payload masking can have other advantages for totally unrelated reasons. For instance, if we design it as an extension, it might be usable to safely transmit asymetrically encrypted keys or passwords over the network with a key presented in the hello frames. But that's assuming we accept to make masking optional and negociable. Willy From gregw@intalio.com Fri Jan 7 02:07:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E673A6810 for ; Fri, 7 Jan 2011 02:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhdGx80sCOOj for ; Fri, 7 Jan 2011 02:07:01 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id C6C933A67F9 for ; Fri, 7 Jan 2011 02:07:01 -0800 (PST) Received: by qyk34 with SMTP id 34so283854qyk.10 for ; Fri, 07 Jan 2011 02:09:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.235.143 with SMTP id kg15mr21558267qcb.17.1294394947817; Fri, 07 Jan 2011 02:09:07 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Fri, 7 Jan 2011 02:09:07 -0800 (PST) In-Reply-To: <4D26E00E.10106@warmcat.com> References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <4D26E00E.10106@warmcat.com> Date: Fri, 7 Jan 2011 11:09:07 +0100 X-Google-Sender-Auth: KmXkhrnyFX1bRdMnLrMd_w0eM6w Message-ID: From: Greg Wilkins To: andy@warmcat.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:07:02 -0000 On 7 January 2011 10:42, Andy Green wrote: > If CONNECT or some CRLFs in the framing allow the browsers to re-enable > websockets without munging, so we can go on, that's a price worth paying IMO > (even though I think all of it is pointless and a problem to be solved at > the intermediary only). Andy, as much as I personally agree that sending some stream and/or frame prefix should be sufficient to defend against poor intermediaries, that line of argument has been made many many times and has uniformly failed to convince the browser vendors that speak in this WG. So unless they have a sudden change of heart/mind (???), then I really think the only way forward is along the lines of the consensus that started forming around masking. But for that to work, those that don't think masking is needed must stop trying to convince others that it is not needed, and those that think masking is cheap and simple must stop trying to convince others that there is no cost in making it mandatory in all deployments. regards From andy.warmcat.com@googlemail.com Fri Jan 7 02:27:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6836A3A6803 for ; Fri, 7 Jan 2011 02:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqSEV-PVWjCG for ; Fri, 7 Jan 2011 02:27:27 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F20403A6817 for ; Fri, 7 Jan 2011 02:27:26 -0800 (PST) Received: by wyf23 with SMTP id 23so18139798wyf.31 for ; Fri, 07 Jan 2011 02:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=S45Mm6dDN/T9fDMEAnvIYzRuiyMjVdvUBvyGZqWgFso=; b=E49LJJNhBhk4+2+jXJkEeBhT1+Gpe+gs/ImSguhtc3QwlSlbMDb+l+iS33HeIlh887 oflWmv7/Y0+L6P9A0fkfNst3/cmkP92iBGlPsEIrN6vMiLO4QQvl2vrG+u4gqa3CccUo KG7ssG9KDUj1kMz3MpQ/ZXKpemaYPfUs0u1yE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=kcNYcTe4XFX6VistBbyJBJXig8ppiF6/D2Iy7t8iXxm6C1X2+X5Pub49iIucLGTcKA XFflvvPsSjuQaNtrS/vz4ENERSbDqblPwKnAS8rrFm+KdI4IyBsb5M4kwYdAIALMsKWP QfFgb24lm9Ix0xvcokiueVveagChsegpMSMh4= Received: by 10.227.93.94 with SMTP id u30mr2600001wbm.153.1294396173057; Fri, 07 Jan 2011 02:29:33 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id q18sm17534290wbe.17.2011.01.07.02.29.30 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 02:29:31 -0800 (PST) Sender: Andy Green Message-ID: <4D26EB0A.9050203@warmcat.com> Date: Fri, 07 Jan 2011 10:29:30 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Greg Wilkins References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <4D26E00E.10106@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:27:28 -0000 On 01/07/11 10:09, Somebody in the thread at some point said: > as much as I personally agree that sending some stream and/or frame > prefix should be sufficient to defend against poor intermediaries, > that line of argument has been made many many times and has uniformly > failed to convince the browser vendors that speak in this WG. > > So unless they have a sudden change of heart/mind (???), then I really > think the only way forward is along the lines of the consensus that > started forming around masking. But for that to work, those that I agree, as a political situation regardless of the technical reality the browsers need a reason to re-enable websockets after disabling it for 'security'. > don't think masking is needed must stop trying to convince others that > it is not needed, and those that think masking is cheap and simple > must stop trying to convince others that there is no cost in making it > mandatory in all deployments. Since my use case for websockets involves a browser, like pretty much everybody else, when the browser makes munging mandatory by default it will be mandatory for me in fact. There's no possibility to reach a reasoned, technical decision about defeating attacks without defining the attacks that need to be defeated. If that isn't going to happen, then just making the spooked browser guys happy again by throwing crypto voodoo into the mix is as good as anything else, at the cost of stinking up this nice lightweight protocol for no perceptible benefit. -Andy From gregw@intalio.com Fri Jan 7 02:29:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1973A680F for ; Fri, 7 Jan 2011 02:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxHc6r8-xtRl for ; Fri, 7 Jan 2011 02:29:35 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id E5FE13A6803 for ; Fri, 7 Jan 2011 02:29:34 -0800 (PST) Received: by qyk34 with SMTP id 34so301918qyk.10 for ; Fri, 07 Jan 2011 02:31:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.235.143 with SMTP id kg15mr21575849qcb.17.1294396301323; Fri, 07 Jan 2011 02:31:41 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Fri, 7 Jan 2011 02:31:41 -0800 (PST) In-Reply-To: <4D26E3FB.6050206@warmcat.com> References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <4D26E3FB.6050206@warmcat.com> Date: Fri, 7 Jan 2011 11:31:41 +0100 X-Google-Sender-Auth: ZkFpEdO-8fefOeh104Wml4S1_hA Message-ID: From: Greg Wilkins To: andy@warmcat.com Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:29:36 -0000 On 7 January 2011 10:59, Andy Green wrote: > I ask you is it a good idea to > add this into a specification when you cannot actually describe in all > honesty exactly what it is trying to achieve and why it is sufficient to > achieve it? Andy, I can in all honesty describe the vulnerability that masking is trying to defend against. WS, by it's nature is designed to penetrate HTTP infrastructure, some of which is unaware of the ability of HTTP to be upgraded to a non-HTTP protocol. There is a demonstrated vulnerability in some intermediaries that they can have their caches poisoned by seeing spoofed host headers in a request sent to an attacker controlled server. However, this demonstration only HTTP compliant framing. There are other demonstrations of HTTP parsers that are very forgiving of at least some type of rubbish data between requests such that unknown methods and white space are skipped while the next request is looked for. There is a concern that there might exist intermediaries that suffer from both cache poisoning vulnerability and overly forgiving HTTP parsing. If so, WS could be used to attack these intermediaries and poison their caches. While such intermediaries are already vulnerable to flash and java plugins, these are optional extras in browsers, so it is a different matter to expose the same vulnerability in the protocol behind a non-optional part of the HTML-5 standard. Now, I personally believe that the existence of intermediaries with both vulnerabilities is vanishingly small and probably zero. I also believe that sending Hello frames and using framing with high bits set should be sufficient to break even the most forgiving of HTTP parsers. But I can not prove either point, nor after months of debate have the browser vendors been convinced of the validity of such arguments. Thus in the spirit of compromise, as an implementer or servers and non-browser clients, I'm prepared to accept a masking extension that removes the ability of attackers to send any predictable clear text in any frame and that this extension is mandatory for browsers. All I ask in return is when a connection is established by consenting parties that do not share the concern about such intermediaries, that there be a realistic option to turn off the masking (or replace it with something else). OK - I'm also asking that we don't go overboard with an elaborate masking algorithm - surely XORing a random key is sufficient? Technically, I believe that it is very important that WS has a viable extension mechanism. While I'm not entirely convinced of the need for masking on the grounds of security, I think it's value as an exemplar that will ensuring we have a viable extension mechanism is significant. regards From andy.warmcat.com@googlemail.com Fri Jan 7 02:40:20 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2ABA3A681B for ; Fri, 7 Jan 2011 02:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Asv2nXUALKz for ; Fri, 7 Jan 2011 02:40:19 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A2FEE3A681A for ; Fri, 7 Jan 2011 02:40:19 -0800 (PST) Received: by wyf23 with SMTP id 23so18149704wyf.31 for ; Fri, 07 Jan 2011 02:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=APdQp+GtcQ8dAdaeW4HuaA9hHg8n7nXNPNwpKk6ruY4=; b=WDTdcA3WOGsI72lsfkAEVPR8frCEGf6RLAU0lH2QCERbhvPN1so6dMFR/N9+Eej3dm EWY8t2xUO5xvdaNVf0RTQp+QZZ8saVBR4OfaYPg6IzxhYkoK7ChadKq24sgmx6wt4fgf JgiDWuNRLCyJ6bJ07i0aLk7ywL11FCquIMXHc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=CEkk5b+4o2slAz2plySJajydK2Jjde2GGxfrG43sOORobaRz/se8RPwBiUyQrPanBo JBTnzH2EojHvqaOsOOxuF/BVlj4mLbxPZCLTN0w5nvYlDL96V1MGGB9iVvlqyfPcvOzs D9PAjJ4kqT0dORlF+Nvqz7OCjw2dX+rLXzsdA= Received: by 10.227.153.11 with SMTP id i11mr9853809wbw.4.1294396945779; Fri, 07 Jan 2011 02:42:25 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id f35sm17542128wbf.2.2011.01.07.02.42.24 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 02:42:25 -0800 (PST) Sender: Andy Green Message-ID: <4D26EE10.5020306@warmcat.com> Date: Fri, 07 Jan 2011 10:42:24 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> In-Reply-To: <20110107100313.GO28367@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:40:20 -0000 On 01/07/11 10:03, Somebody in the thread at some point said: > On Fri, Jan 07, 2011 at 09:16:23AM +0000, Dave Cridland wrote: >> On Fri Jan 7 08:42:52 2011, Andy Green wrote: >>> How many cases are disabled from attack if the websocket framing >>> began always with the constant "\x0d\x0a\x0d\x0a", so you could >>> never subsequently send data that could be interpreted as http >>> headers or request? >> >> We don't know, and can't tell without experiment. > > In fact, starting with CRLF should not change anything because HTTP > recommends that implementations skip over CRLFs in request in order > to accomodate for broken clients that used to send CRLFs after POST > requests. Thanks for the insight... "+\x0d\x0a\x0d\x0a" then? -Andy From w@1wt.eu Fri Jan 7 02:44:14 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEAB3A681A for ; Fri, 7 Jan 2011 02:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE4WzmCPnZZ4 for ; Fri, 7 Jan 2011 02:44:13 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id E76963A67F8 for ; Fri, 7 Jan 2011 02:44:12 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p07AkHGK031851; Fri, 7 Jan 2011 11:46:17 +0100 Date: Fri, 7 Jan 2011 11:46:17 +0100 From: Willy Tarreau To: Greg Wilkins Message-ID: <20110107104617.GP28367@1wt.eu> References: <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <4D26E3FB.6050206@warmcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:44:14 -0000 On Fri, Jan 07, 2011 at 11:31:41AM +0100, Greg Wilkins wrote: > There is a demonstrated vulnerability in some intermediaries that they > can have their caches poisoned by seeing spoofed host headers in a > request sent to an attacker controlled server. However, this > demonstration only HTTP compliant framing. Indeed and it can also be done without involving a browser at all, just by sending a hand-crafted request to the faulty component. > There are other demonstrations of HTTP parsers that are very forgiving > of at least some type of rubbish data between requests such that > unknown methods and white space are skipped while the next request is > looked for. Such components generally are the ones that don't use the method, for instance, content switches that are just looking for host headers and maybe URI. Since a cache must check the method (at least to differentiate between HEAD/GET/POST), it could not blindly ignore it. > There is a concern that there might exist intermediaries that suffer > from both cache poisoning vulnerability and overly forgiving HTTP > parsing. If so, WS could be used to attack these intermediaries and > poison their caches. While such intermediaries are already > vulnerable to flash and java plugins, And to any incoming connection whatever the component which initiates it, I find it important to remind it. > these are optional extras in > browsers, so it is a different matter to expose the same vulnerability > in the protocol behind a non-optional part of the HTML-5 standard. > > Now, I personally believe that the existence of intermediaries with > both vulnerabilities is vanishingly small and probably zero. Agreed. > I also > believe that sending Hello frames and using framing with high bits set > should be sufficient to break even the most forgiving of HTTP parsers. Agreed too. > But I can not prove either point, nor after months of debate have > the browser vendors been convinced of the validity of such arguments. > > Thus in the spirit of compromise, as an implementer or servers and > non-browser clients, I'm prepared to accept a masking extension that > removes the ability of attackers to send any predictable clear text in > any frame and that this extension is mandatory for browsers. All I > ask in return is when a connection is established by consenting > parties that do not share the concern about such intermediaries, that > there be a realistic option to turn off the masking (or replace it > with something else). OK - I'm also asking that we don't go overboard > with an elaborate masking algorithm - surely XORing a random key is > sufficient? I too would be happy with that. In my opinion it would be technically useless, but technically cheap enough to justify having it, and it will make browser vendors feel better after what we tried to make them swallow. > Technically, I believe that it is very important that WS has a viable > extension mechanism. While I'm not entirely convinced of the need for > masking on the grounds of security, I think it's value as an exemplar > that will ensuring we have a viable extension mechanism is > significant. That's a good point. Just like TCP was released with the MSS option as the single one at the beginning. Regards, Willy From w@1wt.eu Fri Jan 7 02:51:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E813A67F8 for ; Fri, 7 Jan 2011 02:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGkNj70wchGW for ; Fri, 7 Jan 2011 02:51:23 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id EF0D23A67EC for ; Fri, 7 Jan 2011 02:51:22 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p07ArRw8031877; Fri, 7 Jan 2011 11:53:27 +0100 Date: Fri, 7 Jan 2011 11:53:27 +0100 From: Willy Tarreau To: Andy Green Message-ID: <20110107105327.GQ28367@1wt.eu> References: <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <4D26EE10.5020306@warmcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D26EE10.5020306@warmcat.com> User-Agent: Mutt/1.4.2.3i Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 10:51:24 -0000 On Fri, Jan 07, 2011 at 10:42:24AM +0000, Andy Green wrote: > On 01/07/11 10:03, Somebody in the thread at some point said: > >On Fri, Jan 07, 2011 at 09:16:23AM +0000, Dave Cridland wrote: > >>On Fri Jan 7 08:42:52 2011, Andy Green wrote: > >>>How many cases are disabled from attack if the websocket framing > >>>began always with the constant "\x0d\x0a\x0d\x0a", so you could > >>>never subsequently send data that could be interpreted as http > >>>headers or request? > >> > >>We don't know, and can't tell without experiment. > > > >In fact, starting with CRLF should not change anything because HTTP > >recommends that implementations skip over CRLFs in request in order > >to accomodate for broken clients that used to send CRLFs after POST > >requests. > > Thanks for the insight... "+\x0d\x0a\x0d\x0a" then? We should avoid restarting this debate, it has already been suggested to send strings supposed to make intermediaries abort on invalid requests, but since the fears about the broken one sometimes rely on their supposed ability to spot anything anywhere, such methods cannot be convincing for these people. If we want to send something that looks like a request, Dave is right, the experiment has only shown that CONNECT was respected. And if we wanted to go that route, we could only use what was proven by the experiment to reassure the people that were worried by the interpretation of the same experiment. Quite frankly, I'd prefer to be able to send a clear stream when possible, which means that optional masking is a good solution. 10 years from now, people will not say "why do we have to send a fake request after the handshake ?", at best they'll say "pfff this stupid masking has been unused for 5 years still we have to implement it", and that will mean we'll have already succeeded. Willy From andy.warmcat.com@googlemail.com Fri Jan 7 03:09:31 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4073A681E for ; Fri, 7 Jan 2011 03:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5L2PNSMLTcU for ; Fri, 7 Jan 2011 03:09:30 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9CF173A681D for ; Fri, 7 Jan 2011 03:09:30 -0800 (PST) Received: by wyf23 with SMTP id 23so18172704wyf.31 for ; Fri, 07 Jan 2011 03:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oFfdjayB7JF9vsyVzHNtJo++U983Qs+efsgj1CshHcs=; b=k1CHKViHEEpKM5I/gi071cKXz7ZAOfiyknKQFolJv0nQBrp2QUGB+agxmNDwPRMxMz UnZ4RZC47NvSabiWiwcDDjGIqQ8kzDoCkD5CIgn/Vl9JJb34NflIZdU6GilUoyhNgm/I mxIhJBT+oHEr1RGhR3wCPthB2nhQyOXvqgGZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Ne+dTBIL2dwnAI3WZuw+sNTBj6+8fe7FOKPvhVUv9dl0Kh0wppX6+W1INB7BiHwLZt M/WNPsQX8cF6hl9SFaYCk7zhF4GsU4uNEj8+QfuvTX6ivVHIvZFkePn/G+tD0sQ04eI7 1fiyIeUgb+R13ZRMT9LO/5IHiNavSizNTqZzI= Received: by 10.227.181.73 with SMTP id bx9mr15309145wbb.223.1294398696689; Fri, 07 Jan 2011 03:11:36 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id 11sm17562877wbj.13.2011.01.07.03.11.35 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 03:11:35 -0800 (PST) Sender: Andy Green Message-ID: <4D26F4E6.1010605@warmcat.com> Date: Fri, 07 Jan 2011 11:11:34 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <4D26EE10.5020306@warmcat.com> <20110107105327.GQ28367@1wt.eu> In-Reply-To: <20110107105327.GQ28367@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:09:32 -0000 On 01/07/11 10:53, Somebody in the thread at some point said: >> Thanks for the insight... "+\x0d\x0a\x0d\x0a" then? > > We should avoid restarting this debate, it has already been suggested > to send strings supposed to make intermediaries abort on invalid requests, > but since the fears about the broken one sometimes rely on their supposed > ability to spot anything anywhere, such methods cannot be convincing for > these people. Yeah but this is the bind, if we accept it is websocket responsibility to defeat attacks on an intermediary that has the "supposed ability to spot anything anywhere" as you say, then they will eventually spot something even in a munged stream. This troll intermediary is actually broken for use on a network at all, presumably it has a special get-out that it never spots crap on ssl. That's why I say no obfuscation key length is enough to satisfy the demand to protect the "anything anywhere" case, the demand is unreasonable and we should reject it and require these broken intermediaries get fixed themselves. > If we want to send something that looks like a request, Dave is right, the > experiment has only shown that CONNECT was respected. And if we wanted to > go that route, we could only use what was proven by the experiment to reassure > the people that were worried by the interpretation of the same experiment. > > Quite frankly, I'd prefer to be able to send a clear stream when possible, > which means that optional masking is a good solution. 10 years from now, > people will not say "why do we have to send a fake request after the > handshake ?", at best they'll say "pfff this stupid masking has been > unused for 5 years still we have to implement it", and that will mean > we'll have already succeeded. Like I said for me if it only takes CONNECT in the handshake or a few extra bytes in the framing and the rest is in clear, that is hugely preferable to munging every byte. -Andy From dave@cridland.net Fri Jan 7 03:13:29 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C2E3A681D for ; Fri, 7 Jan 2011 03:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPITJaSG0XNM for ; Fri, 7 Jan 2011 03:13:28 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 5D3783A681E for ; Fri, 7 Jan 2011 03:13:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 94D41116811E; Fri, 7 Jan 2011 11:15:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10nKOE9FYbTa; Fri, 7 Jan 2011 11:15:28 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 01E9311680FB; Fri, 7 Jan 2011 11:15:28 +0000 (GMT) References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> In-Reply-To: <20110107100313.GO28367@1wt.eu> MIME-Version: 1.0 Message-Id: <10468.1294398928.011152@puncture> Date: Fri, 07 Jan 2011 11:15:28 +0000 From: Dave Cridland To: Willy Tarreau , Andy Green , Server-Initiated HTTP Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:13:29 -0000 On Fri Jan 7 10:03:13 2011, Willy Tarreau wrote: > > would be sufficient to reduce attacks to a percentage of > > intermediaries sufficiently small that none have been found to > date. > > Please note that none intermediaries vulnerable to what we're trying > to fix have been found to date either. > > Not quite - the vulnerabilities have been found given a plain Upgrade-based handshake followed by syntactically correct HTTP requests and responses. There is some argument, much of it reasonable (if not absolutely convincing) that it follows that with a pure Upgrade-based handshake, intermediaries may "find" HTTP traffic within some framing. > > One may as well say that these intermediaries don't exist, and > claim > > that proof because the invisible pink unicorn told us so, because > > it'll be just as easy to prove the non-existence of the IPU as to > > prove the non-existence of the intermediaries, and frankly as > valid, > > given that experimental data at least supports the unicorn's > > statement. > > You got me lost there. Let's step into a parallel universe, for a moment. After all, everyone else is. In this hypothetical world, Adam conducts his advertising experiment and discovers that actually, no intermediaries he can find are vulnerable. But if they were, he notes that cryptographic masking would be sufficient to disable the attack. Would the working group consider masking in this parallel universe? Of course not, because that would be silly. In our real universe, however, Adam conducted his experiemnt and found that by sending a CONNECT, he could no longer find any vulnerable intermediaries. He notes that if there were, cryptographic masking would be sufficient to disable the attack. One might think that the same logic applies, and that the working group would universally nod, use the provided solution, and move on, without considering the masking which Adam has clearly demonstrated is superfluous by experiment. But no, the working group decides that yes, yes we will indeed do masking in spite of the evidence. Now, if I assert that no such intermediaries exist, I'm supported by experimental data - an experiment which, in case it needs to be said, I had nothing to do with. I can't absolutely prove my assertion, because proof of non-existence would require an exhaustive survey. However, disproving my assertion would require a less than exhaustive survey - and a reasonably high survey has been carried out without success. If I add, to my assertion, that I know so because an imaginary entity told me so, it remains equally valid, and to disprove the imaginary entity is again a proof of non-existence. > The rise of vulnerable intermediaries will probably happen, No - I think you simply misunderstood what I meant, rather than disagreeing with me. (I hope so, anyway). It seems probable than one or two will be found, certainly, but it seems highly unlikely - given experimental data - that these represent a significant threat. If we assume that the experimental sample was skewed by 50% - ie, the numbers of vulnerable intermediaries are 50% higher than it would suggest - then we have roughly 1 in every 25,000 intermediaries vulnerable. Now, assuming that every single person on the whole internet has a proxy of some form, that would mean that 80,000 vulnerable proxies exist amongst the 2 billion internet users. I don't think this is a sufficient attack surface to worry about, especially given that these represent intermediaries that are already vulnerable to attacks of the form we're trying to protect against by using Flash or Java. (And, maybe, ActiveX?) One assumes that, therefore, these will be fixed, and not just due to websockets, but due to the far more widely used rich content technologies of today. That is, to be clear - even if we deploy masking, these intermediaries will be fixed. So, my assertion is that this number will be the upper bound - ie, this number will drop (probably quite rapidly) - and will not rise. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From w@1wt.eu Fri Jan 7 03:32:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA253A6823 for ; Fri, 7 Jan 2011 03:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBHh3g5SPys3 for ; Fri, 7 Jan 2011 03:32:33 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id DAE153A67CF for ; Fri, 7 Jan 2011 03:32:32 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p07BYauJ032084; Fri, 7 Jan 2011 12:34:36 +0100 Date: Fri, 7 Jan 2011 12:34:36 +0100 From: Willy Tarreau To: Andy Green Message-ID: <20110107113436.GR28367@1wt.eu> References: <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <4D26EE10.5020306@warmcat.com> <20110107105327.GQ28367@1wt.eu> <4D26F4E6.1010605@warmcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D26F4E6.1010605@warmcat.com> User-Agent: Mutt/1.4.2.3i Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:32:34 -0000 On Fri, Jan 07, 2011 at 11:11:34AM +0000, Andy Green wrote: > On 01/07/11 10:53, Somebody in the thread at some point said: > > >>Thanks for the insight... "+\x0d\x0a\x0d\x0a" then? > > > >We should avoid restarting this debate, it has already been suggested > >to send strings supposed to make intermediaries abort on invalid requests, > >but since the fears about the broken one sometimes rely on their supposed > >ability to spot anything anywhere, such methods cannot be convincing for > >these people. > > Yeah but this is the bind, if we accept it is websocket responsibility > to defeat attacks on an intermediary that has the "supposed ability to > spot anything anywhere" as you say, then they will eventually spot > something even in a munged stream. Yes it will. But this will require much more data to be sent to make the "anything" appear than if we can put the "anything" on the wire as-is. > This troll intermediary is actually > broken for use on a network at all, That's what I've been saying for some time too. And I really guess that this intermediary is on no network at all anyway :-) > presumably it has a special get-out that it never spots crap on ssl. No, most likely it requires a specific header that we'll have to define :-) > Like I said for me if it only takes CONNECT in the handshake or a few > extra bytes in the framing and the rest is in clear, that is hugely > preferable to munging every byte. It depends how it can be removed later and how we can prove it's enough. The problem with a CONNECT request is that we have to ensure that either it always fails or that it always works (harder). There will always remain some doubts about "what if an intermediary silently ignores them and scans the remaining stream to search for a cacheable GET request"... In my opinion, neither the CONNECT nor masking are necessary. Technically the CONNECT offers much more control and relies less on luck than the masking. But as it requires better understanding of protocols, it does not have the psychological effect of "look, now the requests are masked so your browsers are safe again, isn't it beautiful ?". And clearly what we're looking for now is something that will be easy to understand for people who don't understand the basics of the underlying protocols. And I'm convinced that payload masking has this magical effect we're looking for with a low cost. Regards, Willy From dave@cridland.net Fri Jan 7 03:34:11 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904503A67CF for ; Fri, 7 Jan 2011 03:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSPkFKejUAqP for ; Fri, 7 Jan 2011 03:34:10 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 2A4373A67E3 for ; Fri, 7 Jan 2011 03:34:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id D71E9116811E; Fri, 7 Jan 2011 11:36:15 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBVP0zxXB9yT; Fri, 7 Jan 2011 11:36:12 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id CA82311680FB; Fri, 7 Jan 2011 11:36:11 +0000 (GMT) References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <4D26E00E.10106@warmcat.com> <4D26EB0A.9050203@warmcat.com> In-Reply-To: <4D26EB0A.9050203@warmcat.com> MIME-Version: 1.0 Message-Id: <10468.1294400171.841918@puncture> Date: Fri, 07 Jan 2011 11:36:11 +0000 From: Dave Cridland To: Andy Green , Server-Initiated HTTP , Greg Wilkins Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:34:11 -0000 On Fri Jan 7 10:29:30 2011, Andy Green wrote: > I agree, as a political situation regardless of the technical > reality the browsers need a reason to re-enable websockets after > disabling it for 'security'. Remember that whatever solution we propose for Websockets will also need to be proposed for Flash and Java, which are both considerably easier to exploit as an attck generator now, and also much more widely used - after all, it was using one of these technologies that the vulnerabilities were demonstrated. Re-enabling these two technologies would seem, if anything, to be a greater priority, given the current reliance on them. I'm assuming, of course, that the browser vendors actually disabled those, too, due to security, right? I'd hate to think they'd only disable the attack vector least likely to be useful, all in the name of "security", because that would be just laughable, right? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From w@1wt.eu Fri Jan 7 03:54:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9B53A681A for ; Fri, 7 Jan 2011 03:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vefser4lnKot for ; Fri, 7 Jan 2011 03:54:00 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 0E31B3A681D for ; Fri, 7 Jan 2011 03:53:59 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p07Bu4Zh032181; Fri, 7 Jan 2011 12:56:04 +0100 Date: Fri, 7 Jan 2011 12:56:04 +0100 From: Willy Tarreau To: Dave Cridland Message-ID: <20110107115604.GS28367@1wt.eu> References: <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10468.1294398928.011152@puncture> User-Agent: Mutt/1.4.2.3i Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:54:03 -0000 On Fri, Jan 07, 2011 at 11:15:28AM +0000, Dave Cridland wrote: > On Fri Jan 7 10:03:13 2011, Willy Tarreau wrote: > >> would be sufficient to reduce attacks to a percentage of > >> intermediaries sufficiently small that none have been found to > >date. > > > >Please note that none intermediaries vulnerable to what we're trying > >to fix have been found to date either. > > > > > Not quite - the vulnerabilities have been found given a plain > Upgrade-based handshake followed by syntactically correct HTTP > requests and responses. Yes precisely. But the framing is all but syntactically correct HTTP requests and responses. > There is some argument, much of it reasonable > (if not absolutely convincing) that it follows that with a pure > Upgrade-based handshake, intermediaries may "find" HTTP traffic > within some framing. I think that all the people who are thinking that should at some point try to write some working code to implement a real caching intermediary. They will see that they need to check the method and that you cannot randomly skip over garbage to presume your method will be here or there. Such a code would already have trouble with requests such as "POST /path/GET HTTP/1.1" or even with data looking like methods in headers or payload. Yes a simple content switch can be lazy, failures will have limited impact. But a cache cannot be that lazy. > In this hypothetical world, Adam conducts his advertising experiment > and discovers that actually, no intermediaries he can find are > vulnerable. But if they were, he notes that cryptographic masking > would be sufficient to disable the attack. > > Would the working group consider masking in this parallel universe? > Of course not, because that would be silly. > > In our real universe, however, Adam conducted his experiemnt and > found that by sending a CONNECT, he could no longer find any > vulnerable intermediaries. He notes that if there were, cryptographic > masking would be sufficient to disable the attack. One might think > that the same logic applies, and that the working group would > universally nod, use the provided solution, and move on, without > considering the masking which Adam has clearly demonstrated is > superfluous by experiment. Well, to be honnest, he did not exactly test what you are suggesting. He compared the GET+Upgrade followed by valid HTTP requests with CONNECT followed by valid HTTP requests and concluded that GET+Upgrade was sometimes failing where CONNECT did not. That does not mean that GET+Upgrade followed by a CONNECT is always OK. While our intuition lets us guess so, it has not even been tested. And as I explained in another mail, accepting that this complex design be more robust than the initial one that was accused of failing will not be easy for those who don't understand the basics of the underlying protocol. > But no, the working group decides that yes, yes we will indeed do > masking in spite of the evidence. > > Now, if I assert that no such intermediaries exist, I'm supported by > experimental data - an experiment which, in case it needs to be said, > I had nothing to do with. I can't absolutely prove my assertion, > because proof of non-existence would require an exhaustive survey. > However, disproving my assertion would require a less than exhaustive > survey - and a reasonably high survey has been carried out without > success. You like to stack up negations in your assertions... It's hard to follow you. So you're saying that a survery did not succeed in disproving your assertion that no broken intermediaries exist ? > If I add, to my assertion, that I know so because an imaginary entity > told me so, it remains equally valid, and to disprove the imaginary > entity is again a proof of non-existence. I'm lost again, sorry. > >The rise of vulnerable intermediaries will probably happen, > > No - I think you simply misunderstood what I meant, rather than > disagreeing with me. (I hope so, anyway). > > It seems probable than one or two will be found, certainly, but it > seems highly unlikely - given experimental data - that these > represent a significant threat. > > If we assume that the experimental sample was skewed by 50% - ie, the > numbers of vulnerable intermediaries are 50% higher than it would > suggest - then we have roughly 1 in every 25,000 intermediaries > vulnerable. Vulnerable to valid HTTP requests, let me insist on that once again, we've never found one vulnerable to WebSocket. > Now, assuming that every single person on the whole internet has a > proxy of some form, that would mean that 80,000 vulnerable proxies > exist amongst the 2 billion internet users. I don't think this is a > sufficient attack surface to worry about, especially given that these > represent intermediaries that are already vulnerable to attacks of > the form we're trying to protect against by using Flash or Java. And telnet, netcat, etc... No need to look for plugins when everyone has an internet connection which is enough to abuse them. > (And, maybe, ActiveX?) One assumes that, therefore, these will be > fixed, and not just due to websockets, but due to the far more widely > used rich content technologies of today. That is, to be clear - even > if we deploy masking, these intermediaries will be fixed. Exactly, that's why I'm advocating for strong protocol compliance. We can't force intermediaries to implement new protocols, but we can have them quickly fix their security issues. > So, my assertion is that this number will be the upper bound - ie, > this number will drop (probably quite rapidly) - and will not rise. I think the number of really vulnerable intermediaries (vulnerable to HTTP requests) will indeed drop, but their knowledge will rise with the interest around them that Adam's paper should suggest. Because basically right now those intermediaries can be fooled by anyone behind them as easily as : $ printf \ "GET / HTTP/1.1\r\nHost: my.fake.site.com\r\nUpgrade: WebSocket\r\n\r\n" \ "GET / HTTP/1.1\r\nHost: victim.com\r\n\r\n" > /dev/tcp/my.fake.site.com/80 So surely it will raise some interest ;-) Cheers, Willy From w@1wt.eu Fri Jan 7 03:57:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5743A681A for ; Fri, 7 Jan 2011 03:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqL+oWAAJ7Da for ; Fri, 7 Jan 2011 03:57:37 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id CFA9E3A6802 for ; Fri, 7 Jan 2011 03:57:36 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p07BxfXU032196; Fri, 7 Jan 2011 12:59:41 +0100 Date: Fri, 7 Jan 2011 12:59:41 +0100 From: Willy Tarreau To: Dave Cridland Message-ID: <20110107115941.GT28367@1wt.eu> References: <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <4D26E00E.10106@warmcat.com> <4D26EB0A.9050203@warmcat.com> <10468.1294400171.841918@puncture> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10468.1294400171.841918@puncture> User-Agent: Mutt/1.4.2.3i Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:57:38 -0000 On Fri, Jan 07, 2011 at 11:36:11AM +0000, Dave Cridland wrote: > On Fri Jan 7 10:29:30 2011, Andy Green wrote: > >I agree, as a political situation regardless of the technical > >reality the browsers need a reason to re-enable websockets after > >disabling it for 'security'. > > Remember that whatever solution we propose for Websockets will also > need to be proposed for Flash and Java, which are both considerably > easier to exploit as an attck generator now, and also much more > widely used - after all, it was using one of these technologies that > the vulnerabilities were demonstrated. > > Re-enabling these two technologies would seem, if anything, to be a > greater priority, given the current reliance on them. > > I'm assuming, of course, that the browser vendors actually disabled > those, too, due to security, right? I'd hate to think they'd only > disable the attack vector least likely to be useful, all in the name > of "security", because that would be just laughable, right? Why do you think that the situation suddenly must not be laughable anymore ? We're trying to make 0.001% of the users avoid to deliberately attack known vulnerable components which are exposed to larger parts of the net. Granted we can make some efforts to avoid the simple cases but those efforts should be reasonably limited once the cost becomes non-null. Willy From mjs@apple.com Fri Jan 7 06:18:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A73C3A68D7 for ; Fri, 7 Jan 2011 06:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3BKvoA3HxqJ for ; Fri, 7 Jan 2011 06:18:03 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 768463A68BE for ; Fri, 7 Jan 2011 06:18:03 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 73C20C9F25F7 for ; Fri, 7 Jan 2011 06:20:10 -0800 (PST) X-AuditID: 11807130-b7cb4ae000001037-14-4d27211a34c3 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay11.apple.com (Apple SCV relay) with SMTP id 96.DF.04151.A11272D4; Fri, 7 Jan 2011 06:20:10 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.14] ([24.6.209.6]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEN00LZJP5LI300@et.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 06:20:10 -0800 (PST) From: Maciej Stachowiak In-reply-to: <20110107055244.GH28367@1wt.eu> Date: Fri, 07 Jan 2011 06:20:09 -0800 Message-id: References: <4D17B5FF.5060209@callenish.com> <41249E48-B17E-47C7-9340-6F95B85182CD@apple.com> <20110107055244.GH28367@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:18:06 -0000 On Jan 6, 2011, at 9:52 PM, Willy Tarreau wrote: > On Mon, Dec 27, 2010 at 04:30:43PM -0800, Maciej Stachowiak wrote: >>> But I'm strongly against masking the framing itself. Their is >>> absolutely no reason for it other than to prevent the possibility of >>> making it optional. >> >> That's not right. One reason for masking the framing is to make it impossible for hostile browser-hosted hosted code to pre-generate valid-looking frames. If you don't mask framing, then it is trivial to create valid-looking frames, even if the contents are scrambled. Depending on circumstances, this could still be a dangerous attack on integrity. > > No Maciej, it's not "trivial" to do that because if you look at the framing, > very little of it is directly controlled by the application. As I suggested > in another mail, if you use RSV4 to indicate masking is used and put the > random key in extension data, that leaves you with : > - first byte with MORE|RSV1|RSV2|RSV3|OPCODE = 1|XXX|OPCODE > - second byte with RSV4|LENGTH = 1|LENGTH > - 3rd-4th bytes corresponding to the low part of the payload length, > only if previous byte is 0xFE/0xFF > - 5-10th bytes corresponding to the high part of the payload length > only if 2nd byte is 0xFF > - random key the size of the payload length > - application data > > The only controllable part here in which you might put an HTTP request is > the key length. But even in order to write an HTTP/0.9 "GET /\n", you have > to forge a message that is 0x54202F0A4745 bytes long, or 92 TeraBytes long. > And if you need to start it at the beginning of a line, it becomes > 0x4554202F0A0A47 which is 19 PetaBytes. By the time we get browsers able to > construct that large messages, we won't bother anymore about the broken > intermediaries. > > That's why I'm really considering masking the payload safe enough with > regards to the risk we're trying to cover. Willy, I think we're talking past each other. The threat model I'm talking about involves using HTTP APIs to connect to WebSocket servers. HTTP APIs in the browser will effectively let you send any bytes you want as the payload. You seem to be talking about the opposite threat model, where WebSocket APIs in the browser, to attack HTTP. These are completely separate threat models, and both are important to consider. Regards, Maciej From mjs@apple.com Fri Jan 7 06:26:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AFE73A68D8 for ; Fri, 7 Jan 2011 06:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.261 X-Spam-Level: X-Spam-Status: No, score=-106.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byKvc2GEQ-oE for ; Fri, 7 Jan 2011 06:26:01 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id C95593A68D7 for ; Fri, 7 Jan 2011 06:26:01 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 8FB7AC556CD5 for ; Fri, 7 Jan 2011 06:28:08 -0800 (PST) X-AuditID: 11807130-b7cb4ae000001037-e2-4d2722f84d89 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay11.apple.com (Apple SCV relay) with SMTP id B9.51.04151.8F2272D4; Fri, 7 Jan 2011 06:28:08 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.14] ([24.6.209.6]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEN00L5ZPIVI310@et.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 06:28:08 -0800 (PST) From: Maciej Stachowiak In-reply-to: Date: Fri, 07 Jan 2011 06:28:07 -0800 Message-id: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> References: To: John Tamplin X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: Hybi Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:26:03 -0000 I have several objections to this proposal: 1) The idea of an extension that is, in most circumstances, mandatory for both clients and servers seems silly. If the normal use case is that you always request it from the other endpoint, and refuse the connection if the other endpoint won't use it, then it's not an extension. 2) Designing things this way creates more risk of bugs leading to total security failure. 3) Some decent technical reasons have been given for why the framing should be masked as well, for example, when considering the threat model of using HTTP APIs in the browser to attack WebSocket services. 4) I still haven't seen evidence of a non-hypothetical use case for removing masking, so I don't think we should warp the design around the possibility. This proposal weakens the effectiveness of the masking (perhaps in minor or edge case ways) to make it easier to later address a totally unproven use case. Combining masking with GET+Upgrade (instead of a potentially more robust initial handshake) was already a compromise. Now I feel that GET+Upgrade advocates are incrementally chipping away at the effectiveness of the masking. Meanwhile, CONNECT advocates have largely agreed to let go of the CONNECT handshake idea if we can at least have effective masking. I don't think this ratchet method is an effective or fair way to negotiate agreement. Regards, Maciej On Jan 6, 2011, at 6:38 PM, John Tamplin wrote: > Ok, I understand your complaint about unlike SSL and other wrappers, > the proposed masking means an observer can't tell frame boundaries > without unmasking first. I am still not sure that is such a big deal > considering the simplicity of the proposed masking relative to > interpreting the framing anyway, but here is another attempt to > satisfy all concerned: > > Since I don't want to renogiate anything we have already agreed in the > base framing, that > means that Extension Data can only have a non-zero length if we > negotiate an extension, so that means we can't have masking be the > default and define a new extension later to remove it. > > My proposal: > 1) Define a new extension "clientmask" in the base spec, which > specifies that client->server masking is present. An optional > parameter "type" specifies the type of masking, and if not > present defaults to "hmac-sha1". > (this leave open the option > of defining new masking methods in the future). > 2) Any clients which make WebSocket connections at the > request of untrusted code or entities and do not know for > certain that the entire path to the ultimate server is trusted > MUST request the clientmask extension and MUST fail the > connection if the server does not accept the extension. > 3) Any servers (or intermediaries acting as servers to the client) > accepting a connection from an untrusted source MUST NOT > accept a connection which does not request the clientmask > extension. A server accepting a connection from a client that > is known to transit only trusted networks MAY accept > connections which do not request the clientmask extension. > A server which allows connections without the clientmask > extension SHOULD default to no trusted networks and be > configurable as to which networks are allowed to connect > without the clientmask extension. > 4) If the clientmask extension is negotiated, the first n bytes of > the extension data of client-server frames is a per-frame key > defined by the masking type, and the remainder of the payload > (including any further bytes of extension data and application > data) are masked as defined by the masking type. > 5) For clientmask type of "hmac-sha1", the per-frame key length > shall be 4 bytes, and the remainder of the frame shall be masked > according to the following algorithm: > > Let client-nonce and server-nonce be the respective nonces > exchanged during the handshake. Let uid be a 20-byte constant > defined in the standard, and per-frame-key be the masking key > read from the extension data. > > // computed once during the handshake > sessionKey = HMAC-SHA1(uid, client-nonce || server-nonce); > > for (int blockStart = 0; blockStart < remainingLength; blockStart += 20) { > mask = HMAC-SHA1(sessionKey, per-frame-key || blockStart); > for (int i = 0; i < 20 && blockStart + i < remainingLength; ++i) { > remainingPayload[blockStart + i] ^= mask[i]; > } > } > > The same operation is performed for masking and unmasking. > > > The intent of #1 is to conform to requirements established in the > current framing, in that Extension Data can only be used if an > extension is negotiated, as well as allowing the masking algorithm > to be refined in the future without defining a new extension. > > The intent of #2 & #3 is to allow the use-cases that have been > brought up, where the safety provided by masking is not needed. > > -- > John A. Tamplin > Software Engineer (GWT), Google > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From mjs@apple.com Fri Jan 7 06:32:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469503A68DC for ; Fri, 7 Jan 2011 06:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BML9EETymLYF for ; Fri, 7 Jan 2011 06:32:33 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 4D81D3A68CD for ; Fri, 7 Jan 2011 06:32:33 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 5B7CFC5571BE for ; Fri, 7 Jan 2011 06:34:40 -0800 (PST) X-AuditID: 11807136-b7bf8ae00000244a-78-4d27248057ad Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay15.apple.com (Apple SCV relay) with SMTP id C4.9B.09290.084272D4; Fri, 7 Jan 2011 06:34:40 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.14] ([24.6.209.6]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEN00LBMPTRI310@et.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 06:34:40 -0800 (PST) From: Maciej Stachowiak In-reply-to: <20110107063854.GN28367@1wt.eu> Date: Fri, 07 Jan 2011 06:34:39 -0800 Message-id: <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:32:34 -0000 On Jan 6, 2011, at 10:38 PM, Willy Tarreau wrote: > On Thu, Jan 06, 2011 at 10:16:55PM -0800, Eric Rescorla wrote: >>> Well, at 1 million concurrent connections with a 5s think time, that's >>> about >>> 200k frames per second, it starts to be concerning even if it's cheap. >> >> My dinky Macbook Air does one million SHA-1 ops/second on a single core. > > That means a 20% CPU overhead imposed by masking then. I would hope a server handling 1 million concurrent connections is considerably more powerful than a single core of a MacBook Air. Regards, Maciej From dave@cridland.net Fri Jan 7 06:39:49 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA223A68E0 for ; Fri, 7 Jan 2011 06:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx-Qu-n-tkCs for ; Fri, 7 Jan 2011 06:39:48 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 4CA423A68DF for ; Fri, 7 Jan 2011 06:39:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id E8C031168117; Fri, 7 Jan 2011 14:41:52 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVXryQu44zkq; Fri, 7 Jan 2011 14:41:48 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 97E7211680FB; Fri, 7 Jan 2011 14:41:48 +0000 (GMT) References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> In-Reply-To: <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> MIME-Version: 1.0 Message-Id: <10468.1294411308.608117@puncture> Date: Fri, 07 Jan 2011 14:41:48 +0000 From: Dave Cridland To: Maciej Stachowiak , Server-Initiated HTTP , Willy Tarreau Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:39:49 -0000 On Fri Jan 7 14:34:39 2011, Maciej Stachowiak wrote: > > On Jan 6, 2011, at 10:38 PM, Willy Tarreau wrote: > > > On Thu, Jan 06, 2011 at 10:16:55PM -0800, Eric Rescorla wrote: > >>> Well, at 1 million concurrent connections with a 5s think time, > that's > >>> about > >>> 200k frames per second, it starts to be concerning even if it's > cheap. > >> > >> My dinky Macbook Air does one million SHA-1 ops/second on a > single core. > > > > That means a 20% CPU overhead imposed by masking then. > > I would hope a server handling 1 million concurrent connections is > considerably more powerful than a single core of a MacBook Air. It'd have to be because of the masking. The thing is, I can quite easily see cases where BOSH or some other long-poll is going to be more efficient for servers to handle just because of the masking overhead. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dave@cridland.net Fri Jan 7 06:56:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7C03A68E9 for ; Fri, 7 Jan 2011 06:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIGZr6sHLZ3M for ; Fri, 7 Jan 2011 06:56:04 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 885D73A68D8 for ; Fri, 7 Jan 2011 06:56:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 0BFA71168117; Fri, 7 Jan 2011 14:58:09 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcJe6IVFQ4Qq; Fri, 7 Jan 2011 14:58:00 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 1F1AB11680FB; Fri, 7 Jan 2011 14:58:00 +0000 (GMT) References: =?US-ASCII?Q??= <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> In-Reply-To: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> MIME-Version: 1.0 Message-Id: <10468.1294412280.131214@puncture> Date: Fri, 07 Jan 2011 14:58:00 +0000 From: Dave Cridland To: Maciej Stachowiak , Server-Initiated HTTP , John Tamplin Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:56:05 -0000 On Fri Jan 7 14:28:07 2011, Maciej Stachowiak wrote: > 3) Some decent technical reasons have been given for why the > framing should be masked as well, for example, when considering the > threat model of using HTTP APIs in the browser to attack WebSocket > services. Hmmmph. If you can mimic any data as an HTTP client, then by inference you can mimic any masking, surely? The trick, then has to be to use restricted features like the Sec-* headers to defeat this attack at the handshake level, which we had way back when. > 4) I still haven't seen evidence of a non-hypothetical use case for > removing masking, so I don't think we should warp the design around > the possibility. This proposal weakens the effectiveness of the > masking (perhaps in minor or edge case ways) to make it easier to > later address a totally unproven use case. I still haven't seen evidence of a non-hypothetical case where masking is required. > Combining masking with GET+Upgrade (instead of a potentially more > robust initial handshake) was already a compromise. Now I feel that > GET+Upgrade advocates are incrementally chipping away at the > effectiveness of the masking. Meanwhile, CONNECT advocates have > largely agreed to let go of the CONNECT handshake idea if we can at > least have effective masking. I don't think this ratchet method is > an effective or fair way to negotiate agreement. CONNECT on its own fails because it is no longer correct HTTP. Pretending it is doesn't help - it breaks end-to-end transparency. Upgrade on its own has hypothetical - but reasonable - security arguments against it. However, in its favour, technologies like CORS should "just work", for instance. So, quite obviously, neither of those two options on their own work. Would the browser folk be interested in running an experiment to see if an Upgrade+CONNECT would work as intended? Would Google be willing to use their advertising network for such an experiment? If so, we could actually run an experiment that tested each proposal, and then for any where no attacks where found, we could select based purely on efficiency and correctness. Basing our decision making on hypothetical vulnerabilities which have been shown to be at least sufficiently rare as to not have been found seems like a poor course of action. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From gregw@intalio.com Fri Jan 7 07:01:50 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D1F3A68F2 for ; Fri, 7 Jan 2011 07:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQBHQabqtNWX for ; Fri, 7 Jan 2011 07:01:49 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 18F273A68F0 for ; Fri, 7 Jan 2011 07:01:49 -0800 (PST) Received: by qwi2 with SMTP id 2so2108924qwi.31 for ; Fri, 07 Jan 2011 07:03:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.53.213 with SMTP id n21mr23993785qag.399.1294412635528; Fri, 07 Jan 2011 07:03:55 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Fri, 7 Jan 2011 07:03:55 -0800 (PST) In-Reply-To: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> Date: Fri, 7 Jan 2011 16:03:55 +0100 X-Google-Sender-Auth: Ywl7p5MIf5pL_m21nLrB6lNzsv4 Message-ID: From: Greg Wilkins To: Maciej Stachowiak Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 15:01:50 -0000 On 7 January 2011 15:28, Maciej Stachowiak wrote: > > I have several objections to this proposal: > > 1) The idea of an extension that is, in most circumstances, mandatory for= both clients and servers seems silly. If the normal use case is that you a= lways request it from the other endpoint, and refuse the connection if the = other endpoint won't use it, then it's not an extension. I don't think you can say the normal use-case will always use masking. Sure it will for the browser, but it may be a very normal use-case for the the connection to enter a data centre via a web-socket aware aggregator that forwards the messages without masking to the application server. So from the server point of view, the normal use-case could be without masking. > 2) Designing things this way creates more risk of bugs leading to total s= ecurity failure. that's very subjective. I think that masking framing will result in more bugs, specially with partially received frames. > 3) Some decent technical reasons have been given for why the framing shou= ld be masked as well, for example, when considering the threat model of usi= ng HTTP APIs in the browser to attack WebSocket services. I do not think that threat has been well explained or accepted, nor is it the primary target of masking. Specifically I've not yet seen a credible explanation of how a HTTP API could generate the required headers to get past the websockets expectations of the initial upgrade request. I don't want to dismiss this vulnerability out of hand, but I would like to see more detail about it and to consider if there are other mitigations we could do that would not impede the progress we were making on masking. > 4) I still haven't seen evidence of a non-hypothetical use case for remov= ing masking, so I don't think we should warp the design around the possibil= ity. This proposal weakens the effectiveness of the masking (perhaps in min= or or edge case ways) to make it easier to later address a totally unproven= use case. Unfortunately there are some that see the hypothetical risk of these intermediaries as warping the design with the introduction of masking. Beside, there have been many use-case presented (eg the aggregator above) that would benefit from no masking. I know you think that masking is cheap - and it may be in the client, but there are many opinions on the intermediary/server side that are concerned about the cost of masking and thus there is a drive to have it as simple and cheap as possible, if not optional. > Combining masking with GET+Upgrade (instead of a potentially more robust = initial handshake) was already a compromise. Now I feel that GET+Upgrade ad= vocates are incrementally chipping away at the effectiveness of the masking= . Meanwhile, CONNECT advocates have largely agreed to let go of the CONNECT= handshake idea if we can at least have effective masking. I don't think th= is ratchet method is an effective or fair way to negotiate agreement. I don't think that is a fair or productive characterisation. I could equally say that masking advocates are incrementally increasing the scope and complexity of masking from the simple prevention of clear text originally proposed and adding new unproven hypothetical vulnerabilities - which would also be neither fair or productive. There is no benefit in having masking unless it is seen to be effective, so it is in nobodies interests to chip away at the effectiveness of masking. I truly do not understand why having the payload XOR's with a random per frame key will not be effective at preventing attackers sending clear text. Nor do I understand why having masking as an extension reduces it's effectiveness in any way. I get it that you'd greatly prefer masking to not be an extension, but in the spirit of compromise, what aspect of masking as an extension is a show stopper for you? regards From andy.warmcat.com@googlemail.com Fri Jan 7 07:13:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DDD23A68EE for ; Fri, 7 Jan 2011 07:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDc9FIGHvpRa for ; Fri, 7 Jan 2011 07:13:45 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id AB5833A67F0 for ; Fri, 7 Jan 2011 07:13:44 -0800 (PST) Received: by wyf23 with SMTP id 23so18394926wyf.31 for ; Fri, 07 Jan 2011 07:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YQWUynfRM2B8If9W2Dad7NUElbTlQhXoT54/B6wvJ40=; b=NepG8mqsvYsisCF4ddAVjjoI9jKy1jBXfVQC7PajAB7PPMF0Ijne1ghZrZ1aJLP0A4 yTK+2RnNW2YVUWd1u5mBCGXVUXLsQDOL9hrXE6vqEEyB55sYyH1hvKnv5QpxYMLUVqgJ 0jJMJJgVumMDglMUgWWm7VA/T/lXlpXDY4sNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Al5MB46xKH1lpbSItDzZRU515p8Wvaixu80k8RosypGyKVUe6sEgNm2cACdF7utb43 nPuVDHaFDMltH6YVBeecKDCwG84607VYGArYp9+U0+cTt93wT+78RHHzRtpz4DZEV0IW EYqxAF2aiYG0I1iMDDiCwhutw1b7288WtPMQQ= Received: by 10.227.132.206 with SMTP id c14mr15649295wbt.124.1294413350944; Fri, 07 Jan 2011 07:15:50 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id 11sm17738025wbi.12.2011.01.07.07.15.49 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 07:15:50 -0800 (PST) Sender: Andy Green Message-ID: <4D272E25.9050902@warmcat.com> Date: Fri, 07 Jan 2011 15:15:49 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Greg Wilkins References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <4D26E3FB.6050206@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism / building in troll proxy detection to the handshake X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 15:13:46 -0000 On 01/07/11 10:31, Somebody in the thread at some point said: > There is a concern that there might exist intermediaries that suffer > from both cache poisoning vulnerability and overly forgiving HTTP > parsing. If so, WS could be used to attack these intermediaries and > poison their caches. While such intermediaries are already > vulnerable to flash and java plugins, these are optional extras in > browsers, so it is a different matter to expose the same vulnerability > in the protocol behind a non-optional part of the HTML-5 standard. Thanks, that is quite concise describing what "masking" aka munging is meant to solve, assuming it's generally held agreed. At least nobody has poured scorn on it yet so let's assume that is the attack websockets is supposed to stop. How about this alternative solution for people who think the above is realistic: extend the handshake to deliberately send a websocket frame which (accepting the intermediary has dumb HTTP parsing and ignores the framing) trying to poison the cache at a random and unlikely URL path, then connect to the server in http again and confirm the poisoned path is a 404 before allowing the connection. So, it's 1) normal -03 handshake 2) send an initial frame to be discarded by the server, containing a good-looking HTTP poisoning action for a URL like "/__websocketcheck/" inside websocket framing 3) try to GET "/__websocketcheck/", die if it exists 4) otherwise, enjoy a non-munged websocket life Of course, after a while when the number of hits on the test URL remains at 0, or the troll proxies are identified and updated, this can be removed from the handshake. -Andy From alex@noemax.com Fri Jan 7 07:59:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662FC3A691B for ; Fri, 7 Jan 2011 07:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5QkBLV2ffUA for ; Fri, 7 Jan 2011 07:59:44 -0800 (PST) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by core3.amsl.com (Postfix) with ESMTP id 8FB803A6918 for ; Fri, 7 Jan 2011 07:59:42 -0800 (PST) Received: from HPdv73190ev by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id QRI11145; Fri, 07 Jan 2011 18:01:45 +0200 From: "Alexander Philippou" To: "'Maciej Stachowiak'" References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> In-Reply-To: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> Date: Fri, 7 Jan 2011 18:01:37 +0200 Message-ID: <00e101cbae84$2e0b7510$8a225f30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuudx2IH0ymSU1PR8ukIIgzaodnkQAAHQEw Content-Language: en-us Cc: 'Hybi' Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 15:59:46 -0000 > 4) I still haven't seen evidence of a non-hypothetical use case for = removing masking, so I don't think we should warp the design around the = possibility. This proposal weakens the effectiveness of the masking = (perhaps in minor or edge case ways) to make it easier to later address = a totally unproven use case. One large use case is non-browser client systems. I don't see how = masking will be useful to them. Masking seems to be protecting against = vulnerabilities that affect only browser client systems. Unless there is = evidence that these protection mechanisms have a universal usefulness, I = would strongly support a design that keeps them as an optional = extension. Alexander From jat@google.com Fri Jan 7 08:01:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338F73A691C for ; Fri, 7 Jan 2011 08:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.405 X-Spam-Level: X-Spam-Status: No, score=-104.405 tagged_above=-999 required=5 tests=[AWL=-2.428, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tLCfzhkkH0u for ; Fri, 7 Jan 2011 08:01:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 1B6113A6937 for ; Fri, 7 Jan 2011 08:01:10 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p07G3Gg2012379 for ; Fri, 7 Jan 2011 08:03:17 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294416197; bh=6oq9Az6lb9lIDrfEoVBxPAZ22Ec=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=LYgLETli+mx1giu8hfHjb5KTyB4IijOVvDYC1iUKqGabMlj3d0D2dafKwVF6g1BpM ouKzl8LPF5ttWdwsW1Rww== Received: from qyk12 (qyk12.prod.google.com [10.241.83.140]) by wpaz17.hot.corp.google.com with ESMTP id p07G2TS9029401 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 7 Jan 2011 08:03:15 -0800 Received: by qyk12 with SMTP id 12so17925799qyk.12 for ; Fri, 07 Jan 2011 08:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=u6LTDAcYbuDQNx2WZG6HXU9xklzt0rlGgfx6P6Z9H0s=; b=xpk1q1p+ljb7UMWvRyPUYhqFI2dqEVJhNs32I2oIei5oRhzMt4+wZbk2kBH0q30xro LQGx1q5SzXzLAB+UXabg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=PsDZOEhcOwXQ0AxokLxvHB1+eK2qgwtE9iihpU3znUx3Rd3FxfV2tBAMzTwqOiwIRB zf2byA72sOdXF/ZpV8qQ== Received: by 10.229.232.15 with SMTP id js15mr22430638qcb.136.1294416194621; Fri, 07 Jan 2011 08:03:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.106.38 with HTTP; Fri, 7 Jan 2011 08:02:53 -0800 (PST) In-Reply-To: <4D272E25.9050902@warmcat.com> References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <4D26E3FB.6050206@warmcat.com> <4D272E25.9050902@warmcat.com> From: John Tamplin Date: Fri, 7 Jan 2011 11:02:53 -0500 Message-ID: To: andy@warmcat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism / building in troll proxy detection to the handshake X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:01:15 -0000 On Fri, Jan 7, 2011 at 10:15 AM, Andy Green wrote: > How about this alternative solution for people who think the above is > realistic: extend the handshake to deliberately send a websocket frame wh= ich > (accepting the intermediary has dumb HTTP parsing and ignores the framing= ) > trying to poison the cache at a random and unlikely URL path, then connec= t > to the server in http again and confirm the poisoned path is a 404 before > allowing the connection. > > So, it's > > =C2=A01) normal -03 handshake > =C2=A02) send an initial =C2=A0frame to be discarded by the server, conta= ining a > good-looking HTTP poisoning action for a URL like "/__websocketcheck/ integer>" inside websocket framing > =C2=A03) try to GET "/__websocketcheck/", die if it exist= s > =C2=A04) otherwise, enjoy a non-munged websocket life > > Of course, after a while when the number of hits on the test URL remains = at > 0, or the troll proxies are identified and updated, this can be removed f= rom > the handshake. Personally, I find requiring extra round trips during the handshake far more objectionable than a small amount of per-byte processing overhead. --=20 John A. Tamplin Software Engineer (GWT), Google From jat@google.com Fri Jan 7 08:04:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B16E3A692E for ; Fri, 7 Jan 2011 08:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.365 X-Spam-Level: X-Spam-Status: No, score=-104.365 tagged_above=-999 required=5 tests=[AWL=-2.388, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdg2d-zJOL8W for ; Fri, 7 Jan 2011 08:04:37 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 86C403A68ED for ; Fri, 7 Jan 2011 08:04:37 -0800 (PST) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p07G6hCF019680 for ; Fri, 7 Jan 2011 08:06:43 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294416403; bh=Jd8cUjoDOoxOypeKu8+/YOtoGDo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=VmGkBD4YpPhWRJosS6OEoqY1AgzCtejIP2jEGnI8S1rE0djYGnNtIN4xfyI/jrGKN T2D8N7RIEoaRpQ7pWlZvw== Received: from qwj8 (qwj8.prod.google.com [10.241.195.72]) by hpaq2.eem.corp.google.com with ESMTP id p07G5jcp021956 for ; Fri, 7 Jan 2011 08:06:42 -0800 Received: by qwj8 with SMTP id 8so18462058qwj.10 for ; Fri, 07 Jan 2011 08:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=XXKtWmRJVos3PZ8Rnka2jYexHitT7dqqLh0yjkpOzR8=; b=SDkXjufYRPOlBtT6dLOOOcW5q+TV+I83q/C3QSLrgeEzU/tctZ/99dZiLMtnzKMHqJ iX5Jbv4tJofPcHtfgfyw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=xvk7ncQiR3msiJCMEXPRh3Bso/cx9FPN88K5GPjKFo8LqS3R8I2bgIp+r1Rwjkw/hb LBcChLRFGWEPqqePYJ0A== Received: by 10.229.219.132 with SMTP id hu4mr22973501qcb.60.1294416402225; Fri, 07 Jan 2011 08:06:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.106.38 with HTTP; Fri, 7 Jan 2011 08:06:20 -0800 (PST) In-Reply-To: <10468.1294412280.131214@puncture> References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> <10468.1294412280.131214@puncture> From: John Tamplin Date: Fri, 7 Jan 2011 11:06:20 -0500 Message-ID: To: Dave Cridland Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Server-Initiated HTTP Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:04:38 -0000 On Fri, Jan 7, 2011 at 9:58 AM, Dave Cridland wrote: > Would the browser folk be interested in running an experiment to see if an > Upgrade+CONNECT would work as intended? Would Google be willing to use their > advertising network for such an experiment? If so, we could actually run an > experiment that tested each proposal, and then for any where no attacks > where found, we could select based purely on efficiency and correctness. The question about Google's participation is above my pay grade, but assuming the answer to both of the above are yes, are we really willing to put WebSockets on hold for 6 months or more while an experiment is crafted, conducted, and analyzed? -- John A. Tamplin Software Engineer (GWT), Google From gregw@intalio.com Fri Jan 7 08:06:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE803A691A for ; Fri, 7 Jan 2011 08:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fs4fHNyQbDY for ; Fri, 7 Jan 2011 08:06:12 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 6EC783A692C for ; Fri, 7 Jan 2011 08:06:12 -0800 (PST) Received: by qwi2 with SMTP id 2so2177021qwi.31 for ; Fri, 07 Jan 2011 08:08:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.47.75 with SMTP id m11mr24022557qaf.249.1294416498633; Fri, 07 Jan 2011 08:08:18 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Fri, 7 Jan 2011 08:08:18 -0800 (PST) In-Reply-To: <4D272E25.9050902@warmcat.com> References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <4D26E3FB.6050206@warmcat.com> <4D272E25.9050902@warmcat.com> Date: Fri, 7 Jan 2011 17:08:18 +0100 X-Google-Sender-Auth: MI3Xdtd6KphhSmq6LV6x1GKj9Rs Message-ID: From: Greg Wilkins To: andy@warmcat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism / building in troll proxy detection to the handshake X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:06:13 -0000 Andy, the problem is that sending a single poisoning attack that fails does not prove that all poisoning attacks will fail. Maybe the intermediary needs special cache-control headers for it to work, or maybe the particular injection was not found, but it is still scanning and might see a subsequent phantom request. The fundamental problem with this line of solution, is that you inevitably have to ask the question: "is this good enough?" But we have no definition or agreement what "enough" is! It was hoped that masking would remove the possibility of clear text and thus avoid the attempt to detect or trip up bad intermediaries. Unfortunately we are now in the: "is this masking good enough?" game :( cheers On 7 January 2011 16:15, Andy Green wrote: > On 01/07/11 10:31, Somebody in the thread at some point said: > >> There is a concern that there might exist intermediaries that suffer >> from both cache poisoning vulnerability and overly forgiving HTTP >> parsing. =A0If so, WS could be used to attack these intermediaries and >> poison their caches. =A0 While such intermediaries are already >> vulnerable to flash and java plugins, these are optional extras in >> browsers, so it is a different matter to expose the same vulnerability >> in the protocol behind a non-optional part of the HTML-5 standard. > > Thanks, that is quite concise describing what "masking" aka munging is me= ant > to solve, assuming it's generally held agreed. =A0At least nobody has pou= red > scorn on it yet so let's assume that is the attack websockets is supposed= to > stop. > > How about this alternative solution for people who think the above is > realistic: extend the handshake to deliberately send a websocket frame wh= ich > (accepting the intermediary has dumb HTTP parsing and ignores the framing= ) > trying to poison the cache at a random and unlikely URL path, then connec= t > to the server in http again and confirm the poisoned path is a 404 before > allowing the connection. > > So, it's > > =A01) normal -03 handshake > =A02) send an initial =A0frame to be discarded by the server, containing = a > good-looking HTTP poisoning action for a URL like "/__websocketcheck/ integer>" inside websocket framing > =A03) try to GET "/__websocketcheck/", die if it exists > =A04) otherwise, enjoy a non-munged websocket life > > Of course, after a while when the number of hits on the test URL remains = at > 0, or the troll proxies are identified and updated, this can be removed f= rom > the handshake. > > -Andy > From jat@google.com Fri Jan 7 08:07:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3CB3A6918 for ; Fri, 7 Jan 2011 08:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.87 X-Spam-Level: X-Spam-Status: No, score=-103.87 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KybaqMqiQMjA for ; Fri, 7 Jan 2011 08:07:52 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A531C3A691A for ; Fri, 7 Jan 2011 08:07:52 -0800 (PST) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p07G9wVM023193 for ; Fri, 7 Jan 2011 08:09:58 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294416599; bh=HpwOcH8It1b+XttFa6D5vss7f2o=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=EFM8Jy+W1wAf5LN20FcJaqVDCqr/ohTqJf9X2xY9V58h1BrDHw+B6y93LeG4h4+M+ Sko6Pw1PSy8H0PymV26dw== Received: from qyj19 (qyj19.prod.google.com [10.241.83.83]) by hpaq14.eem.corp.google.com with ESMTP id p07G85GA023682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 7 Jan 2011 08:09:57 -0800 Received: by qyj19 with SMTP id 19so570502qyj.12 for ; Fri, 07 Jan 2011 08:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Io9sCXJhCmF/VYe2ZsLV9AZ9Vs2WjrnYgfgAcMVUfs4=; b=iszqzZ0/Un2P86G4JxA7EBeYZPyjuaOfU9/0y3A++6lQ6fwpBzY1ZuiZcLkxHKj3Or cIeyuEneZ3UMJSlN2cxg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=l5XFaSufAGPJVKlOvNpb/kpDSlQ6CoubCNij5l8Aoax7D93soN08SUaFqW4eoA5uWX h2Aj66mU4EzTl6uYEicA== Received: by 10.229.224.136 with SMTP id io8mr16701162qcb.250.1294416596545; Fri, 07 Jan 2011 08:09:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.106.38 with HTTP; Fri, 7 Jan 2011 08:09:35 -0800 (PST) In-Reply-To: <20110107115604.GS28367@1wt.eu> References: <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <20110107115604.GS28367@1wt.eu> From: John Tamplin Date: Fri, 7 Jan 2011 11:09:35 -0500 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:07:54 -0000 On Fri, Jan 7, 2011 at 6:56 AM, Willy Tarreau wrote: > I think the number of really vulnerable intermediaries (vulnerable to > HTTP requests) will indeed drop, but their knowledge will rise with the > interest around them that Adam's paper should suggest. Because basically > right now those intermediaries can be fooled by anyone behind them as > easily as : > > =C2=A0$ printf \ > =C2=A0 =C2=A0"GET / HTTP/1.1\r\nHost: my.fake.site.com\r\nUpgrade: WebSoc= ket\r\n\r\n" \ > =C2=A0 =C2=A0"GET / HTTP/1.1\r\nHost: victim.com\r\n\r\n" > /dev/tcp/my.f= ake.site.com/80 > > So surely it will raise some interest ;-) And if simply clicking on a link in a browser could cause that code to be executed on their machine, then yes this would be equally exploitable. --=20 John A. Tamplin Software Engineer (GWT), Google From andy.warmcat.com@googlemail.com Fri Jan 7 08:17:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43BEC3A68C0 for ; Fri, 7 Jan 2011 08:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Nu4X7hYdRLK for ; Fri, 7 Jan 2011 08:17:17 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2ECC13A6842 for ; Fri, 7 Jan 2011 08:17:17 -0800 (PST) Received: by wyf23 with SMTP id 23so18451503wyf.31 for ; Fri, 07 Jan 2011 08:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Td8AIuu+uZu5ufhFfbHX9PkdRhmOJ9phgnBu4dLZ0Pk=; b=HhFHUI8/bRFRd3NpyVKPCm3iyBshIeTfggjc22BTWtTi2o2LoRm8LBFcLv2iN6A91K Qz4k7x5WOnR8S9TYE6k58UVoEpRr/VbyifRi6S6Cpo6tWTYqsLrVqYW45gddaVx2wQtu tj/JQvEt6lfVjrjtkp8WWHr52YipCUP1pEUQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=c0ruj1xPfSpoaigSOYJhllHbRJq7Rsorgedl7xdk8ftIFjjh4Xtziywqc+yGcYWDXP XM/flLS+M8kFmpg81gdBRk1yNKZNFxjrXdWusjCfIIZsS2afViRQUglYrHTTfQ5mqyhB iPvgRLKhWcJ+OPde9v3Vsd45OKkQ1RW8XkMRk= Received: by 10.227.146.196 with SMTP id i4mr15612387wbv.105.1294417087160; Fri, 07 Jan 2011 08:18:07 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id 11sm17783329wbj.13.2011.01.07.08.18.05 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 08:18:05 -0800 (PST) Sender: Andy Green Message-ID: <4D273CBC.7060801@warmcat.com> Date: Fri, 07 Jan 2011 16:18:04 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Tamplin References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <4D26E3FB.6050206@warmcat.com> <4D272E25.9050902@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism / building in troll proxy detection to the handshake X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:17:19 -0000 On 01/07/11 16:02, Somebody in the thread at some point said: > On Fri, Jan 7, 2011 at 10:15 AM, Andy Green wrote: >> How about this alternative solution for people who think the above is >> realistic: extend the handshake to deliberately send a websocket frame which >> (accepting the intermediary has dumb HTTP parsing and ignores the framing) > Personally, I find requiring extra round trips during the handshake > far more objectionable than a small amount of per-byte processing > overhead. There is a whole extra socket establishment and HTTP transfer both ways with this method, not a simple roundtrip, so it is pretty expensive for each websocket setup while it is used. However, it will allow you to exactly perform the internet-wide probing for these alleged broken intermediaries, pretty much starting immediately. Just mandate the probe in the protocol. Whe.. I mean if it is shown these problem intermediaries don't exist, if you use a header line to warn the server you will be sending a probe packet that should be ignored, this extra connection and roundtrip can be turned off at any time compatibly. -Andy From dave@cridland.net Fri Jan 7 08:37:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4173A691E for ; Fri, 7 Jan 2011 08:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65F7-KESr-7M for ; Fri, 7 Jan 2011 08:37:00 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 6FB2D3A6917 for ; Fri, 7 Jan 2011 08:37:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id D8482116811D; Fri, 7 Jan 2011 16:39:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAWM+LqXa9al; Fri, 7 Jan 2011 16:39:01 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 7945D11680FB; Fri, 7 Jan 2011 16:39:01 +0000 (GMT) References: =?US-ASCII?Q??= <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> <00e101cbae84$2e0b7510$8a225f30$@com> In-Reply-To: <00e101cbae84$2e0b7510$8a225f30$@com> MIME-Version: 1.0 Message-Id: <10468.1294418341.486794@puncture> Date: Fri, 07 Jan 2011 16:39:01 +0000 From: Dave Cridland To: Alexander Philippou , Server-Initiated HTTP , Maciej Stachowiak Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:37:02 -0000 On Fri Jan 7 16:01:37 2011, Alexander Philippou wrote: > One large use case is non-browser client systems. I don't see how > masking will be useful to them. Masking seems to be protecting > against vulnerabilities that affect only browser client systems. No, not really. It's a vulnerability caused by the compound issue of vulnerable intermediaries hypothetically existing, plus downloadable code. So it's not "browser client systems" that are vulnerable, it's intermediaries in front of browsers which have Flash, Java, or WebSockets enabled. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dave@cridland.net Fri Jan 7 08:37:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE423A6917 for ; Fri, 7 Jan 2011 08:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXVofs-wyM50 for ; Fri, 7 Jan 2011 08:37:48 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 9CEF43A68D2 for ; Fri, 7 Jan 2011 08:37:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 24442116811E; Fri, 7 Jan 2011 16:39:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbFH4c3NrqFi; Fri, 7 Jan 2011 16:39:45 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 440E011680FB; Fri, 7 Jan 2011 16:39:45 +0000 (GMT) References: <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <20110107115604.GS28367@1wt.eu> In-Reply-To: MIME-Version: 1.0 Message-Id: <10468.1294418385.290351@puncture> Date: Fri, 07 Jan 2011 16:39:45 +0000 From: Dave Cridland To: John Tamplin , Server-Initiated HTTP , Willy Tarreau Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:37:49 -0000 On Fri Jan 7 16:09:35 2011, John Tamplin wrote: > On Fri, Jan 7, 2011 at 6:56 AM, Willy Tarreau wrote: > >  $ printf \ > >    "GET / HTTP/1.1\r\nHost: my.fake.site.com\r\nUpgrade: > WebSocket\r\n\r\n" \ > >    "GET / HTTP/1.1\r\nHost: victim.com\r\n\r\n" > > /dev/tcp/my.fake.site.com/80 > > > > So surely it will raise some interest ;-) > > And if simply clicking on a link in a browser could cause that code > to > be executed on their machine, then yes this would be equally > exploitable. But you *can* arrange for equivalent code to be executed on the machine by a click on a link - indeed, that's exactly what the experiment did. Just with Flash. The fact is that even if we did nothing at all in WebSocket to mitigate against this attack, a wannabe attacker will *still* use Flash over WebSocket as a mechanism because it'll present a far higher success rate. Mostly because Flash has a vastly greater deployment, but also because while the effects of framing might be unknown, it can only decrease the effectiveness of the attack. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From jat@google.com Fri Jan 7 08:41:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C7C3A691A for ; Fri, 7 Jan 2011 08:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.327 X-Spam-Level: X-Spam-Status: No, score=-104.327 tagged_above=-999 required=5 tests=[AWL=-2.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFR7aB3m0cOn for ; Fri, 7 Jan 2011 08:41:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id B1A3D3A68D2 for ; Fri, 7 Jan 2011 08:41:11 -0800 (PST) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p07GhHpD025763 for ; Fri, 7 Jan 2011 08:43:17 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294418597; bh=JLrdG23vsGJrR54ICjfluH7rZj8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=DChbIyzV1cpDeHvE5v6guL3Ri9sfpgiqOngNKc0AhaQ2vyboT5xBONQhUM5CbcGns duwuu/98EQFO0sqbLexsA== Received: from qyk36 (qyk36.prod.google.com [10.241.83.164]) by kpbe11.cbf.corp.google.com with ESMTP id p07GhFUM025551 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 7 Jan 2011 08:43:16 -0800 Received: by qyk36 with SMTP id 36so18793491qyk.20 for ; Fri, 07 Jan 2011 08:43:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=TPxrG5JKlCVvLpy9yZD9qDi8AN5QsJHJ9OWTb9QoYUU=; b=UWMvIqV5QD/p6/uSaPrBoU59t3Kbe63thZsLXvTCpT/+bwdI8Z6tnBVDjLgELNtwy4 2HmS9yAssl77jtd66WcQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=q0oycxEu2XvKVBWifWIxQ5ujaVfIjixlLQALVbH9amau2rvtPE5bhAOU/FbwiTvVkm JXdO5mZfpsxtN1vHY3Tg== Received: by 10.229.232.15 with SMTP id js15mr22463357qcb.136.1294418595303; Fri, 07 Jan 2011 08:43:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.106.38 with HTTP; Fri, 7 Jan 2011 08:42:55 -0800 (PST) In-Reply-To: <10468.1294418385.290351@puncture> References: <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <20110107115604.GS28367@1wt.eu> <10468.1294418385.290351@puncture> From: John Tamplin Date: Fri, 7 Jan 2011 11:42:55 -0500 Message-ID: To: Dave Cridland Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:41:12 -0000 On Fri, Jan 7, 2011 at 11:39 AM, Dave Cridland wrote: > But you *can* arrange for equivalent code to be executed on the machine by a > click on a link - indeed, that's exactly what the experiment did. Just with > Flash. > > The fact is that even if we did nothing at all in WebSocket to mitigate > against this attack, a wannabe attacker will *still* use Flash over > WebSocket as a mechanism because it'll present a far higher success rate. > Mostly because Flash has a vastly greater deployment, but also because while > the effects of framing might be unknown, it can only decrease the > effectiveness of the attack. I don't know the current status of the vulnerability in Flash/Java, but since publishing the experiment results was delayed by a couple of months to give them time to react to it, hopefully it has been or will soon be fixed. -- John A. Tamplin Software Engineer (GWT), Google From andy.warmcat.com@googlemail.com Fri Jan 7 08:49:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7332A3A691B for ; Fri, 7 Jan 2011 08:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15n04i7G-Z2L for ; Fri, 7 Jan 2011 08:49:21 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 54E803A6909 for ; Fri, 7 Jan 2011 08:49:20 -0800 (PST) Received: by wyf23 with SMTP id 23so18475721wyf.31 for ; Fri, 07 Jan 2011 08:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wF3eIw7fbfempQ++51DK2W/OJTRQxvsyMUNIIAuChHY=; b=QLl9AJUEciFfQ9U6h/wYB/j81LG5Dd6yrwy6y9Qe4rZXPnvJ9F6xSota09Hywyc49U OB+nHrC+Df7lCuj9fyRP4ne+qbpmkZwMrjUQFBUiZIw8TcEoPN8EPVKlpO+oQhTxvYw5 +lcaYz5jarIdDtIRro0+fM37y2+7EjggEvX6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=XW+rrWjk5nebS3XSWiJLDiZ1SKLtB7SiI7HhQ7GWDnhsqlVK50im2QRa1JnAuv2mwX kgarVYRHtoZrTzdBQO5A/lHzCrgmJ+jhRET1VGBtXLe0XuFqteLrroYfkp3g+6qA2UFf TUoHOoH9f3SsiTL+jgGl+6K4ilOTb12dWuJkA= Received: by 10.227.147.209 with SMTP id m17mr15616709wbv.108.1294417212267; Fri, 07 Jan 2011 08:20:12 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id 11sm17784743wbj.13.2011.01.07.08.20.10 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 08:20:11 -0800 (PST) Sender: Andy Green Message-ID: <4D273D39.4040203@warmcat.com> Date: Fri, 07 Jan 2011 16:20:09 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Greg Wilkins References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <4D26E3FB.6050206@warmcat.com> <4D272E25.9050902@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism / building in troll proxy detection to the handshake X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:49:22 -0000 On 01/07/11 16:08, Somebody in the thread at some point said: > the problem is that sending a single poisoning attack that fails does > not prove that all poisoning attacks will fail. Maybe the intermediary Some dudes are claiming that they have been going around actually poisoning caches via websocket, let's get started with their magic packet contents and reproduce their test widely using the protocol itself. -Andy From ifette@google.com Fri Jan 7 08:54:11 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A3B3A6920 for ; Fri, 7 Jan 2011 08:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.65 X-Spam-Level: X-Spam-Status: No, score=-103.65 tagged_above=-999 required=5 tests=[AWL=-1.974, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjpNbUzXDPSe for ; Fri, 7 Jan 2011 08:54:10 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 489AF3A68D0 for ; Fri, 7 Jan 2011 08:54:10 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p07GuF0I017626 for ; Fri, 7 Jan 2011 08:56:16 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294419376; bh=TTmtbvtPgLQAVmrP7Mfchy5XY8g=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=CBgM0t5nvbXt6fSVFaDX5HMBHUmhg6AE02BAp7zJROoa+bflQWduvWWeXUwCUMSLY p37NmW4Fc+B+yvnE4BZHg== Received: from qyk10 (qyk10.prod.google.com [10.241.83.138]) by kpbe12.cbf.corp.google.com with ESMTP id p07Gtqdg002089 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 7 Jan 2011 08:56:14 -0800 Received: by qyk10 with SMTP id 10so644755qyk.1 for ; Fri, 07 Jan 2011 08:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=OwoVHwjMsFIfbk4kTjOm6y+Z8c8w5eZc6/6YfRNS/Jg=; b=hu+WKQ1jJ0xWenLCQXhWnYdJ3W3dB3nfRdUeQASN+23m80qaYtYg/w4em11nKEVf7z ABGHwfJNt7F8mGEdisZg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=g23+jK468QPE5jkFUaCVQ8FalqwmKeqESChG4TFodhLnAXenSEiI9Mb/7nh+JBCLur kuy9twNdoqVXfPmAJGQg== MIME-Version: 1.0 Received: by 10.229.81.11 with SMTP id v11mr2146961qck.152.1294419374258; Fri, 07 Jan 2011 08:56:14 -0800 (PST) Received: by 10.229.0.137 with HTTP; Fri, 7 Jan 2011 08:56:14 -0800 (PST) In-Reply-To: <4D273D39.4040203@warmcat.com> References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <4D26E3FB.6050206@warmcat.com> <4D272E25.9050902@warmcat.com> <4D273D39.4040203@warmcat.com> Date: Fri, 7 Jan 2011 08:56:14 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: andy@warmcat.com Content-Type: multipart/alternative; boundary=0016364274d9fe3b280499447e4a X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism / building in troll proxy detection to the handshake X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:54:11 -0000 --0016364274d9fe3b280499447e4a Content-Type: text/plain; charset=UTF-8 On Fri, Jan 7, 2011 at 8:20 AM, Andy Green wrote: > On 01/07/11 16:08, Somebody in the thread at some point said: > > the problem is that sending a single poisoning attack that fails does >> not prove that all poisoning attacks will fail. Maybe the intermediary >> > > Some dudes are claiming that they have been going around actually poisoning > caches via websocket, let's get started with their magic packet contents and > reproduce their test widely using the protocol itself. > > Andy, you are missing the point. The point is not to stop a single known attack, the point is to come up with a solution that we can reason about and feel comfortable that we understand why such attacks in general, not a specific instance, are prevented. The general threat brought up is attackers being able to send plain-text content that can confuse intermediaries, masking is a solution that has been proposed to remove that capability from attackers. With masking, we can actually reason about why an attacker cannot do things, as opposed to just guessing at what black-box intermediaries may or may not do. -Ian > > -Andy > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016364274d9fe3b280499447e4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 7, 2011 at 8:20 AM, Andy Green <andy@warmcat.com&g= t; wrote:
On 01/07/11 16:08, Somebody in the thread at some point s= aid:

the problem is that sending a single poisoning attack that fails does
not prove that all poisoning attacks will fail. Maybe the intermediary

Some dudes are claiming that they have been going around actually poisoning= caches via websocket, let's get started with their magic packet conten= ts and reproduce their test widely using the protocol itself.


An= dy, you are missing the point. The point is not to stop a single known atta= ck, the point is to come up with a solution that we can reason about and fe= el comfortable that we understand why such attacks in general, not a specif= ic instance, are prevented. The general threat brought up is attackers bein= g able to send plain-text content that can confuse intermediaries, masking = is a solution that has been proposed to remove that capability from attacke= rs. With masking, we can actually reason about why an attacker cannot do th= ings, as opposed to just guessing at what black-box intermediaries may or m= ay not do.

-Ian
=C2=A0

-Andy
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--0016364274d9fe3b280499447e4a-- From salvatore.loreto@ericsson.com Fri Jan 7 09:36:52 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B683A68C5 for ; Fri, 7 Jan 2011 09:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.25 X-Spam-Level: X-Spam-Status: No, score=-106.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHrS7nbh2FWZ for ; Fri, 7 Jan 2011 09:36:48 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 465E13A6924 for ; Fri, 7 Jan 2011 09:36:47 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-d0-4d274faee4b1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E8.DA.23694.EAF472D4; Fri, 7 Jan 2011 18:38:54 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 7 Jan 2011 18:38:54 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B25D0297E for ; Fri, 7 Jan 2011 19:38:53 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 761B65052B for ; Fri, 7 Jan 2011 19:38:53 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0534E50488 for ; Fri, 7 Jan 2011 19:38:52 +0200 (EET) Message-ID: <4D274FAC.103@ericsson.com> Date: Fri, 7 Jan 2011 18:38:52 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> In-Reply-To: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 17:36:52 -0000 On 1/7/11 3:28 PM, Maciej Stachowiak wrote: > I have several objections to this proposal: > > 1) The idea of an extension that is, in most circumstances, mandatory for both clients and servers seems silly. If the normal use case is that you always request it from the other endpoint, and refuse the connection if the other endpoint won't use it, then it's not an extension. > 2) Designing things this way creates more risk of bugs leading to total security failure. > > 3) Some decent technical reasons have been given for why the framing should be masked as well, for example, when considering the threat model of using HTTP APIs in the browser to attack WebSocket services. > > 4) I still haven't seen evidence of a non-hypothetical use case for removing masking, so I don't think we should warp the design around the possibility. This proposal weakens the effectiveness of the masking (perhaps in minor or edge case ways) to make it easier to later address a totally unproven use case. > > Combining masking with GET+Upgrade (instead of a potentially more robust initial handshake) was already a compromise. Indeed it is a compromise for both the sides. But it is a compromise that has been largely accepted by people in the poll. No other proposals so far has received so large consensus. /Sal -- Salvatore Loreto www.sloreto.com > Now I feel that GET+Upgrade advocates are incrementally chipping away at the effectiveness of the masking. Meanwhile, CONNECT advocates have largely agreed to let go of the CONNECT handshake idea if we can at least have effective masking. I don't think this ratchet method is an effective or fair way to negotiate agreement. > > Regards, > Maciej > From ferg@caucho.com Fri Jan 7 09:43:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756763A68C5 for ; Fri, 7 Jan 2011 09:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkaQxbGj1AJZ for ; Fri, 7 Jan 2011 09:42:59 -0800 (PST) Received: from nm27.bullet.mail.sp2.yahoo.com (nm27.bullet.mail.sp2.yahoo.com [98.139.91.97]) by core3.amsl.com (Postfix) with SMTP id B1A2C3A67D0 for ; Fri, 7 Jan 2011 09:42:59 -0800 (PST) Received: from [98.139.91.69] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jan 2011 17:45:03 -0000 Received: from [98.139.91.48] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jan 2011 17:45:03 -0000 Received: from [127.0.0.1] by omp1048.mail.sp2.yahoo.com with NNFMP; 07 Jan 2011 17:45:03 -0000 X-Yahoo-Newman-Id: 861620.10571.bm@omp1048.mail.sp2.yahoo.com Received: (qmail 89619 invoked from network); 7 Jan 2011 17:45:03 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 07 Jan 2011 09:45:03 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: vTFVo9IVM1ldRX4mzHTCK.1EtZU2VP0_8Hgx5oQk_pkU3Zx 5ca3K6BgGcboSMNaiQ9L7Wb.xIaMSlEZ3SRnEjKTwuM5hDSTG6BTRcGhGggj Zu5QDOhSn9.DKJ9QHZjcYguhmAeUZ5uQ6Lv5_KHxxC0sRUhMhOJrUXkKtMsE YKq3E.dHTmB02pBP3CTiTXmWpJHrE8E7oerlk7898_hz.DnPZAlElPwifvrC pG1sPvyuKd89itbGCOJtN_zQG.jbbkl00cSdjVyMpfwaA2jjKwofsSA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D27511F.6080007@caucho.com> Date: Fri, 07 Jan 2011 09:45:03 -0800 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Willy Tarreau References: <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <20110107115604.GS28367@1wt.eu> In-Reply-To: <20110107115604.GS28367@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 17:43:00 -0000 Willy Tarreau wrote: > On Fri, Jan 07, 2011 at 11:15:28AM +0000, Dave Cridland wrote: > > >> There is some argument, much of it reasonable >> (if not absolutely convincing) that it follows that with a pure >> Upgrade-based handshake, intermediaries may "find" HTTP traffic >> within some framing. >> > > I think that all the people who are thinking that should at some > point try to write some working code to implement a real caching > intermediary. They will see that they need to check the method > and that you cannot randomly skip over garbage to presume your > method will be here or there. +1 Those arguments have been handwaving based on an ignorance of what a HTTP intermediary does. (And apparently ignorant of how framing works in general.) If framing breaks, an intermediary (or server) cannot just skip bytes in some kind of error recovery system until it find something it likes. It has to terminate the connection. That's not a security requirement; it's basic protocol requirement to avoid parsing junk. > Well, to be honnest, he did not exactly test what you are suggesting. > He compared the GET+Upgrade followed by valid HTTP requests.... In other words, the test used valid HTTP framing followed by another HTTP request. There was no test where HTTP framing was deliberately broken as it is in WebSockets. > >> Now, assuming that every single person on the whole internet has a >> proxy of some form, that would mean that 80,000 vulnerable proxies >> exist amongst the 2 billion internet users. I don't think this is a >> sufficient attack surface to worry about, especially given that these >> represent intermediaries that are already vulnerable to attacks of >> the form we're trying to protect against by using Flash or Java. >> > > And telnet, netcat, etc... No need to look for plugins when everyone > has an internet connection which is enough to abuse them. > +1 -- Scott From alex@noemax.com Fri Jan 7 09:52:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B05C3A68D5 for ; Fri, 7 Jan 2011 09:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EoIxnX-37MH for ; Fri, 7 Jan 2011 09:52:58 -0800 (PST) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by core3.amsl.com (Postfix) with ESMTP id 8E5F83A67D0 for ; Fri, 7 Jan 2011 09:52:58 -0800 (PST) Received: from HPdv73190ev by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id QSK92300; Fri, 07 Jan 2011 19:55:00 +0200 From: "Alexander Philippou" To: "'Dave Cridland'" References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> <00e101cbae84$2e0b7510$8a225f30$@com> <10468.1294418341.486794@puncture> In-Reply-To: <10468.1294418341.486794@puncture> Date: Fri, 7 Jan 2011 19:54:53 +0200 Message-ID: <010401cbae94$00b16650$021432f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuuiWgSPYZr7zmSSkq/FNNaFEefzwAAtLYA Content-Language: en-us Cc: 'Server-Initiated HTTP' Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 17:52:59 -0000 > No, not really. It's a vulnerability caused by the compound issue of = vulnerable intermediaries hypothetically existing, plus downloadable = code. So it's not "browser client systems" that are vulnerable, it's = intermediaries in front of browsers which have Flash, Java, or = WebSockets enabled. Right. So I don't see what type of protection masking will offer to a = "non-browser client system" that consists of non-browser clients, the = servers hosting the services that these clients access, and their = intermediaries. In this case both sides are tightly controlled and no = arbitrary code can be downloaded or run. I understand the = vulnerabilities when browsers are involved but don't see what is gained = by masking when there are no browsers in the picture. If WebSockets is = also to be for clients other than browsers (or more generally when = downloadable code is involved) then my opinion is that masking should = either be justified for them too or be made optional. Alexander From mjs@apple.com Fri Jan 7 09:56:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514853A67A1 for ; Fri, 7 Jan 2011 09:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wrg6Vlp1JC42 for ; Fri, 7 Jan 2011 09:56:45 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 577233A68D5 for ; Fri, 7 Jan 2011 09:56:45 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 156F4C9FDD0D for ; Fri, 7 Jan 2011 09:58:52 -0800 (PST) X-AuditID: 11807130-b7cb4ae000001037-07-4d27545b12fb Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay11.apple.com (Apple SCV relay) with SMTP id 31.F3.04151.B54572D4; Fri, 7 Jan 2011 09:58:52 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.62.4] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEN001K7ZA3ZW50@gertie.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 09:58:51 -0800 (PST) From: Maciej Stachowiak In-reply-to: <10468.1294412280.131214@puncture> Date: Fri, 07 Jan 2011 09:58:51 -0800 Message-id: References: ?= <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> <10468.1294412280.131214@puncture> To: Dave Cridland X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: Server-Initiated HTTP Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 17:56:46 -0000 On Jan 7, 2011, at 6:58 AM, Dave Cridland wrote: > On Fri Jan 7 14:28:07 2011, Maciej Stachowiak wrote: >> 3) Some decent technical reasons have been given for why the framing should be masked as well, for example, when considering the threat model of using HTTP APIs in the browser to attack WebSocket services. > > Hmmmph. If you can mimic any data as an HTTP client, then by inference you can mimic any masking, surely? No. If the correct mask includes an unpredictable string sent by the server, then it's not possible to mimic it because the client can't compute the correct mask. This is actually better than Sec-* headers, because if the server does the check in a buggy way, it won't be able to read from clients at all in the normal case. > The trick, then has to be to use restricted features like the Sec-* headers to defeat this attack at the handshake level, which we had way back when. > >> 4) I still haven't seen evidence of a non-hypothetical use case for removing masking, so I don't think we should warp the design around the possibility. This proposal weakens the effectiveness of the masking (perhaps in minor or edge case ways) to make it easier to later address a totally unproven use case. > > I still haven't seen evidence of a non-hypothetical case where masking is required. > >> Combining masking with GET+Upgrade (instead of a potentially more robust initial handshake) was already a compromise. Now I feel that GET+Upgrade advocates are incrementally chipping away at the effectiveness of the masking. Meanwhile, CONNECT advocates have largely agreed to let go of the CONNECT handshake idea if we can at least have effective masking. I don't think this ratchet method is an effective or fair way to negotiate agreement. > > CONNECT on its own fails because it is no longer correct HTTP. Pretending it is doesn't help - it breaks end-to-end transparency. > > Upgrade on its own has hypothetical - but reasonable - security arguments against it. However, in its favour, technologies like CORS should "just work", for instance. > > So, quite obviously, neither of those two options on their own work. > > Would the browser folk be interested in running an experiment to see if an Upgrade+CONNECT would work as intended? Would Google be willing to use their advertising network for such an experiment? If so, we could actually run an experiment that tested each proposal, and then for any where no attacks where found, we could select based purely on efficiency and correctness. I like your Upgrade+CONNECT proposal, and have explicitly supported it in the straw poll thread. However, even with Upgrade+CONNECT, I would still be in favor of having masking. > Basing our decision making on hypothetical vulnerabilities which have been shown to be at least sufficiently rare as to not have been found seems like a poor course of action. >From the browser vendor point of view, if we widely deploy a technology in the browser, lots of websites adopt it, and then a serious security vulnerability is found, the cost is huge. It's extremely difficult to quickly deploy security updates to a lot of users, even more so when this will break their favorite websites. In the meantime, the tech press sows fear and panic. Since we are designing a new protocol, we are not constrained by legacy yet, and can do better than the historical level of security on the Web. We can set a higher standard than "can't find a fully working exploit today through armchair reasoning" and produce a design that is likely to be robust against a wide variety of threat models. Regards, Maciej From mjs@apple.com Fri Jan 7 10:03:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39D23A68D5 for ; Fri, 7 Jan 2011 10:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqXwkdm+ikqD for ; Fri, 7 Jan 2011 10:03:43 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id A4F433A67B7 for ; Fri, 7 Jan 2011 10:03:43 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id AEB82C9FE4E1 for ; Fri, 7 Jan 2011 10:05:50 -0800 (PST) X-AuditID: 11807130-b7cb4ae000001037-13-4d2755fefb94 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay11.apple.com (Apple SCV relay) with SMTP id 23.46.04151.EF5572D4; Fri, 7 Jan 2011 10:05:50 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.62.4] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEN001RZZLQZW50@gertie.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 10:05:50 -0800 (PST) From: Maciej Stachowiak In-reply-to: Date: Fri, 07 Jan 2011 10:05:50 -0800 Message-id: References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> To: Greg Wilkins X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: Hybi Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:03:45 -0000 On Jan 7, 2011, at 7:03 AM, Greg Wilkins wrote: > On 7 January 2011 15:28, Maciej Stachowiak wrote: >> >> I have several objections to this proposal: >> >> 1) The idea of an extension that is, in most circumstances, mandatory for both clients and servers seems silly. If the normal use case is that you always request it from the other endpoint, and refuse the connection if the other endpoint won't use it, then it's not an extension. > > I don't think you can say the normal use-case will always use masking. > Sure it will for the browser, but it may be a very normal use-case > for the the connection to enter a data centre via a web-socket aware > aggregator that forwards the messages without masking to the > application server. So from the server point of view, the normal > use-case could be without masking. I put much more priority on what happens on the public Internet than what happens inside the data center, on a private network. The security of the Internet can't be subordinated to convenience of communication on private networks where security is not as much an issue. Designing "low security mode" into protocols for such use cases creates more risk than benefit, in my opinion. > > >> 2) Designing things this way creates more risk of bugs leading to total security failure. > > that's very subjective. I think that masking framing will result in > more bugs, specially with partially received frames. I'm less worried about bugs that cause a failure of functionality than security bugs. > > > >> 3) Some decent technical reasons have been given for why the framing should be masked as well, for example, when considering the threat model of using HTTP APIs in the browser to attack WebSocket services. > > I do not think that threat has been well explained or accepted, nor is > it the primary target of masking. Specifically I've not yet seen a > credible explanation of how a HTTP API could generate the required > headers to get past the websockets expectations of the initial upgrade > request. I don't want to dismiss this vulnerability out of hand, but > I would like to see more detail about it and to consider if there are > other mitigations we could do that would not impede the progress we > were making on masking. I've posted about it many times now, with varying levels of detail. I'll try to write something up about the various cross-protocol threat models on the wiki. > > > >> 4) I still haven't seen evidence of a non-hypothetical use case for removing masking, so I don't think we should warp the design around the possibility. This proposal weakens the effectiveness of the masking (perhaps in minor or edge case ways) to make it easier to later address a totally unproven use case. > > Unfortunately there are some that see the hypothetical risk of these > intermediaries as warping the design with the introduction of masking. > > Beside, there have been many use-case presented (eg the aggregator > above) that would benefit from no masking. I know you think that > masking is cheap - and it may be in the client, but there are many > opinions on the intermediary/server side that are concerned about the > cost of masking and thus there is a drive to have it as simple and > cheap as possible, if not optional. > > >> Combining masking with GET+Upgrade (instead of a potentially more robust initial handshake) was already a compromise. Now I feel that GET+Upgrade advocates are incrementally chipping away at the effectiveness of the masking. Meanwhile, CONNECT advocates have largely agreed to let go of the CONNECT handshake idea if we can at least have effective masking. I don't think this ratchet method is an effective or fair way to negotiate agreement. > > I don't think that is a fair or productive characterisation. I > could equally say that masking advocates are incrementally increasing > the scope and complexity of masking from the simple prevention of > clear text originally proposed and adding new unproven hypothetical > vulnerabilities - which would also be neither fair or productive. Nothing has been added to the masking proposal since it was originally proposed. It has only been simplified. > > There is no benefit in having masking unless it is seen to be > effective, so it is in nobodies interests to chip away at the > effectiveness of masking. I truly do not understand why having the > payload XOR's with a random per frame key will not be effective at > preventing attackers sending clear text. Nor do I understand why > having masking as an extension reduces it's effectiveness in any way. > > > I get it that you'd greatly prefer masking to not be an extension, but > in the spirit of compromise, what aspect of masking as an extension is > a show stopper for you? Security features should not be optional, they should be mandatory. Using extensions, a mechanism designed for optional features, and then layering requirements on top of that to make masking still be required in the normal case, is needlessly fragile and needlessly complex. I don't agree with adding that fragility without a corresponding benefit. Regards, Maciej From mjs@apple.com Fri Jan 7 10:05:55 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE01D3A6924 for ; Fri, 7 Jan 2011 10:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNiN3boIa+vC for ; Fri, 7 Jan 2011 10:05:55 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id AA1703A6914 for ; Fri, 7 Jan 2011 10:05:54 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 4D77AC562BD1 for ; Fri, 7 Jan 2011 10:08:01 -0800 (PST) X-AuditID: 11807134-b7cfdae000001831-50-4d2756813367 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id 68.6F.06193.186572D4; Fri, 7 Jan 2011 10:08:01 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.62.4] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEN00LV9ZPCI360@et.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 10:08:01 -0800 (PST) From: Maciej Stachowiak In-reply-to: <00e101cbae84$2e0b7510$8a225f30$@com> Date: Fri, 07 Jan 2011 10:07:59 -0800 Message-id: <39D3C73F-3BB4-4EBD-B6D3-C3159C9A5B23@apple.com> References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> <00e101cbae84$2e0b7510$8a225f30$@com> To: Alexander Philippou X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: 'Hybi' Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:05:55 -0000 On Jan 7, 2011, at 8:01 AM, Alexander Philippou wrote: >> 4) I still haven't seen evidence of a non-hypothetical use case for removing masking, so I don't think we should warp the design around the possibility. This proposal weakens the effectiveness of the masking (perhaps in minor or edge case ways) to make it easier to later address a totally unproven use case. > > One large use case is non-browser client systems. I don't see how masking will be useful to them. Masking seems to be protecting against vulnerabilities that affect only browser client systems. Unless there is evidence that these protection mechanisms have a universal usefulness, I would strongly support a design that keeps them as an optional extension. Note that the proposal under discussion was to make masking a mandatory extension that is always on on both client and server side, and can only be turned off through explicit configuration of the server. I don't see how that helps your use case, unless you have a server that exists only for non-browser clients and can't be accessed at all through browsers. In which case, it's not obvious why you'd want to use WebSocket protocol instead of raw TCP. Regards, Maciej From mjs@apple.com Fri Jan 7 10:08:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73CFE3A6935 for ; Fri, 7 Jan 2011 10:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOe7Luy1IE9O for ; Fri, 7 Jan 2011 10:08:21 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id A6BF13A691A for ; Fri, 7 Jan 2011 10:08:21 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id B2D91C562DD4 for ; Fri, 7 Jan 2011 10:10:28 -0800 (PST) X-AuditID: 11807130-b7cb4ae000001037-19-4d275714a1a9 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay11.apple.com (Apple SCV relay) with SMTP id 89.77.04151.417572D4; Fri, 7 Jan 2011 10:10:28 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.62.4] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEN00LY7ZTGI360@et.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 10:10:28 -0800 (PST) From: Maciej Stachowiak In-reply-to: <10468.1294411308.608117@puncture> Date: Fri, 07 Jan 2011 10:10:28 -0800 Message-id: References: <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <10468.1294411308.608117@puncture> To: Dave Cridland X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: Server-Initiated HTTP Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:08:22 -0000 On Jan 7, 2011, at 6:41 AM, Dave Cridland wrote: > On Fri Jan 7 14:34:39 2011, Maciej Stachowiak wrote: >> On Jan 6, 2011, at 10:38 PM, Willy Tarreau wrote: >> > On Thu, Jan 06, 2011 at 10:16:55PM -0800, Eric Rescorla wrote: >> >>> Well, at 1 million concurrent connections with a 5s think time, that's >> >>> about >> >>> 200k frames per second, it starts to be concerning even if it's cheap. >> >> >> >> My dinky Macbook Air does one million SHA-1 ops/second on a single core. >> > >> > That means a 20% CPU overhead imposed by masking then. >> I would hope a server handling 1 million concurrent connections is considerably more powerful than a single core of a MacBook Air. > > It'd have to be because of the masking. > > The thing is, I can quite easily see cases where BOSH or some other long-poll is going to be more efficient for servers to handle just because of the masking overhead. A more plausible server configuration could probably do at least an order of magnitude better on SHA-1 ops/sec, which would lower the overhead to 2%, given these assumptions. Would you consider that unacceptable overhead? Regards, Maciej From jat@google.com Fri Jan 7 10:28:14 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05CC3A67A1 for ; Fri, 7 Jan 2011 10:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.289 X-Spam-Level: X-Spam-Status: No, score=-104.289 tagged_above=-999 required=5 tests=[AWL=-2.312, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4pF-M7z9h60 for ; Fri, 7 Jan 2011 10:28:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id C40933A6825 for ; Fri, 7 Jan 2011 10:28:13 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p07IUJ9V011454 for ; Fri, 7 Jan 2011 10:30:19 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294425019; bh=gVbvVBUAjZW4q2c46KF43DvXxUY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=V3KxXtJeMqthCACA8oHE3KAGDAMr2OfVCGu6SVvGa9OVHd58I2byXsH0Ytl21QGs+ BagEjlbGmVJGx6T5yw/EA== Received: from yic24 (yic24.prod.google.com [10.243.65.152]) by hpaq1.eem.corp.google.com with ESMTP id p07ITlqG010903 for ; Fri, 7 Jan 2011 10:30:18 -0800 Received: by yic24 with SMTP id 24so4513687yic.39 for ; Fri, 07 Jan 2011 10:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=49f5W2+uu8yfuXkcgRs4kwvbsEUpSu1T+UQXMqhW80s=; b=xNCwWa5kBmrt5/jdTHOycE8SZez5Jw2SONdhPIe1FAmoX8GmARIvuO/8BKs3Nhz+BX hzoecpwkJL1mgCEXxvxg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Ts2XOYTvFdLieBQcbn10ZU6S/tsdTcWlI4rwFAnPo/h/FiUFGf7nqRY53vERQfdNjJ OYBnngc/P7sjqJCwHqqQ== Received: by 10.150.91.18 with SMTP id o18mr25999367ybb.92.1294425018256; Fri, 07 Jan 2011 10:30:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Fri, 7 Jan 2011 10:29:57 -0800 (PST) In-Reply-To: References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> From: John Tamplin Date: Fri, 7 Jan 2011 13:29:57 -0500 Message-ID: To: Maciej Stachowiak Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:28:14 -0000 On Fri, Jan 7, 2011 at 1:05 PM, Maciej Stachowiak wrote: > Security features should not be optional, they should be mandatory. Using extensions, > a mechanism designed for optional features, and then layering requirements on top of > that to make masking still be required in the normal case, is needlessly fragile and > needlessly complex. I don't agree with adding that fragility without a corresponding benefit. The benefit would hopefully be that we can agree on it, ship it, and move on to the next thing. Given the entrenched positions, it isn't clear to me that we can achieve consensus on masking not implemented as a mandatory extension. -- John A. Tamplin Software Engineer (GWT), Google From gregw@intalio.com Fri Jan 7 10:32:21 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA103A691D for ; Fri, 7 Jan 2011 10:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dwzBe0Tu8a9 for ; Fri, 7 Jan 2011 10:32:20 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 1571E3A6906 for ; Fri, 7 Jan 2011 10:32:19 -0800 (PST) Received: by qwi2 with SMTP id 2so2318733qwi.31 for ; Fri, 07 Jan 2011 10:34:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.214.71 with SMTP id gz7mr10604833qab.349.1294425266434; Fri, 07 Jan 2011 10:34:26 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Fri, 7 Jan 2011 10:34:26 -0800 (PST) In-Reply-To: References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> Date: Fri, 7 Jan 2011 19:34:26 +0100 X-Google-Sender-Auth: 3QE0Y11_0deLE1QeoImQHQoBo3Y Message-ID: From: Greg Wilkins To: Maciej Stachowiak Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:32:21 -0000 Maciej, nobody is saying that masking should not be mandatory for situations where there is the possibility of this class of security vulnerability. Nobody is suggesting prioritising data centre convenience over security. This is not a contest of opposites. I believe that there must be a way that we can have mandatory masking for browsers that is suitably robust without sacrificing the flexibility of the intermediaries, servers and non client browsers. Are there any actual security flaws in the proposal that I have made? From mjs@apple.com Fri Jan 7 10:45:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2944C3A6938 for ; Fri, 7 Jan 2011 10:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDUPokJNSonF for ; Fri, 7 Jan 2011 10:45:38 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 572D53A6935 for ; Fri, 7 Jan 2011 10:45:38 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 48D54C564BC3 for ; Fri, 7 Jan 2011 10:47:45 -0800 (PST) X-AuditID: 11807130-b7cb4ae000001037-20-4d275fd1f905 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id 89.62.04151.1DF572D4; Fri, 7 Jan 2011 10:47:45 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.62.4] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEO00IEO1JKDG40@elliott.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 10:47:45 -0800 (PST) From: Maciej Stachowiak In-reply-to: Date: Fri, 07 Jan 2011 10:47:44 -0800 Message-id: References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> To: John Tamplin X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: Hybi Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:45:39 -0000 On Jan 7, 2011, at 10:29 AM, John Tamplin wrote: > On Fri, Jan 7, 2011 at 1:05 PM, Maciej Stachowiak wrote: >> Security features should not be optional, they should be mandatory. Using extensions, >> a mechanism designed for optional features, and then layering requirements on top of >> that to make masking still be required in the normal case, is needlessly fragile and >> needlessly complex. I don't agree with adding that fragility without a corresponding benefit. > > The benefit would hopefully be that we can agree on it, ship it, and > move on to the next thing. > > Given the entrenched positions, it isn't clear to me that we can > achieve consensus on masking > not implemented as a mandatory extension. It doesn't seem like we have consensus on making it a mandatory extension either. - Maciej From w@1wt.eu Fri Jan 7 10:56:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28C63A6819 for ; Fri, 7 Jan 2011 10:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAHbOxBHetuK for ; Fri, 7 Jan 2011 10:56:00 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 644563A67A1 for ; Fri, 7 Jan 2011 10:55:59 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p07Iw1aO001682; Fri, 7 Jan 2011 19:58:01 +0100 Date: Fri, 7 Jan 2011 19:58:01 +0100 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20110107185801.GB32612@1wt.eu> References: <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:56:00 -0000 On Fri, Jan 07, 2011 at 06:34:39AM -0800, Maciej Stachowiak wrote: > > On Jan 6, 2011, at 10:38 PM, Willy Tarreau wrote: > > > On Thu, Jan 06, 2011 at 10:16:55PM -0800, Eric Rescorla wrote: > >>> Well, at 1 million concurrent connections with a 5s think time, that's > >>> about > >>> 200k frames per second, it starts to be concerning even if it's cheap. > >> > >> My dinky Macbook Air does one million SHA-1 ops/second on a single core. > > > > That means a 20% CPU overhead imposed by masking then. > > I would hope a server handling 1 million concurrent connections is considerably more powerful than a single core of a MacBook Air. Handling connections is not a matter of having a big CPU bit just large amounts of RAM. What's important is to consider the cost of doing things that are sometimes not needed at all. Doing an HMAC-SHA1 will involve 2 SHA1 operations (40% CPU above, I forgot the factor of two). As Eric said, the operation by itself can be relatively cheap, but still it's a lot more expensive than the work that was supposed to be done. In short, instead of doing this in a front proxy : read(in, buf, 10); length = parse_length(buf); write(out, buf, 10); splice(in, out, length - 10); with parse_length() basically adding a few bytes with a few if that way : length = buf[1] & 0x7F; if (length == 0x7E) length = (buf[2] << 8) + buf[3]; else if (length == 0x7F) length = (buf[2] << 56) + (buf[3] << 48) + ... buf[9]; return length; You'll have to run something like this : read(in, rnd, 6); // assuming we'd use 6 bytes for the key key = compute_hmac_sha1(c_nonce, s_nonce, frame_num, rnd); read(in, buf, 10); decode(buf, tmp, key, 10); length = parse_length(tmp); write(out, rnd, 6); write(out, buf, 10); splice(in, out, length - 10); The hmac computation above while not a big deal still represents a substantial cost compared to the simple decoding and short read/writes. Once again, I'm not saying it's a big blocking issue, I'm saying that it's way overkill to protect the 6 bytes that reprenset the smallest supposedly vulnerable request we can think of (having a key larger than the data to hide brings nothing, and we don't want to prevent anybody from deciphering the stream, we just want it to be non-deterministic from the server's POV). Regards, Willy From ekr@rtfm.com Fri Jan 7 10:58:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719333A6921 for ; Fri, 7 Jan 2011 10:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.405 X-Spam-Level: X-Spam-Status: No, score=-101.405 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwsmvgiH6iY4 for ; Fri, 7 Jan 2011 10:58:56 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 3B6F33A67A1 for ; Fri, 7 Jan 2011 10:58:56 -0800 (PST) Received: by gwj17 with SMTP id 17so9438953gwj.31 for ; Fri, 07 Jan 2011 11:01:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.83.18 with SMTP id k18mr3622250agl.79.1294426862595; Fri, 07 Jan 2011 11:01:02 -0800 (PST) Received: by 10.90.154.19 with HTTP; Fri, 7 Jan 2011 11:01:02 -0800 (PST) In-Reply-To: <20110107185801.GB32612@1wt.eu> References: <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> Date: Fri, 7 Jan 2011 11:01:02 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=0016e6407c64552d770499463d49 Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:58:57 -0000 --0016e6407c64552d770499463d49 Content-Type: text/plain; charset=ISO-8859-1 We're going around in circles. It's your position that masking with a keystream as long as the message is overkill. It's my position that the alternative you're pushing isn't demonstrably secure. Obviously, I'm not convincing you and your arguments certainly haven't convinced me. I'm now going to stop responding on this point until something new is said. Please do not take that as agreement with your position. It is not. -Ekr On Fri, Jan 7, 2011 at 10:58 AM, Willy Tarreau wrote: > On Fri, Jan 07, 2011 at 06:34:39AM -0800, Maciej Stachowiak wrote: > > > > On Jan 6, 2011, at 10:38 PM, Willy Tarreau wrote: > > > > > On Thu, Jan 06, 2011 at 10:16:55PM -0800, Eric Rescorla wrote: > > >>> Well, at 1 million concurrent connections with a 5s think time, > that's > > >>> about > > >>> 200k frames per second, it starts to be concerning even if it's > cheap. > > >> > > >> My dinky Macbook Air does one million SHA-1 ops/second on a single > core. > > > > > > That means a 20% CPU overhead imposed by masking then. > > > > I would hope a server handling 1 million concurrent connections is > considerably more powerful than a single core of a MacBook Air. > > Handling connections is not a matter of having a big CPU bit just large > amounts of RAM. What's important is to consider the cost of doing things > that are sometimes not needed at all. Doing an HMAC-SHA1 will involve 2 > SHA1 operations (40% CPU above, I forgot the factor of two). As Eric said, > the operation by itself can be relatively cheap, but still it's a lot more > expensive than the work that was supposed to be done. In short, instead of > doing this in a front proxy : > > read(in, buf, 10); > length = parse_length(buf); > write(out, buf, 10); > splice(in, out, length - 10); > > with parse_length() basically adding a few bytes with a few if that way : > > length = buf[1] & 0x7F; > if (length == 0x7E) > length = (buf[2] << 8) + buf[3]; > else if (length == 0x7F) > length = (buf[2] << 56) + (buf[3] << 48) + ... buf[9]; > return length; > > You'll have to run something like this : > > read(in, rnd, 6); // assuming we'd use 6 bytes for the key > key = compute_hmac_sha1(c_nonce, s_nonce, frame_num, rnd); > read(in, buf, 10); > decode(buf, tmp, key, 10); > length = parse_length(tmp); > write(out, rnd, 6); > write(out, buf, 10); > splice(in, out, length - 10); > > The hmac computation above while not a big deal still represents a > substantial cost compared to the simple decoding and short read/writes. > > Once again, I'm not saying it's a big blocking issue, I'm saying that > it's way overkill to protect the 6 bytes that reprenset the smallest > supposedly vulnerable request we can think of (having a key larger than > the data to hide brings nothing, and we don't want to prevent anybody > from deciphering the stream, we just want it to be non-deterministic > from the server's POV). > > Regards, > Willy > > --0016e6407c64552d770499463d49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We're going around in circles.

It's your positio= n that masking with a keystream as long as the message is overkill. It'= s my position
that the alternative you're=A0pushing isn't= demonstrably secure. Obviously, I'm not convincing you
and your arguments certainly haven't convinced me. I'm now goi= ng to stop responding on this
point until something new is said. = Please do not take that as agreement with your position. It is
not.

-Ekr


On Fri, Jan 7, 2011 at 10:58 AM, Willy Tarreau <w@1wt.eu> wrote:
=
On Fri, Jan 07, 2011 at 06:34:39AM -0800,= Maciej Stachowiak wrote:
>
> On Jan 6, 2011, at 10:38 PM, Willy Tarreau wrote:
>
> > On Thu, Jan 06, 2011 at 10:16:55PM -0800, Eric Rescorla wrote: > >>> Well, at 1 million concurrent connections with a 5s think= time, that's
> >>> about
> >>> 200k frames per second, it starts to be concerning even i= f it's cheap.
> >>
> >> My dinky Macbook Air does one million SHA-1 ops/second on a s= ingle core.
> >
> > That means a 20% CPU overhead imposed by masking then.
>
> I would hope a server handling 1 million concurrent connections is con= siderably more powerful than a single core of a MacBook Air.

Handling connections is not a matter of having a big CPU bit ju= st large
amounts of RAM. What's important is to consider the cost of doing thing= s
that are sometimes not needed at all. Doing an HMAC-SHA1 will involve 2
SHA1 operations (40% CPU above, I forgot the factor of two). As Eric said,<= br> the operation by itself can be relatively cheap, but still it's a lot m= ore
expensive than the work that was supposed to be done. In short, instead of<= br> doing this in a front proxy :

=A0 read(in, buf, 10);
=A0 length =3D parse_length(buf);
=A0 write(out, buf, 10);
=A0 splice(in, out, length - 10);

with parse_length() basically adding a few bytes with a few if that way :
=A0 length =3D buf[1] & 0x7F;
=A0 if (length =3D=3D 0x7E)
=A0 =A0 =A0length =3D (buf[2] << 8) + buf[3];
=A0 else if (length =3D=3D 0x7F)
=A0 =A0 =A0length =3D (buf[2] << 56) + (buf[3] << 48) + ... bu= f[9];
=A0 return length;

You'll have to run something like this :

=A0 read(in, rnd, 6); =A0// assuming we'd use 6 bytes for the key
=A0 key =3D compute_hmac_sha1(c_nonce, s_nonce, frame_num, rnd);
=A0 read(in, buf, 10);
=A0 decode(buf, tmp, key, 10);
=A0 length =3D parse_length(tmp);
=A0 write(out, rnd, 6);
=A0 write(out, buf, 10);
=A0 splice(in, out, length - 10);

The hmac computation above while not a big deal still represents a
substantial cost compared to the simple decoding and short read/writes.

Once again, I'm not saying it's a big blocking issue, I'm sayin= g that
it's way overkill to protect the 6 bytes that reprenset the smallest supposedly vulnerable request we can think of (having a key larger than
the data to hide brings nothing, and we don't want to prevent anybody from deciphering the stream, we just want it to be non-deterministic
from the server's POV).

Regards,
Willy


--0016e6407c64552d770499463d49-- From salvatore.loreto@ericsson.com Fri Jan 7 12:33:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20DCA3A6950 for ; Fri, 7 Jan 2011 12:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOFC4Q+LM-wK for ; Fri, 7 Jan 2011 12:33:55 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 092313A67F4 for ; Fri, 7 Jan 2011 12:33:53 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-c0-4d27792f0a3b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 79.E2.23694.F29772D4; Fri, 7 Jan 2011 21:35:59 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 7 Jan 2011 21:36:00 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 68CAF297E for ; Fri, 7 Jan 2011 22:35:59 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2906F5052B for ; Fri, 7 Jan 2011 22:35:59 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8B0E250488 for ; Fri, 7 Jan 2011 22:35:58 +0200 (EET) Message-ID: <4D27792E.2070902@ericsson.com> Date: Fri, 7 Jan 2011 21:35:58 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010209040303090800020904" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:33:57 -0000 --------------010209040303090800020904 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 1/7/11 7:47 PM, Maciej Stachowiak wrote: > On Jan 7, 2011, at 10:29 AM, John Tamplin wrote: > >> On Fri, Jan 7, 2011 at 1:05 PM, Maciej Stachowiak wrote: >>> Security features should not be optional, they should be mandatory. Using extensions, >>> a mechanism designed for optional features, and then layering requirements on top of >>> that to make masking still be required in the normal case, is needlessly fragile and >>> needlessly complex. I don't agree with adding that fragility without a corresponding benefit. a possible benefit from the John proposal is that one has *the freedom* to use the type of masking he want, the one he think is the better or the stronger... if hmac-sha1 is not enough strong for him. 1) Define a new extension "clientmask" in the base spec, which specifies that client->server masking is present. An optional parameter "type" specifies the type of masking, and if not present defaults to "hmac-sha1". /Sal >> The benefit would hopefully be that we can agree on it, ship it, and >> move on to the next thing. >> >> Given the entrenched positions, it isn't clear to me that we can >> achieve consensus on masking >> not implemented as a mandatory extension. > It doesn't seem like we have consensus on making it a mandatory extension either. > > - Maciej > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --------------010209040303090800020904 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 1/7/11 7:47 PM, Maciej Stachowiak wrote: 
On Jan 7, 2011, at 10:29 AM, John Tamplin wrote:


On Fri, Jan 7, 2011 at 1:05 PM, Maciej Stachowiak <mjs@apple.com> wrote:

Security features should not be optional, they should be mandatory. Using extensions,
a mechanism designed for optional features, and then layering requirements on top of
that to make masking still be required in the normal case, is needlessly fragile and
needlessly complex. I don't agree with adding that fragility without a corresponding benefit.
a possible benefit from the John proposal is that one has *the freedom* to use the type of masking he want,
the one he think is the better or the stronger... if hmac-sha1 is not enough strong for him.

1) Define a new extension "clientmask" in the base spec, which
   specifies that client->server masking is present.  An optional
   parameter "type" specifies the type of masking, and if not
   present defaults to "hmac-sha1".

/Sal

The benefit would hopefully be that we can agree on it, ship it, and
move on to the next thing.

Given the entrenched positions, it isn't clear to me that we can
achieve consensus on masking
not implemented as a mandatory extension.

It doesn't seem like we have consensus on making it a mandatory extension either.

 - Maciej

_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi


--------------010209040303090800020904-- From w@1wt.eu Fri Jan 7 12:37:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96ABE3A6945 for ; Fri, 7 Jan 2011 12:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odLtr7sIyrG2 for ; Fri, 7 Jan 2011 12:37:55 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 5BE523A6832 for ; Fri, 7 Jan 2011 12:37:55 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p07KdwVN002169; Fri, 7 Jan 2011 21:39:58 +0100 Date: Fri, 7 Jan 2011 21:39:58 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110107203958.GC32612@1wt.eu> References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:37:56 -0000 On Fri, Jan 07, 2011 at 11:01:02AM -0800, Eric Rescorla wrote: > We're going around in circles. > > It's your position that masking with a keystream as long as the message is > overkill. It's my position that the alternative you're pushing isn't > demonstrably secure. Obviously, I'm not convincing you and your arguments > certainly haven't convinced me. I'm now going to stop responding on this > point until something new is said. Please do not take that as agreement with > your position. It is not. Eric, you're probably the one who knows all the theory around crypto better than anyone else here, still you don't explain what elements you're using for your choices, so it's very hard to understand some key points behind that, and it's normal to challenge them especially when the proposals come with a cost. If you have a reason to think that a long and complexly built key is more efficient at preventing someone to make a 48-bit long text appear in a stream than it is using a 48-bit key, then please explain to us why. At my level of knowledge, we're sure to make that choosen text appear if we send all possible 48-bit patterns, whatever the key length, key value and crypto method used. That means that sending 6*2^48 = 1.6 PB of payload *will* definitely make the choosen text appear. For this reason I fail to understand the point of using larger keys. I believe you said that 32-bit was not long enough for you, but I fail to understand how you can reliably make the message appear without exhausting the key space. Even if we assumed that clever constructs might create sequences which can match under multiple forms, you'd still have to send at least 4 GB of data to cover the entire key space (I even suspect it's 4G+1 though I cannot demonstrate it). I even proposed variable key lengths so that the size required to exhaust the key space would always be larger than the largest possible message. This is something which makes sense to me, but maybe I'm wrong. You often ask for provably secure systems. I try to show with my little knowledge that the risks are in line with the context, but you just keep saying I'm wrong without even a piece of explanation. Right now we're just with "I would be more comfortable with this or that". I know that intuition from experience is something to be taken into account, but we are talking about finite systems, so we should be able to talk about quantities. Finally I end up doing the maths myself while I'm not the one skilled to that task. That's not a fair way of participating and making progress. So please explain me why you think I'm wrong if you do, and if it convinces me, it will at least stop me from defending a mechanism you don't agree with and it might educate me as well as possibly other persons here. Thank you, Willy From w@1wt.eu Fri Jan 7 12:42:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66573A6940 for ; Fri, 7 Jan 2011 12:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9GOY6JJ79n1 for ; Fri, 7 Jan 2011 12:42:50 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 725F63A6920 for ; Fri, 7 Jan 2011 12:42:50 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p07KissB002208; Fri, 7 Jan 2011 21:44:54 +0100 Date: Fri, 7 Jan 2011 21:44:54 +0100 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20110107204454.GD32612@1wt.eu> References: <4D17B5FF.5060209@callenish.com> <41249E48-B17E-47C7-9340-6F95B85182CD@apple.com> <20110107055244.GH28367@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:42:51 -0000 On Fri, Jan 07, 2011 at 06:20:09AM -0800, Maciej Stachowiak wrote: > > On Jan 6, 2011, at 9:52 PM, Willy Tarreau wrote: > > > On Mon, Dec 27, 2010 at 04:30:43PM -0800, Maciej Stachowiak wrote: > >>> But I'm strongly against masking the framing itself. Their is > >>> absolutely no reason for it other than to prevent the possibility of > >>> making it optional. > >> > >> That's not right. One reason for masking the framing is to make it impossible for hostile browser-hosted hosted code to pre-generate valid-looking frames. If you don't mask framing, then it is trivial to create valid-looking frames, even if the contents are scrambled. Depending on circumstances, this could still be a dangerous attack on integrity. > > > > No Maciej, it's not "trivial" to do that because if you look at the framing, > > very little of it is directly controlled by the application. As I suggested > > in another mail, if you use RSV4 to indicate masking is used and put the > > random key in extension data, that leaves you with : > > - first byte with MORE|RSV1|RSV2|RSV3|OPCODE = 1|XXX|OPCODE > > - second byte with RSV4|LENGTH = 1|LENGTH > > - 3rd-4th bytes corresponding to the low part of the payload length, > > only if previous byte is 0xFE/0xFF > > - 5-10th bytes corresponding to the high part of the payload length > > only if 2nd byte is 0xFF > > - random key the size of the payload length > > - application data > > > > The only controllable part here in which you might put an HTTP request is > > the key length. But even in order to write an HTTP/0.9 "GET /\n", you have > > to forge a message that is 0x54202F0A4745 bytes long, or 92 TeraBytes long. > > And if you need to start it at the beginning of a line, it becomes > > 0x4554202F0A0A47 which is 19 PetaBytes. By the time we get browsers able to > > construct that large messages, we won't bother anymore about the broken > > intermediaries. > > > > That's why I'm really considering masking the payload safe enough with > > regards to the risk we're trying to cover. > > Willy, I think we're talking past each other. The threat model I'm talking about involves using HTTP APIs to connect to WebSocket servers. HTTP APIs in the browser will effectively let you send any bytes you want as the payload. You seem to be talking about the opposite threat model, where WebSocket APIs in the browser, to attack HTTP. Yes, I am. That's why we're discussing about having masking on by default on the WS client, so that it cannot decide what the bytes will look like on the wire. The HTTP API vs WS server was addressed a while ago with the Sec-* headers that the HTTP API was supposed not to be able to send. > These are completely separate threat models, and both are important to consider. Yes, I agree and you're right to remind each one's goal to clarify the discussion. Thanks, Willy From ekr@rtfm.com Fri Jan 7 13:17:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13FD3A6935 for ; Fri, 7 Jan 2011 13:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cJHPMGnbJaA for ; Fri, 7 Jan 2011 13:17:07 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 7454F3A6832 for ; Fri, 7 Jan 2011 13:17:07 -0800 (PST) Received: by yxt33 with SMTP id 33so7775172yxt.31 for ; Fri, 07 Jan 2011 13:19:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.232.6 with SMTP id e6mr28700693agh.52.1294435153792; Fri, 07 Jan 2011 13:19:13 -0800 (PST) Received: by 10.90.154.19 with HTTP; Fri, 7 Jan 2011 13:19:13 -0800 (PST) In-Reply-To: <20110107203958.GC32612@1wt.eu> References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> Date: Fri, 7 Jan 2011 13:19:13 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=001636284f6086d12b0499482bdb Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:17:08 -0000 --001636284f6086d12b0499482bdb Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 7, 2011 at 12:39 PM, Willy Tarreau wrote: > On Fri, Jan 07, 2011 at 11:01:02AM -0800, Eric Rescorla wrote: > > We're going around in circles. > > > > It's your position that masking with a keystream as long as the message > is > > overkill. It's my position that the alternative you're pushing isn't > > demonstrably secure. Obviously, I'm not convincing you and your arguments > > certainly haven't convinced me. I'm now going to stop responding on this > > point until something new is said. Please do not take that as agreement > with > > your position. It is not. > > Eric, you're probably the one who knows all the theory around crypto better > than anyone else here, still you don't explain what elements you're using > for your choices, so it's very hard to understand some key points behind > that, and it's normal to challenge them especially when the proposals come > with a cost. If you have a reason to think that a long and complexly built > key is more efficient at preventing someone to make a 48-bit long text > appear > in a stream than it is using a 48-bit key, then please explain to us why. > I don't know what a "long and complexly built key" means, but I think I've explained myself several times. My objective is to make the bits that appear on the wire indistinguishable from random from the attacker's perspective. I think it's clear that this is the strongest form of masking available, and the method I proposed does that. A sliding mask does not produce this result because it means that an attacker can have any relationship he wants between bits which appear at the same offset in the mask. As I've now said a number of times, I am unaware of an attack which exploits this property, but that does not mean there isn't one, and so I prefer to have a stronger mechanism. It's important to recognize that this is a distinct question from the *entropy* of the mask. For instance. if you start with a 32-bit random seed and use that to generate an arbitrarily long mask, this provides more resistance to the above property than just using the key directly as a repeating mask. Which is precisely the point of using an expansion function for the mask (whether HMAC-SHA1, or AES-CTR). > Finally I end up doing the maths myself while I'm not the one skilled to > that task. That's not a fair way of participating and making progress. I'm sorry, but this is simply nonsense. I've explained my position. If you're not convinced, that's fine, but there's nothing "unfair" about my refusal to engage in an endless discussion about it. -Ekr --001636284f6086d12b0499482bdb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 7, 2011 at 12:39 PM, Willy T= arreau <w@1wt.eu> wrote:
On Fri, Jan 07, 2011 at 11:01:02AM -0800, Eric Rescorla w= rote:
> We're going around in circles.
>
> It's your position that masking with a keystream as long as the me= ssage is
> overkill. It's my position that the alternative you're pushing= isn't
> demonstrably secure. Obviously, I'm not convincing you and your ar= guments
> certainly haven't convinced me. I'm now going to stop respondi= ng on this
> point until something new is said. Please do not take that as agreemen= t with
> your position. It is not.

Eric, you're probably the one who knows all the theory around cry= pto better
than anyone else here, still you don't explain what elements you're= using
for your choices, so it's very hard to understand some key points behin= d
that, and it's normal to challenge them especially when the proposals c= ome
with a cost. If you have a reason to think that a long and complexly built<= br> key is more efficient at preventing someone to make a 48-bit long text appe= ar
in a stream than it is using a 48-bit key, then please explain to us why.

I don't know what a "long and c= omplexly built key" means, but I think I've explained
myself several times.

My objective is to make the = bits that appear on the wire indistinguishable from random
from t= he attacker's perspective. I think it's clear that this is the stro= ngest form of masking
available, and the method I proposed does that. A sliding mask does no= t produce this
result because it means that an attacker can have = any relationship he wants between
bits which appear at the same o= ffset in the mask. As I've now said a number of times,
I am unaware of an attack which exploits this property, but that does = not mean there
isn't one, and so I prefer to have a stronger = mechanism.

It's important to recognize that th= is is a distinct question from the *entropy* of the=A0
mask. For instance. if you start with a 32-bit random seed and use tha= t to generate
an arbitrarily long mask, this provides more resist= ance to the above property than=A0
just using the key directly as= a repeating mask. Which is precisely the point of using
an expansion function for the mask (whether HMAC-SHA1, or AES-CTR).


Finally I end up doing the maths myself while I'm not the one skilled t= o
that task. That's not a fair way of participating and making progress. =

I'm sorry, but this is simply nonsense= . I've explained my position. If you're not convinced,
that's fine, but there's nothing "unfair" about my refusa= l to engage in an endless discussion
about it.

-Ekr

--001636284f6086d12b0499482bdb-- From ferg@caucho.com Fri Jan 7 13:21:17 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5248D3A68C5 for ; Fri, 7 Jan 2011 13:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3rjw+GkTi+A for ; Fri, 7 Jan 2011 13:21:15 -0800 (PST) Received: from nm17.bullet.mail.ac4.yahoo.com (nm17.bullet.mail.ac4.yahoo.com [98.139.52.214]) by core3.amsl.com (Postfix) with SMTP id 580423A6946 for ; Fri, 7 Jan 2011 13:21:04 -0800 (PST) Received: from [98.139.52.190] by nm17.bullet.mail.ac4.yahoo.com with NNFMP; 07 Jan 2011 21:23:08 -0000 Received: from [98.139.52.128] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 07 Jan 2011 21:23:08 -0000 Received: from [127.0.0.1] by omp1011.mail.ac4.yahoo.com with NNFMP; 07 Jan 2011 21:23:08 -0000 X-Yahoo-Newman-Id: 446679.62649.bm@omp1011.mail.ac4.yahoo.com Received: (qmail 29017 invoked from network); 7 Jan 2011 21:23:08 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 07 Jan 2011 13:23:07 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: TLtSlVsVM1mf7u7PE6YZTnayTxe3OqYCe300R.W4tRh523n YSeG4FR.AuLHq29J5BdfuS24KAl9PuPWZ56ukWgBaP23QCGXeFGk0cnQzJhu 1qk3BM2Wt6ihjGUR1qyNPoOJroM1P9wJa25G6O83bJ_e8..y0kxDownjAFuY 9hmTJIDvSRKHVTpTdhagffHjVf75yuai9H1DeD_X_7j_OBxS1JBsq4rp89tb rDcWSAoLvFJcgwfPQPT.O4PmjZQAf6h7UNwQo9.zfnZfJ0lstkmuDS4cov.q KuRsNbPaiBGyl1kBsEIlOLHIgM6iwE339dhlSsvB22L8y_w8WnZZWVGx0Whl PVVG4ZJCFsrJ7wYsMF3Ofte8pFdUmQp4esUwBROQ_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D27843B.2090705@caucho.com> Date: Fri, 07 Jan 2011 13:23:07 -0800 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Maciej Stachowiak References: ?= <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> <10468.1294412280.131214@puncture> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Server-Initiated HTTP Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:21:17 -0000 Maciej Stachowiak wrote: > On Jan 7, 2011, at 6:58 AM, Dave Cridland wrote: > > >> On Fri Jan 7 14:28:07 2011, Maciej Stachowiak wrote: >> >>> 3) Some decent technical reasons have been given for why the framing should be masked as well, for example, when considering the threat model of using HTTP APIs in the browser to attack WebSocket services. >>> >> Hmmmph. If you can mimic any data as an HTTP client, then by inference you can mimic any masking, surely? >> > > No. If the correct mask includes an unpredictable string sent by the server, then it's not possible to mimic it because the client can't compute the correct mask. > > This is actually better than Sec-* headers, because if the server does the check in a buggy way, it won't be able to read from clients at all in the normal case. > To clarify, you're suggesting that the following is a threat: frame-header frame-header frame-header where 1. the hijacker cannot predict how the bytes will be interpreted by the server 2. the hijacker somehow produces Sec-* headers in the POST request 3. the server allows a POST to be processed as a websocket request -- Scott From w@1wt.eu Fri Jan 7 14:21:17 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C30D28C124 for ; Fri, 7 Jan 2011 14:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sLs6hPyhaLu for ; Fri, 7 Jan 2011 14:21:16 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 4CC7B28C0D0 for ; Fri, 7 Jan 2011 14:21:11 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p07MNC2l002519; Fri, 7 Jan 2011 23:23:12 +0100 Date: Fri, 7 Jan 2011 23:23:12 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110107222312.GA2479@1wt.eu> References: <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:21:17 -0000 On Fri, Jan 07, 2011 at 01:19:13PM -0800, Eric Rescorla wrote: > My objective is to make the bits that appear on the wire indistinguishable > from random > from the attacker's perspective. I think it's clear that this is the > strongest form of masking > available, and the method I proposed does that. A sliding mask does not > produce this > result because it means that an attacker can have any relationship he wants > between > bits which appear at the same offset in the mask. As I've now said a number > of times, > I am unaware of an attack which exploits this property, but that does not > mean there > isn't one, and so I prefer to have a stronger mechanism. > > It's important to recognize that this is a distinct question from the > *entropy* of the > mask. For instance. if you start with a 32-bit random seed and use that to > generate > an arbitrarily long mask, this provides more resistance to the above > property than > just using the key directly as a repeating mask. Which is precisely the > point of using > an expansion function for the mask (whether HMAC-SHA1, or AES-CTR). Thank you for this explanation. Now I understand better what you're trying to achieve. Yes I agree that the repeating mask is a lot weaker than a sliding mask, because in order to send a predefined message, the server would just have to establish the relation between the multiple bytes and send it as many times as the key space permits. But still that *a lot*. Sending the 6-bytes "GET /\n" 2^32 times each time encoded with one different key is still 24 GB long. My position is clear on this point, we're not trying to build something *that* secure, we're trying to avoid a lazy intermediary from finding a method using strstr("GET ") in a stream it has in its request buffer. If an attacker is able to make a browser send 24 GB of data to an arbitrary location without anyone noticing, surely there are much more fun to do than just trying to corrupt one entry in a cache. Now maybe we can also build a sliding mask with something very simple without involving expensive computations at all, but given the goals of the suggested masking, I really think that it will bring nothing at all in this precise context. Obviously, would someone propose to encrypt my password using such a masking method, I would categorically refuse and would approve your proposal without hesitation. But we're not trying to do that right now. Regards, Willy From mjs@apple.com Fri Jan 7 14:23:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8E728C12F for ; Fri, 7 Jan 2011 14:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDZUkWi-V4WV for ; Fri, 7 Jan 2011 14:23:30 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id BA6F328C11A for ; Fri, 7 Jan 2011 14:23:27 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id B157EC578FFE for ; Fri, 7 Jan 2011 14:25:32 -0800 (PST) X-AuditID: 11807134-b7cfdae000001831-84-4d2792dc7693 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay14.apple.com (Apple SCV relay) with SMTP id A0.51.06193.CD2972D4; Fri, 7 Jan 2011 14:25:32 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.62.4] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEO006LTBMJ8T40@gertie.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 14:25:32 -0800 (PST) From: Maciej Stachowiak In-reply-to: <4D27843B.2090705@caucho.com> Date: Fri, 07 Jan 2011 14:25:30 -0800 Message-id: <4A5090A9-D580-4F1E-9796-D04AB2C89A27@apple.com> References: ?= <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> <10468.1294412280.131214@puncture> <4D27843B.2090705@caucho.com> To: Scott Ferguson X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: Server-Initiated HTTP Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:23:34 -0000 On Jan 7, 2011, at 1:23 PM, Scott Ferguson wrote: > Maciej Stachowiak wrote: >> On Jan 7, 2011, at 6:58 AM, Dave Cridland wrote: >> >> >>> On Fri Jan 7 14:28:07 2011, Maciej Stachowiak wrote: >>> >>>> 3) Some decent technical reasons have been given for why the framing should be masked as well, for example, when considering the threat model of using HTTP APIs in the browser to attack WebSocket services. >>>> >>> Hmmmph. If you can mimic any data as an HTTP client, then by inference you can mimic any masking, surely? >>> >> >> No. If the correct mask includes an unpredictable string sent by the server, then it's not possible to mimic it because the client can't compute the correct mask. >> >> This is actually better than Sec-* headers, because if the server does the check in a buggy way, it won't be able to read from clients at all in the normal case. >> > > To clarify, you're suggesting that the following is a threat: > > frame-header > frame-header > frame-header > > where > > 1. the hijacker cannot predict how the bytes will be interpreted by the server > 2. the hijacker somehow produces Sec-* headers in the POST request > 3. the server allows a POST to be processed as a websocket request Yes. It's a much lesser threat than the case where can be controlled, obviously, but sometimes sending parseable commands with a garbage payload is still a risk. I think it would be better not to leave this narrower risk open, if we can avoid it and there's no compelling reason to do otherwise. Regards, Maciej From ekr@rtfm.com Fri Jan 7 14:25:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCC83A6985 for ; Fri, 7 Jan 2011 14:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bqt63An71+9 for ; Fri, 7 Jan 2011 14:25:09 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id A604D28C105 for ; Fri, 7 Jan 2011 14:25:02 -0800 (PST) Received: by gxk28 with SMTP id 28so8266468gxk.31 for ; Fri, 07 Jan 2011 14:27:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.83.18 with SMTP id k18mr3840683agl.79.1294439229050; Fri, 07 Jan 2011 14:27:09 -0800 (PST) Received: by 10.90.154.19 with HTTP; Fri, 7 Jan 2011 14:27:08 -0800 (PST) In-Reply-To: <20110107222312.GA2479@1wt.eu> References: <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> Date: Fri, 7 Jan 2011 14:27:08 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=0016e6407c646e4e9f0499491eb7 Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:25:11 -0000 --0016e6407c646e4e9f0499491eb7 Content-Type: text/plain; charset=ISO-8859-1 Yes. I understand your position. However, as I stated, I disagree. I'd possibly be willing to live with a relatively long mask (e.g., 160 bits) generated from a shortish (4-8 byte) key. I oppose anything shorter. -Ekr On Fri, Jan 7, 2011 at 2:23 PM, Willy Tarreau wrote: > On Fri, Jan 07, 2011 at 01:19:13PM -0800, Eric Rescorla wrote: > > My objective is to make the bits that appear on the wire > indistinguishable > > from random > > from the attacker's perspective. I think it's clear that this is the > > strongest form of masking > > available, and the method I proposed does that. A sliding mask does not > > produce this > > result because it means that an attacker can have any relationship he > wants > > between > > bits which appear at the same offset in the mask. As I've now said a > number > > of times, > > I am unaware of an attack which exploits this property, but that does not > > mean there > > isn't one, and so I prefer to have a stronger mechanism. > > > > It's important to recognize that this is a distinct question from the > > *entropy* of the > > mask. For instance. if you start with a 32-bit random seed and use that > to > > generate > > an arbitrarily long mask, this provides more resistance to the above > > property than > > just using the key directly as a repeating mask. Which is precisely the > > point of using > > an expansion function for the mask (whether HMAC-SHA1, or AES-CTR). > > Thank you for this explanation. Now I understand better what you're trying > to achieve. Yes I agree that the repeating mask is a lot weaker than a > sliding mask, because in order to send a predefined message, the server > would just have to establish the relation between the multiple bytes and > send it as many times as the key space permits. But still that *a lot*. > Sending the 6-bytes "GET /\n" 2^32 times each time encoded with one > different key is still 24 GB long. > > My position is clear on this point, we're not trying to build something > *that* secure, we're trying to avoid a lazy intermediary from finding a > method using strstr("GET ") in a stream it has in its request buffer. > If an attacker is able to make a browser send 24 GB of data to an > arbitrary location without anyone noticing, surely there are much more > fun to do than just trying to corrupt one entry in a cache. > > Now maybe we can also build a sliding mask with something very simple > without involving expensive computations at all, but given the goals > of the suggested masking, I really think that it will bring nothing > at all in this precise context. > > Obviously, would someone propose to encrypt my password using such > a masking method, I would categorically refuse and would approve > your proposal without hesitation. But we're not trying to do that > right now. > > Regards, > Willy > > --0016e6407c646e4e9f0499491eb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes. I understand your position. However, as I stated, I disagree.

=
I'd possibly be willing to live with a relatively long mask = (e.g., 160 bits) generated from
a shortish (4-8 byte) key. I oppo= se anything shorter.

-Ekr


On Fr= i, Jan 7, 2011 at 2:23 PM, Willy Tarreau <w@1wt.eu> wrote:
On Fri, Jan 07, 2011 at 01:19:13PM -0800, Eric Rescorla w= rote:
> My objective is to make the bits that appear on the wire indistinguish= able
> from random
> from the attacker's perspective. I think it's clear that this = is the
> strongest form of masking
> available, and the method I proposed does that. A sliding mask does no= t
> produce this
> result because it means that an attacker can have any relationship he = wants
> between
> bits which appear at the same offset in the mask. As I've now said= a number
> of times,
> I am unaware of an attack which exploits this property, but that does = not
> mean there
> isn't one, and so I prefer to have a stronger mechanism.
>
> It's important to recognize that this is a distinct question from = the
> *entropy* of the
> mask. For instance. if you start with a 32-bit random seed and use tha= t to
> generate
> an arbitrarily long mask, this provides more resistance to the above > property than
> just using the key directly as a repeating mask. Which is precisely th= e
> point of using
> an expansion function for the mask (whether HMAC-SHA1, or AES-CTR).
Thank you for this explanation. Now I understand better what you'= re trying
to achieve. Yes I agree that the repeating mask is a lot weaker than a
sliding mask, because in order to send a predefined message, the server
would just have to establish the relation between the multiple bytes and send it as many times as the key space permits. But still that *a lot*.
Sending the 6-bytes "GET /\n" 2^32 times each time encoded with o= ne
different key is still 24 GB long.

My position is clear on this point, we're not trying to build something=
*that* secure, we're trying to avoid a lazy intermediary from finding a=
method using strstr("GET ") in a stream it has in its request buf= fer.
If an attacker is able to make a browser send 24 GB of data to an
arbitrary location without anyone noticing, surely there are much more
fun to do than just trying to corrupt one entry in a cache.

Now maybe we can also build a sliding mask with something very simple
without involving expensive computations at all, but given the goals
of the suggested masking, I really think that it will bring nothing
at all in this precise context.

Obviously, would someone propose to encrypt my password using such
a masking method, I would categorically refuse and would approve
your proposal without hesitation. But we're not trying to do that
right now.

Regards,
Willy


--0016e6407c646e4e9f0499491eb7-- From mjs@apple.com Fri Jan 7 14:25:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB7328C12E for ; Fri, 7 Jan 2011 14:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCigXhwLEKoN for ; Fri, 7 Jan 2011 14:25:11 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id C1A4428C132 for ; Fri, 7 Jan 2011 14:25:05 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 8B850C579197 for ; Fri, 7 Jan 2011 14:27:08 -0800 (PST) X-AuditID: 1180711d-b7c30ae0000055b4-ae-4d27933c586f Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id 83.88.21940.C33972D4; Fri, 7 Jan 2011 14:27:08 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8m99PKB0OIQZWDx21q/ZvQ)" Received: from [17.153.62.4] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEO000W7BP71H10@elliott.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 14:27:08 -0800 (PST) From: Maciej Stachowiak In-reply-to: <4D27792E.2070902@ericsson.com> Date: Fri, 07 Jan 2011 14:27:07 -0800 Message-id: <234FEC6C-8B5C-449F-92A7-CFAFCDBD5283@apple.com> References: <7EFACA83-7D9C-43AF-93D8-EE47642320C3@apple.com> <4D27792E.2070902@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: hybi@ietf.org Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:25:13 -0000 --Boundary_(ID_8m99PKB0OIQZWDx21q/ZvQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT On Jan 7, 2011, at 12:35 PM, Salvatore Loreto wrote: > On 1/7/11 7:47 PM, Maciej Stachowiak wrote: >> >> On Jan 7, 2011, at 10:29 AM, John Tamplin wrote: >> >>> On Fri, Jan 7, 2011 at 1:05 PM, Maciej Stachowiak wrote: >>>> Security features should not be optional, they should be mandatory. Using extensions, >>>> a mechanism designed for optional features, and then layering requirements on top of >>>> that to make masking still be required in the normal case, is needlessly fragile and >>>> needlessly complex. I don't agree with adding that fragility without a corresponding benefit. > a possible benefit from the John proposal is that one has *the freedom* to use the type of masking he want, > the one he think is the better or the stronger... if hmac-sha1 is not enough strong for him. > > 1) Define a new extension "clientmask" in the base spec, which > specifies that client->server masking is present. An optional > parameter "type" specifies the type of masking, and if not > present defaults to "hmac-sha1". Since we're not going to define any other type of masking at this time, it's not a benefit yet. If we define new masking algorithms in the future, we can allow masking selection without making masking an extension. So even then it's not a real benefit. Regards, Maciej --Boundary_(ID_8m99PKB0OIQZWDx21q/ZvQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
On Jan 7, 2011, at 12:35 PM, Salvatore Loreto wrote:

On 1/7/11 7:47 PM, Maciej Stachowiak wrote: 
On Jan 7, 2011, at 10:29 AM, John Tamplin wrote:


On Fri, Jan 7, 2011 at 1:05 PM, Maciej Stachowiak <mjs@apple.com> wrote:

Security features should not be optional, they should be mandatory. Using extensions,
a mechanism designed for optional features, and then layering requirements on top of
that to make masking still be required in the normal case, is needlessly fragile and
needlessly complex. I don't agree with adding that fragility without a corresponding benefit.
a possible benefit from the John proposal is that one has *the freedom* to use the type of masking he want,
the one he think is the better or the stronger... if hmac-sha1 is not enough strong for him.

1) Define a new extension "clientmask" in the base spec, which
   specifies that client->server masking is present.  An optional
   parameter "type" specifies the type of masking, and if not
   present defaults to "hmac-sha1".

Since we're not going to define any other type of masking at this time, it's not a benefit yet. If we define new masking algorithms in the future, we can allow masking selection without making masking an extension. So even then it's not a real benefit.

Regards,
Maciej



--Boundary_(ID_8m99PKB0OIQZWDx21q/ZvQ)-- From mjs@apple.com Fri Jan 7 14:27:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425B828C12A for ; Fri, 7 Jan 2011 14:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60yfYiY1umuC for ; Fri, 7 Jan 2011 14:27:26 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 671AB28C12F for ; Fri, 7 Jan 2011 14:27:26 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 60DB6CA100AE for ; Fri, 7 Jan 2011 14:29:32 -0800 (PST) X-AuditID: 1180711d-b7c30ae0000055b4-86-4d2793cc1148 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id 82.19.21940.CC3972D4; Fri, 7 Jan 2011 14:29:32 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_pLnQCOgJ40s5++RoiSWrWw)" Received: from [17.153.62.4] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEO006PEBT78T40@gertie.apple.com> for hybi@ietf.org; Fri, 07 Jan 2011 14:29:32 -0800 (PST) From: Maciej Stachowiak In-reply-to: <20110107204454.GD32612@1wt.eu> Date: Fri, 07 Jan 2011 14:29:30 -0800 Message-id: <07C0DD4A-3654-4A2A-8451-DA3EDE88A98B@apple.com> References: <4D17B5FF.5060209@callenish.com> <41249E48-B17E-47C7-9340-6F95B85182CD@apple.com> <20110107055244.GH28367@1wt.eu> <20110107204454.GD32612@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:27:28 -0000 --Boundary_(ID_pLnQCOgJ40s5++RoiSWrWw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT On Jan 7, 2011, at 12:44 PM, Willy Tarreau wrote: > On Fri, Jan 07, 2011 at 06:20:09AM -0800, Maciej Stachowiak wrote: >>> >>> >> Willy, I think we're talking past each other. The threat model I'm talking about involves using HTTP APIs to connect to WebSocket servers. HTTP APIs in the browser will effectively let you send any bytes you want as the payload. You seem to be talking about the opposite threat model, where WebSocket APIs in the browser, to attack HTTP. > > Yes, I am. That's why we're discussing about having masking on by default > on the WS client, so that it cannot decide what the bytes will look like > on the wire. > > The HTTP API vs WS server was addressed a while ago with the Sec-* headers > that the HTTP API was supposed not to be able to send. For reasons I've explained a couple of times now, I think masking is a considerably stronger defense against this threat model than Sec-*, so long as entropy from the server is included in the mask. Short version: checking for named headers can easily be subject to bugs where the server is too lenient in its checks (using regexps to parse headers for instance), but masking isn't subject to this risk, because the server *has* to get it right to work correctly in the non-attack case. Since we're adding masking anyway, I'd like it to address this threat too even if we also have a weaker defense for it. Regards, Maciej --Boundary_(ID_pLnQCOgJ40s5++RoiSWrWw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable
On Fri, Jan 07, 2011 at 06:20:09AM -0800, Maciej = Stachowiak wrote:


Willy, I think we're talking past each other. The threat = model I'm talking about involves using HTTP APIs to connect to WebSocket = servers. HTTP APIs in the browser will effectively let you send any = bytes you want as the payload. You seem to be talking about the opposite = threat model, where WebSocket APIs in the browser, to attack = HTTP.

Yes, I am. That's why we're discussing about = having masking on by default
on the WS client, so that it cannot = decide what the bytes will look like
on the wire.

The HTTP API = vs WS server was addressed a while ago with the Sec-* headers
that = the HTTP API was supposed not to be able to = send.

For reasons I've = explained a couple of times now, I think masking is a considerably = stronger defense against this threat model than Sec-*, so long as = entropy from the server is included in the mask. Short version: checking = for named headers can easily be subject to bugs where the server is too = lenient in its checks (using regexps to parse headers for instance), but = masking isn't subject to this risk, because the server *has* to get it = right to work correctly in the non-attack case. Since we're adding = masking anyway, I'd like it to address this threat too even if we also = have a weaker defense for = it.

Regards,
Maciej

= --Boundary_(ID_pLnQCOgJ40s5++RoiSWrWw)-- From ekr@rtfm.com Fri Jan 7 14:40:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA2328C13B for ; Fri, 7 Jan 2011 14:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSq1Knd0V5tZ for ; Fri, 7 Jan 2011 14:40:46 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id ADDC628C172 for ; Fri, 7 Jan 2011 14:40:42 -0800 (PST) Received: by gyd12 with SMTP id 12so7575265gyd.31 for ; Fri, 07 Jan 2011 14:42:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.232.6 with SMTP id e6mr28777061agh.52.1294440169045; Fri, 07 Jan 2011 14:42:49 -0800 (PST) Received: by 10.90.154.19 with HTTP; Fri, 7 Jan 2011 14:42:48 -0800 (PST) In-Reply-To: <07C0DD4A-3654-4A2A-8451-DA3EDE88A98B@apple.com> References: <4D17B5FF.5060209@callenish.com> <41249E48-B17E-47C7-9340-6F95B85182CD@apple.com> <20110107055244.GH28367@1wt.eu> <20110107204454.GD32612@1wt.eu> <07C0DD4A-3654-4A2A-8451-DA3EDE88A98B@apple.com> Date: Fri, 7 Jan 2011 14:42:48 -0800 Message-ID: From: Eric Rescorla To: Maciej Stachowiak Content-Type: multipart/alternative; boundary=001636284f607580e3049949565f Cc: "hybi@ietf.org" Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 22:40:47 -0000 --001636284f607580e3049949565f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 7, 2011 at 2:29 PM, Maciej Stachowiak wrote: > > On Jan 7, 2011, at 12:44 PM, Willy Tarreau wrote: > > On Fri, Jan 07, 2011 at 06:20:09AM -0800, Maciej Stachowiak wrote: > > > > Willy, I think we're talking past each other. The threat model I'm talking > about involves using HTTP APIs to connect to WebSocket servers. HTTP APIs in > the browser will effectively let you send any bytes you want as the payload. > You seem to be talking about the opposite threat model, where WebSocket APIs > in the browser, to attack HTTP. > > > Yes, I am. That's why we're discussing about having masking on by default > on the WS client, so that it cannot decide what the bytes will look like > on the wire. > > The HTTP API vs WS server was addressed a while ago with the Sec-* headers > that the HTTP API was supposed not to be able to send. > > > For reasons I've explained a couple of times now, I think masking is a > considerably stronger defense against this threat model than Sec-*, so long > as entropy from the server is included in the mask. Short version: checking > for named headers can easily be subject to bugs where the server is too > lenient in its checks (using regexps to parse headers for instance), but > masking isn't subject to this risk, because the server *has* to get it right > to work correctly in the non-attack case. Since we're adding masking anyway, > I'd like it to address this threat too even if we also have a weaker defense > for it. > > I agree that this is a good plan. -Ekr > Regards, > Maciej > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --001636284f607580e3049949565f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 7, 2011 at 2:29 PM, Maciej S= tachowiak <mjs@apple.= com> wrote:

On Jan = 7, 2011, at 12:44 PM, Willy Tarreau wrote:

On Fri, Jan 07, 2011 at 06:20:09AM -0800, = Maciej Stachowiak wrote:


Willy, I think we're talking past each other. The thre= at model I'm talking about involves using HTTP APIs to connect to WebSo= cket servers. HTTP APIs in the browser will effectively let you send any by= tes you want as the payload. You seem to be talking about the opposite thre= at model, where WebSocket APIs in the browser, to attack HTTP.

Yes, I am. That's why we're discussing about havin= g masking on by default
on the WS client, so that it cannot decide what = the bytes will look like
on the wire.

The HTTP API vs WS server w= as addressed a while ago with the Sec-* headers
that the HTTP API was supposed not to be able to send.

For reasons I've explained a couple of time= s now, I think masking is a considerably stronger defense against this thre= at model than Sec-*, so long as entropy from the server is included in the = mask. Short version: checking for named headers can easily be subject to bu= gs where the server is too lenient in its checks (using regexps to parse he= aders for instance), but masking isn't subject to this risk, because th= e server *has* to get it right to work correctly in the non-attack case. Si= nce we're adding masking anyway, I'd like it to address this threat= too even if we also have a weaker defense for it.


I agree that this is a goo= d plan.

-Ekr
=A0
Regards,
Maciej


______________________= _________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--001636284f607580e3049949565f-- From jat@google.com Fri Jan 7 15:21:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC1428B797 for ; Fri, 7 Jan 2011 15:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.855 X-Spam-Level: X-Spam-Status: No, score=-103.855 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITe8Ti8X2Fe7 for ; Fri, 7 Jan 2011 15:21:52 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 24C4C28C129 for ; Fri, 7 Jan 2011 15:20:58 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p07NN44J028586 for ; Fri, 7 Jan 2011 15:23:04 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294442584; bh=0h4h4dvMBjNfJAMfj2fHrSMPPHk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=kM4tlOtjXAEtUBQ9omBVsTrsxfaQUQTRxahWM3IiVJYAWf/youdubUv3ccOHKkEeS sEPnXdq1H3pna2f86fAfQ== Received: from gyf2 (gyf2.prod.google.com [10.243.50.66]) by wpaz24.hot.corp.google.com with ESMTP id p07NN3Kw020596 for ; Fri, 7 Jan 2011 15:23:03 -0800 Received: by gyf2 with SMTP id 2so7243651gyf.29 for ; Fri, 07 Jan 2011 15:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=1Ym8X7xqyFn0miLLsnZqKfT4WoBRTbzBQedstu68k4E=; b=IKLhLL55Vkjdho5eW1UWVQ3u/RXsLIy1wMwGCun429g4QM3z6EKRhPmeU1N/B5fwAt JbjpinL60Ew4ORwHIsWg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=VjHFN0XIsqjPMsvUa2D1K/mA3I6YBQjw/y1NN5RUbj2a7J2b0lXjzeIoPf0fc8C1W4 syf8nSDvXY2n7kHb8z4A== Received: by 10.151.158.12 with SMTP id k12mr25512025ybo.377.1294442582920; Fri, 07 Jan 2011 15:23:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Fri, 7 Jan 2011 15:22:42 -0800 (PST) In-Reply-To: <07C0DD4A-3654-4A2A-8451-DA3EDE88A98B@apple.com> References: <4D17B5FF.5060209@callenish.com> <41249E48-B17E-47C7-9340-6F95B85182CD@apple.com> <20110107055244.GH28367@1wt.eu> <20110107204454.GD32612@1wt.eu> <07C0DD4A-3654-4A2A-8451-DA3EDE88A98B@apple.com> From: John Tamplin Date: Fri, 7 Jan 2011 18:22:42 -0500 Message-ID: To: Maciej Stachowiak Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] proposed masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:21:53 -0000 On Fri, Jan 7, 2011 at 5:29 PM, Maciej Stachowiak wrote: > For reasons I've explained a couple of times now, I think masking is a > considerably stronger defense against this threat model than Sec-*, so long > as entropy from the server is included in the mask. Short version: checking > for named headers can easily be subject to bugs where the server is too > lenient in its checks (using regexps to parse headers for instance), but > masking isn't subject to this risk, because the server *has* to get it right > to work correctly in the non-attack case. Since we're adding masking anyway, > I'd like it to address this threat too even if we also have a weaker defense > for it. Plus, AFAIK, there are various ways to send arbitrary headers, such as with Flash. -- John A. Tamplin Software Engineer (GWT), Google From w@1wt.eu Fri Jan 7 16:13:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5A128C0DB for ; Fri, 7 Jan 2011 16:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=-1.364, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_43=0.6, SARE_RAND_1=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUgB4kifcBLC for ; Fri, 7 Jan 2011 16:13:52 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 04AA328B56A for ; Fri, 7 Jan 2011 16:13:48 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p080FnXN003042; Sat, 8 Jan 2011 01:15:49 +0100 Date: Sat, 8 Jan 2011 01:15:49 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110108001549.GD2479@1wt.eu> References: <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 00:13:56 -0000 On Fri, Jan 07, 2011 at 02:27:08PM -0800, Eric Rescorla wrote: > Yes. I understand your position. However, as I stated, I disagree. I'm seeing that you disagree though I really don't get why considering the balance of risks vs costs in some situations :-/ > I'd possibly be willing to live with a relatively long mask (e.g., 160 bits) > generated from a shortish (4-8 byte) key. I oppose anything shorter. OK. My concerns are to avoid per-message setup costs as well as reducing internal states. Would it be OK for you if we used either a rotating 256 bit mask derived from the rotation of a 32 bit one, or even an infinite length one constructed by iterating over a combination of the rotating mask and the output data ? Such constructs are simple, fast and don't permit the attacker to establish relations between message parts when he doesn't know the key. For instance, below is what we find when sending 100 times "GET /\n" with the first method (it does obviously repeat itself) : 76 26 92 ac 37 3b 24 83 d8 39 1d 6f 8d d1 7d 72 8a 41 d1 68 0e 95 45 df ec 13 f8 79 9c 6c 8b dd 65 43 e9 86 5f 74 37 e6 a3 13 75 20 9e b4 06 58 e2 0e c2 0d 75 bf 2d 90 ff 76 83 53 f4 23 98 b8 1e 69 81 c9 4c 11 4c cc cb 5c 66 45 e5 9e 6e 17 f1 6b b9 27 1d f0 3e f5 84 5c eb 1c e7 46 e3 92 76 26 92 ac 37 3b 24 83 d8 39 1d 6f 8d d1 7d 72 8a 41 d1 68 0e 95 45 df ec 13 f8 79 9c 6c 8b dd 65 43 e9 86 5f 74 37 e6 a3 13 75 20 9e b4 06 58 e2 0e c2 0d 75 bf 2d 90 ff 76 83 53 f4 23 98 b8 ... And the second one does not even repeat at all : 85 4c 0a e6 5c 48 8a 61 fd 6f 21 34 f7 1d 99 14 53 41 90 7b ac bc da ce 10 fb 23 32 79 2c 3e 75 82 0e 44 10 02 c9 b6 5a 61 f4 b6 dd 5a 57 6a ff ae c4 92 3f 52 47 a6 2c ab 89 f4 a1 b0 da 4c 5c 7a 2f 3d 77 8f 65 df ca 0c e6 78 f0 bf ea ec 07 d8 d1 9c 09 48 22 a4 a4 82 d7 d6 bc fb 79 03 56 49 23 bb ba c0 94 96 7d ba b6 cc 98 fb 36 49 a4 83 d1 cf 9a 0d 9f 31 67 05 cc 8b 6a d1 c4 27 a2 25 28 17 82 d5 bc fb 7a 01 57 55 3c 7a f7 8a de c0 8a 7c ec aa bf 6e 84 52 7f 12 87 e6 6d ea 46 3c 68 6a 81 5e 53 15 83 d1 b8 e6 6b 2d 3b da 50 2e 02 68 fd ac c7 98 10 5e 4a 8c 66 f8 70 3e 6b 6a 81 5e 52 18 8c de 55 21 2c 6b fe a0 2a 5c 4c 0b 5e 40 0b fc 6c 2a 3e e0 6a 9c 0c 4a 1f 0e e5 71 9c 3b 6e 70 9b 0c 9c 3a 6e 70 9b 0c 9c 3a 6e 70 9b 0c 9c 3b 6e 71 9b 03 92 d9 cf 1d 97 6f c6 bd eb e9 03 db da e1 77 35 5f c7 ce 85 d3 c1 8b 73 e2 49 1c 0f e5 71 9c 3a 6e 70 9b 0c 9c 3a 6e 70 9a 0d 9f 31 67 05 cc 8a 67 da cf 1e 94 62 ef a2 b6 68 82 44 45 20 34 f6 1c 9a 17 aa be 60 ea 1c 8c ca 9f 8e 64 f2 1f b1 e7 86 4c 0a e6 5c 48 8a 61 fe 72 38 6c 7f b5 c1 cc 8b de c1 88 77 9d ... With a constant input stream, the difference is more obvious, let's feed it 256 'A', we see the repeating pattern every 256 bit for the first method, and none for the second one. In fact, with a 8-bit rotating key, the second makes the pattern loop every 256 bytes on this text, and every 64k for a 16-bit key, but here in the examples I used a 32-bit key : method 1 : fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c method 2 : cb 9e 1c 96 05 cc a7 35 5f da 50 33 56 c4 8e 6d 87 55 3c 76 a5 2f 4a 21 a3 26 b5 df 5a d0 b3 d6 44 0e ed 04 ce ac c7 92 78 ab 3e 7c b6 e5 6f 8a 60 e3 69 fb 2e 4c 27 b5 dc 57 c5 8c 66 f5 1f 9a 11 f3 16 84 4e 2c 47 15 fc 36 65 ef 0a e0 63 e9 7b ae cc a7 32 58 cb a1 20 a2 29 bb ee 0d e7 72 98 0b e1 63 e6 74 9f 1d 94 7e bc f7 22 a8 3a 71 90 72 99 0b e1 60 e2 69 fb 2e 4c 27 b5 dc 56 c5 8f 6a 80 42 09 db 4e 2c 46 15 ff 3a 70 93 79 a8 3a 71 93 76 a4 2e 4d 27 b2 d9 4b 1e 9d 17 82 49 1b 8e 6c 87 55 3f 7a b0 d3 b9 eb 7e bc f7 25 ac c6 94 7f ba f0 13 f9 28 bb f1 10 f2 19 88 5a d0 b2 d9 4b 1e 9c 16 85 4f 2d 44 0f ed 07 d2 b8 eb 01 c3 86 54 3f 7d b4 de 5d d7 42 09 db 4e 2c 47 12 f8 2b 41 00 c2 89 5b ce ac c7 92 79 ab c1 83 46 14 ff 3a 70 93 76 a4 2f 4d 24 ae cd a7 32 59 Both functions are extremely simple, have no setup cost and require very little internal state (4 bytes) : mask_string_v1(char *string, unsigned int mask) { while (*string) { *string++ ^= mask; mask = (mask << 1) | (mask >> 31); } } mask_string_v2(char *string, unsigned int mask) { while (*string) { *string ^= mask; mask = (mask << 1) + (mask >> 31) + (unsigned char)*string++; } } Granted they're not cryptographically strong for anything, but at least they're offering a masking that does not let the text's author guess how bytes will be mangled. Especially the second one is interesting because the mangling changes for every byte. The real advantage I see is that we only need to hold the 32-bit mask, and there is no setup cost at all. Would you object against something like this for this specific usage ? Willy /* Complete example to encode/decode below, just performs one read() for simplicity, so will likely require a single write() or reading from a file. Outputs generated using : $ for ((i=0; i<100; i++)); do echo "GET /"; done > 100get.txt $ < 100get.txt ./xormask $RANDOM | od -An -tx1 */ #include #include void mask_string(char *string, unsigned int mask, int len) { while (len--) { *string ^= mask; mask = (mask << 1) + (mask >> 31) + (unsigned char)*string++; } } void unmask_string(char *string, unsigned int mask, int len) { unsigned char c; while (len--) { c = *string; *string++ ^= mask; mask = (mask << 1) + (mask >> 31) + c; } } int main(int argc, char **argv) { char buf[1024]; int len; len = read(0, buf, sizeof(buf) - 1); buf[sizeof(buf)-1] = 0; mask_string(buf, strtoul(argv[1], NULL, 0), len); unmask_string(buf, strtoul(argv[1], NULL, 0), len); write(1, buf, len); return 0; } Regards, Willy From ekr@rtfm.com Fri Jan 7 17:31:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA2D3A693E for ; Fri, 7 Jan 2011 17:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.603 X-Spam-Level: X-Spam-Status: No, score=-99.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_1=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG-fjDZ29y7Q for ; Fri, 7 Jan 2011 17:31:08 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6D9883A6832 for ; Fri, 7 Jan 2011 17:31:08 -0800 (PST) Received: by iwn40 with SMTP id 40so18826092iwn.31 for ; Fri, 07 Jan 2011 17:33:15 -0800 (PST) Received: by 10.42.179.66 with SMTP id bp2mr1555876icb.81.1294450395223; Fri, 07 Jan 2011 17:33:15 -0800 (PST) Received: from [10.76.74.154] ([166.205.138.113]) by mx.google.com with ESMTPS id he5sm1123954icb.10.2011.01.07.17.33.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 17:33:14 -0800 (PST) References: <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> In-Reply-To: <20110108001549.GD2479@1wt.eu> Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148a) From: Eric Rescorla Date: Fri, 7 Jan 2011 17:32:53 -0800 To: Willy Tarreau Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 01:31:10 -0000 On Jan 7, 2011, at 16:15, Willy Tarreau wrote: > On Fri, Jan 07, 2011 at 02:27:08PM -0800, Eric Rescorla wrote: >> Yes. I understand your position. However, as I stated, I disagree. >=20 > I'm seeing that you disagree though I really don't get why considering > the balance of risks vs costs in some situations :-/ >=20 I guess we will have to agree to disagree. >> I'd possibly be willing to live with a relatively long mask (e.g., 160 bi= ts) >> generated from a shortish (4-8 byte) key. I oppose anything shorter. >=20 > OK. My concerns are to avoid per-message setup costs as well as reducing > internal states. Would it be OK for you if we used either a rotating 256 > bit mask derived from the rotation of a 32 bit one, or even an infinite > length one constructed by iterating over a combination of the rotating > mask and the output data ? Such constructs are simple, fast and don't > permit the attacker to establish relations between message parts when > he doesn't know the key. >=20 No.=20 Ekr > For instance, below is what we find when sending 100 times "GET /\n" with > the first method (it does obviously repeat itself) : >=20 > 76 26 92 ac 37 3b 24 83 d8 39 1d 6f 8d d1 7d 72 > 8a 41 d1 68 0e 95 45 df ec 13 f8 79 9c 6c 8b dd > 65 43 e9 86 5f 74 37 e6 a3 13 75 20 9e b4 06 58 > e2 0e c2 0d 75 bf 2d 90 ff 76 83 53 f4 23 98 b8 > 1e 69 81 c9 4c 11 4c cc cb 5c 66 45 e5 9e 6e 17 > f1 6b b9 27 1d f0 3e f5 84 5c eb 1c e7 46 e3 92 >=20 > 76 26 92 ac 37 3b 24 83 d8 39 1d 6f 8d d1 7d 72 > 8a 41 d1 68 0e 95 45 df ec 13 f8 79 9c 6c 8b dd > 65 43 e9 86 5f 74 37 e6 a3 13 75 20 9e b4 06 58 > e2 0e c2 0d 75 bf 2d 90 ff 76 83 53 f4 23 98 b8 > ... >=20 > And the second one does not even repeat at all : > 85 4c 0a e6 5c 48 8a 61 fd 6f 21 34 f7 1d 99 14 > 53 41 90 7b ac bc da ce 10 fb 23 32 79 2c 3e 75 > 82 0e 44 10 02 c9 b6 5a 61 f4 b6 dd 5a 57 6a ff > ae c4 92 3f 52 47 a6 2c ab 89 f4 a1 b0 da 4c 5c > 7a 2f 3d 77 8f 65 df ca 0c e6 78 f0 bf ea ec 07 > d8 d1 9c 09 48 22 a4 a4 82 d7 d6 bc fb 79 03 56 > 49 23 bb ba c0 94 96 7d ba b6 cc 98 fb 36 49 a4 > 83 d1 cf 9a 0d 9f 31 67 05 cc 8b 6a d1 c4 27 a2 > 25 28 17 82 d5 bc fb 7a 01 57 55 3c 7a f7 8a de > c0 8a 7c ec aa bf 6e 84 52 7f 12 87 e6 6d ea 46 > 3c 68 6a 81 5e 53 15 83 d1 b8 e6 6b 2d 3b da 50 > 2e 02 68 fd ac c7 98 10 5e 4a 8c 66 f8 70 3e 6b > 6a 81 5e 52 18 8c de 55 21 2c 6b fe a0 2a 5c 4c > 0b 5e 40 0b fc 6c 2a 3e e0 6a 9c 0c 4a 1f 0e e5 > 71 9c 3b 6e 70 9b 0c 9c 3a 6e 70 9b 0c 9c 3a 6e > 70 9b 0c 9c 3b 6e 71 9b 03 92 d9 cf 1d 97 6f c6 > bd eb e9 03 db da e1 77 35 5f c7 ce 85 d3 c1 8b > 73 e2 49 1c 0f e5 71 9c 3a 6e 70 9b 0c 9c 3a 6e > 70 9a 0d 9f 31 67 05 cc 8a 67 da cf 1e 94 62 ef > a2 b6 68 82 44 45 20 34 f6 1c 9a 17 aa be 60 ea > 1c 8c ca 9f 8e 64 f2 1f b1 e7 86 4c 0a e6 5c 48 > 8a 61 fe 72 38 6c 7f b5 c1 cc 8b de c1 88 77 9d > ... >=20 > With a constant input stream, the difference is more obvious, > let's feed it 256 'A', we see the repeating pattern every > 256 bit for the first method, and none for the second one. > In fact, with a 8-bit rotating key, the second makes the > pattern loop every 256 bytes on this text, and every 64k > for a 16-bit key, but here in the examples I used a 32-bit > key : >=20 > method 1 : > fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 > 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c > fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 > 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c > fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 > 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c > fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 > 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c > fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 > 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c > fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 > 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c > fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 > 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c > fa 36 af 9d f8 32 a6 8f dc 7b 35 a9 91 e0 02 c6 > 4f 5d 78 33 a5 89 d0 62 07 cc 5b 74 2a 96 ef 1c >=20 > method 2 : > cb 9e 1c 96 05 cc a7 35 5f da 50 33 56 c4 8e 6d > 87 55 3c 76 a5 2f 4a 21 a3 26 b5 df 5a d0 b3 d6 > 44 0e ed 04 ce ac c7 92 78 ab 3e 7c b6 e5 6f 8a > 60 e3 69 fb 2e 4c 27 b5 dc 57 c5 8c 66 f5 1f 9a > 11 f3 16 84 4e 2c 47 15 fc 36 65 ef 0a e0 63 e9 > 7b ae cc a7 32 58 cb a1 20 a2 29 bb ee 0d e7 72 > 98 0b e1 63 e6 74 9f 1d 94 7e bc f7 22 a8 3a 71 > 90 72 99 0b e1 60 e2 69 fb 2e 4c 27 b5 dc 56 c5 > 8f 6a 80 42 09 db 4e 2c 46 15 ff 3a 70 93 79 a8 > 3a 71 93 76 a4 2e 4d 27 b2 d9 4b 1e 9d 17 82 49 > 1b 8e 6c 87 55 3f 7a b0 d3 b9 eb 7e bc f7 25 ac > c6 94 7f ba f0 13 f9 28 bb f1 10 f2 19 88 5a d0 > b2 d9 4b 1e 9c 16 85 4f 2d 44 0f ed 07 d2 b8 eb > 01 c3 86 54 3f 7d b4 de 5d d7 42 09 db 4e 2c 47 > 12 f8 2b 41 00 c2 89 5b ce ac c7 92 79 ab c1 83 > 46 14 ff 3a 70 93 76 a4 2f 4d 24 ae cd a7 32 59 >=20 > Both functions are extremely simple, have no setup cost > and require very little internal state (4 bytes) : >=20 > mask_string_v1(char *string, unsigned int mask) > { > while (*string) { > *string++ ^=3D mask; > mask =3D (mask << 1) | (mask >> 31); > } > } >=20 > mask_string_v2(char *string, unsigned int mask) > { > while (*string) { > *string ^=3D mask; > mask =3D (mask << 1) + (mask >> 31) + (unsigned char)*string++; > } > } >=20 > Granted they're not cryptographically strong for anything, but at > least they're offering a masking that does not let the text's author > guess how bytes will be mangled. Especially the second one is > interesting because the mangling changes for every byte. >=20 > The real advantage I see is that we only need to hold the 32-bit > mask, and there is no setup cost at all. Would you object against > something like this for this specific usage ? >=20 > Willy >=20 > /* > Complete example to encode/decode below, just performs one read() for > simplicity, so will likely require a single write() or reading from a > file. >=20 > Outputs generated using : > $ for ((i=3D0; i<100; i++)); do echo "GET /"; done > 100get.txt > $ < 100get.txt ./xormask $RANDOM | od -An -tx1 > */ >=20 > #include > #include >=20 > void mask_string(char *string, unsigned int mask, int len) > { > while (len--) { > *string ^=3D mask; > mask =3D (mask << 1) + (mask >> 31) + (unsigned char)*string++; > } > } >=20 > void unmask_string(char *string, unsigned int mask, int len) > { > unsigned char c; >=20 > while (len--) { > c =3D *string; > *string++ ^=3D mask; > mask =3D (mask << 1) + (mask >> 31) + c; > } > } >=20 > int main(int argc, char **argv) > { > char buf[1024]; > int len; >=20 > len =3D read(0, buf, sizeof(buf) - 1); > buf[sizeof(buf)-1] =3D 0; > mask_string(buf, strtoul(argv[1], NULL, 0), len); > unmask_string(buf, strtoul(argv[1], NULL, 0), len); > write(1, buf, len); > return 0; > } >=20 > Regards, > Willy >=20 From w@1wt.eu Fri Jan 7 17:48:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473B23A6966 for ; Fri, 7 Jan 2011 17:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3776CrBFOzz for ; Fri, 7 Jan 2011 17:48:00 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 425DD3A6832 for ; Fri, 7 Jan 2011 17:47:59 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p081o2NC003255; Sat, 8 Jan 2011 02:50:02 +0100 Date: Sat, 8 Jan 2011 02:50:02 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110108015002.GG2479@1wt.eu> References: <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 01:48:01 -0000 On Fri, Jan 07, 2011 at 05:32:53PM -0800, Eric Rescorla wrote: > > > On Jan 7, 2011, at 16:15, Willy Tarreau wrote: > > > On Fri, Jan 07, 2011 at 02:27:08PM -0800, Eric Rescorla wrote: > >> Yes. I understand your position. However, as I stated, I disagree. > > > > I'm seeing that you disagree though I really don't get why considering > > the balance of risks vs costs in some situations :-/ > > > > I guess we will have to agree to disagree. Indeed. I don't see any other possible issue then. I will have tried to propose some solutions in relation with estimated risks, and you will have expressed your high expectations. I just have no idea why you absolutely want to ensure that we could safely saturate a network link for as long as the age of the universe without risking to see a request which we will still see anyway, all that to protect against some proxies that might have a sloppy request parser. Clearly that's beyond my understanding, I'm just hoping someone else will understand what it brings. Willy From ekr@rtfm.com Fri Jan 7 18:06:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812F53A6966 for ; Fri, 7 Jan 2011 18:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.101 X-Spam-Level: X-Spam-Status: No, score=-101.101 tagged_above=-999 required=5 tests=[AWL=1.498, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hp0fB-G6aMv for ; Fri, 7 Jan 2011 18:06:55 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id AD5953A6945 for ; Fri, 7 Jan 2011 18:06:55 -0800 (PST) Received: by yie19 with SMTP id 19so5567263yie.31 for ; Fri, 07 Jan 2011 18:09:01 -0800 (PST) Received: by 10.236.108.41 with SMTP id p29mr3145021yhg.54.1294452541838; Fri, 07 Jan 2011 18:09:01 -0800 (PST) Received: from [10.76.74.154] ([166.205.138.113]) by mx.google.com with ESMTPS id g27sm15705939yhd.13.2011.01.07.18.08.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 18:09:01 -0800 (PST) References: <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> In-Reply-To: <20110108015002.GG2479@1wt.eu> Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148a) From: Eric Rescorla Date: Fri, 7 Jan 2011 18:08:53 -0800 To: Willy Tarreau Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 02:06:56 -0000 You haven't said anything new here do I think we are officially done Ekr On Jan 7, 2011, at 17:50, Willy Tarreau wrote: > On Fri, Jan 07, 2011 at 05:32:53PM -0800, Eric Rescorla wrote: >> >> >> On Jan 7, 2011, at 16:15, Willy Tarreau wrote: >> >>> On Fri, Jan 07, 2011 at 02:27:08PM -0800, Eric Rescorla wrote: >>>> Yes. I understand your position. However, as I stated, I disagree. >>> >>> I'm seeing that you disagree though I really don't get why considering >>> the balance of risks vs costs in some situations :-/ >>> >> >> I guess we will have to agree to disagree. > > Indeed. I don't see any other possible issue then. I will have tried to > propose some solutions in relation with estimated risks, and you will > have expressed your high expectations. I just have no idea why you > absolutely want to ensure that we could safely saturate a network link > for as long as the age of the universe without risking to see a request > which we will still see anyway, all that to protect against some proxies > that might have a sloppy request parser. Clearly that's beyond my > understanding, I'm just hoping someone else will understand what it > brings. > > Willy > From w@1wt.eu Sat Jan 8 00:10:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C56828C105 for ; Sat, 8 Jan 2011 00:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOtIkvkFgCbx for ; Sat, 8 Jan 2011 00:10:33 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 1BB9B28C0EB for ; Sat, 8 Jan 2011 00:10:32 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p088CW1m003988; Sat, 8 Jan 2011 09:12:32 +0100 Date: Sat, 8 Jan 2011 09:12:32 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110108081232.GH2479@1wt.eu> References: <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 08:10:34 -0000 On Fri, Jan 07, 2011 at 06:08:53PM -0800, Eric Rescorla wrote: > You haven't said anything new here do I think we are officially done If you want, we can say that : I officially object to the cost of your proposal given that it relies on pure guess and not a quantification of the risk, and it is easily provable that it is overkill for the simplest requests we have to care about (eg: "GET /\n", 48-bit long). Willy From w@1wt.eu Sat Jan 8 03:14:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E153A69D2 for ; Sat, 8 Jan 2011 03:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNKkqDfn5mSS for ; Sat, 8 Jan 2011 03:14:27 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 4DB663A69CE for ; Sat, 8 Jan 2011 03:14:26 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p08BGWBt004340 for hybi@ietf.org; Sat, 8 Jan 2011 12:16:32 +0100 Date: Sat, 8 Jan 2011 12:16:32 +0100 From: Willy Tarreau To: "hybi@ietf.org" Message-ID: <20110108111632.GI2479@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 11:14:28 -0000 Since I was not convinced at all by the supposedly very low overhead of using HMAC to compute a masking key, I have written a WebSocket framing parser which reads, parses and forwards frames. It supports 7, 16 and 63-bit lengths, stops after forwarding the last frame with opcode 0x01 and exits with an error if the input is broken before reaching the end of the closing frame. When called with any argument, it computes an hmac-sha1 key derived from a simple 32-bit constant key (for simplicity) for each frame. The payload is not even unmasked with the key, the purpose is just to evaluate the cost for a front server/load balancer/switch supposed to switch frames to a server farm. I have ran it over a stream of messages whose payload was between 1 and 125 bytes, with an average of 29 bytes (rnd(1..5) ^ 3), so that we're in line with many legitimate uses of the protocol such as online chat, and it happens to always fit in one byte length, making the stream generator even easier to write. The results : willy@pcw:~/c$ wc -c /dev/shm/ws-stream.bin 579976835 /dev/shm/ws-stream.bin - without masking : willy@pcw:~/c$ time ./ws-parse < /dev/shm/ws-stream.bin >/dev/null 20000001 messages forwarded real 0m1.753s user 0m1.544s sys 0m0.208s => average bit rate : 4.1 Gbps - with HMAC-based masking : willy@pcw:~/c$ time ./ws-parse 1 < /dev/shm/ws-stream.bin >/dev/null 20000001 messages forwarded real 0m42.098s user 0m41.759s sys 0m0.212s => average bit rate : 172 Mbps Masking the stream with HMAC multiplies the parsing time by 24 on small messages !!! We're not at all in the range of a few percent more. The parser with HMAC is limited to only 172 Mbps on a 3 GHz system, which is the speed at which the non-masking parser would run on a 125 MHz system. Considering those facts, I'm strongly opposed to using HMAC as well as any algorithm which has a similar level of complexity, which is normally required only for cryptographically strong usages. We're not trying to encrypt the stream, we're just ensuring that no broken intermediary will accidentally find a request that was put there on purpose by an attacker. Such a complexity is not required at all and is way overkill. The per-byte masking cost must remain very low even for small frames. I still think that a simple sliding XOR based on a cheap modification of the seed is far more than enough against choosen text attacks for this use case, such as the example code I provided yesterday, or any other one with the same level of complexity. The code to reproduce those tests can be freely downloaded there : http://1wt.eu/websocket/ It's clearly not a model of beauty as it's only a POC. So it's not needed to comment on its ugliness or its possible improvements. Regards, Willy From ekr@rtfm.com Sat Jan 8 06:55:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA5128C106 for ; Sat, 8 Jan 2011 06:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlFtpxoFiQEB for ; Sat, 8 Jan 2011 06:55:41 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id ABE9528C0F0 for ; Sat, 8 Jan 2011 06:55:41 -0800 (PST) Received: by gwj17 with SMTP id 17so9683115gwj.31 for ; Sat, 08 Jan 2011 06:57:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.114.5 with SMTP id m5mr4435859agc.25.1294498669391; Sat, 08 Jan 2011 06:57:49 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sat, 8 Jan 2011 06:57:49 -0800 (PST) In-Reply-To: <20110108081232.GH2479@1wt.eu> References: <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> Date: Sat, 8 Jan 2011 06:57:49 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=0016361e84fc59f276049956f5e7 Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 14:55:42 -0000 --0016361e84fc59f276049956f5e7 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jan 8, 2011 at 12:12 AM, Willy Tarreau wrote: > On Fri, Jan 07, 2011 at 06:08:53PM -0800, Eric Rescorla wrote: > > You haven't said anything new here do I think we are officially done > > If you want, we can say that : I officially object to the cost of your > proposal given that it relies on pure guess and not a quantification > of the risk, and it is easily provable that it is overkill for the > simplest requests we have to care about (eg: "GET /\n", 48-bit long). > You have proven no such thing. -Ekr --0016361e84fc59f276049956f5e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jan 8, 2011 at 12:12 AM, Willy T= arreau <w@1wt.eu> wrote:
On Fri, Jan 07, 2011 at 06:08:53PM -0800, Eric Rescorla w= rote:
> You haven't said anything new here do I think we are officially do= ne

If you want, we can say that : I officially object to the cost of you= r
proposal given that it relies on pure guess and not a quantification
of the risk, and it is easily provable that it is overkill for the
simplest requests we have to care about (eg: "GET /\n", 48-bit lo= ng).

You have pr= oven no such thing.=A0

-Ekr
=A0

--0016361e84fc59f276049956f5e7-- From ekr@rtfm.com Sat Jan 8 07:07:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032CA28C0F9 for ; Sat, 8 Jan 2011 07:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eWZfev0qzIu for ; Sat, 8 Jan 2011 07:06:59 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 91C5928C0F0 for ; Sat, 8 Jan 2011 07:06:59 -0800 (PST) Received: by gwj17 with SMTP id 17so9685431gwj.31 for ; Sat, 08 Jan 2011 07:09:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.2.23 with SMTP id 23mr4434384agb.106.1294499347444; Sat, 08 Jan 2011 07:09:07 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sat, 8 Jan 2011 07:09:07 -0800 (PST) In-Reply-To: References: <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> Date: Sat, 8 Jan 2011 07:09:07 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=00163631086bc432e10499571d8f Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 15:07:01 -0000 --00163631086bc432e10499571d8f Content-Type: text/plain; charset=ISO-8859-1 Or more properly, you have not proven that there is no risk, but rather that there is no risk, but merely chosen a particular attack. To repeat myself for the umpteenth time, an attacker can use a sliding mask to produce a message with a particular structure. They cannot do that with a generated (CTR or HMAC) solution. No, I do not have an attack, but indistinguishability from random is stronger than not. As for your "official" objection, yes, yes, I know you object. Making it "official" doesn't somehow change anything. Chairs; I think it's clear that we're long past anything that is new being said here. Can you please run a straw poll to resolve the question of masking. IMO the relevant options are: 0. No masking. 1. A short fixed mask carried entirely in the packet. 2. A longish repeated mask computed from the packet. For concreteness, suppose HMAC-SHA1(, || || ), but obviously there's flexibility here. 3. A fully generated mask, e.g., using AES-CTR or HMAC-SHA for each byte. -Ekr On Sat, Jan 8, 2011 at 6:57 AM, Eric Rescorla wrote: > > > On Sat, Jan 8, 2011 at 12:12 AM, Willy Tarreau wrote: > >> On Fri, Jan 07, 2011 at 06:08:53PM -0800, Eric Rescorla wrote: >> > You haven't said anything new here do I think we are officially done >> >> If you want, we can say that : I officially object to the cost of your >> proposal given that it relies on pure guess and not a quantification >> of the risk, and it is easily provable that it is overkill for the >> simplest requests we have to care about (eg: "GET /\n", 48-bit long). >> > > You have proven no such thing. > > -Ekr > > > --00163631086bc432e10499571d8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Or more properly, you have not proven that there is no risk, but rather tha= t
there is no risk, but merely chosen a particular attack. To repeat my= self for
the umpteenth time, an attacker can use a sliding mask t= o produce a message
with a particular structure. They cannot do that with a generated (CTR= or HMAC)
solution. No, I do not have an attack, but indistinguis= hability from random=A0
is stronger than not.

As for your "official" objection, yes, yes, I know you objec= t. Making it "official"
doesn't somehow change anyt= hing.


Chairs; I think it's clea= r that we're long past anything that is new being said here.

Can you please run a straw poll to resolve the question= of masking. IMO the=A0
relevant options are:


0. No masking.
1. A short fixed mask carried= entirely in the packet.
2. A longish repeated mask computed from the packet. For concreteness,= suppose
=A0=A0 =A0HMAC-SHA1(<uuid>, <server-conn-key>= ; || <client-conn-key> || <packet-key>), but
=A0=A0 = =A0obviously there's flexibility here.
3. A fully generated mask, e.g., using AES-CTR or HMAC-SHA for each by= te.

-Ekr



--00163631086bc432e10499571d8f-- From ekr@rtfm.com Sat Jan 8 07:07:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB0D28C0F9 for ; Sat, 8 Jan 2011 07:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTwHSYqfpa6b for ; Sat, 8 Jan 2011 07:07:56 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 116F428C0F0 for ; Sat, 8 Jan 2011 07:07:55 -0800 (PST) Received: by gwj17 with SMTP id 17so9685607gwj.31 for ; Sat, 08 Jan 2011 07:10:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.83.18 with SMTP id k18mr4435072agl.79.1294499403861; Sat, 08 Jan 2011 07:10:03 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sat, 8 Jan 2011 07:10:03 -0800 (PST) In-Reply-To: References: <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> Date: Sat, 8 Jan 2011 07:10:03 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=0016e6407c64210ed804995721c2 Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 15:07:57 -0000 --0016e6407c64210ed804995721c2 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jan 8, 2011 at 7:09 AM, Eric Rescorla wrote: > Or more properly, you have not proven that there is no risk, but rather > that > there is no risk, but merely chosen a particular attack. > Gah. "That there is no risk of a particular chosen attack." > To repeat myself for > the umpteenth time, an attacker can use a sliding mask to produce a message > with a particular structure. They cannot do that with a generated (CTR or > HMAC) > solution. No, I do not have an attack, but indistinguishability from > random > is stronger than not. > > As for your "official" objection, yes, yes, I know you object. Making it > "official" > doesn't somehow change anything. > > > Chairs; I think it's clear that we're long past anything that is new being > said here. > > Can you please run a straw poll to resolve the question of masking. IMO > the > relevant options are: > > > 0. No masking. > 1. A short fixed mask carried entirely in the packet. > 2. A longish repeated mask computed from the packet. For concreteness, > suppose > HMAC-SHA1(, || || > ), but > obviously there's flexibility here. > 3. A fully generated mask, e.g., using AES-CTR or HMAC-SHA for each byte. > > -Ekr > > > On Sat, Jan 8, 2011 at 6:57 AM, Eric Rescorla wrote: > >> >> >> On Sat, Jan 8, 2011 at 12:12 AM, Willy Tarreau wrote: >> >>> On Fri, Jan 07, 2011 at 06:08:53PM -0800, Eric Rescorla wrote: >>> > You haven't said anything new here do I think we are officially done >>> >>> If you want, we can say that : I officially object to the cost of your >>> proposal given that it relies on pure guess and not a quantification >>> of the risk, and it is easily provable that it is overkill for the >>> simplest requests we have to care about (eg: "GET /\n", 48-bit long). >>> >> >> You have proven no such thing. >> >> -Ekr >> >> >> > --0016e6407c64210ed804995721c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jan 8, 2011 at 7:09 AM, Eric Res= corla <ekr@rtfm.com> wrote:
Or more properly, you have not proven that there is no risk, but rather tha= t
there is no risk, but merely chosen a particular attack.

Gah. "That there is no risk of a particular= chosen attack."

=A0
To repeat= myself for
the umpteenth time, an attacker can use a sliding mas= k to produce a message
with a particular structure. They cannot do that with a generated (CTR= or HMAC)
solution. No, I do not have an attack, but indistinguis= hability from random=A0
is stronger than not.

As for your "official" objection, yes, yes, I know you objec= t. Making it "official"
doesn't somehow change anyt= hing.


Chairs; I think it's clea= r that we're long past anything that is new being said here.

Can you please run a straw poll to resolve the question= of masking. IMO the=A0
relevant options are:


0. No masking.
1. A short fixed mask carried= entirely in the packet.
2. A longish repeated mask computed from the packet. For concreteness,= suppose
=A0=A0 =A0HMAC-SHA1(<uuid>, <server-conn-key>= ; || <client-conn-key> || <packet-key>), but
=A0=A0 = =A0obviously there's flexibility here.
3. A fully generated mask, e.g., using AES-CTR or HMAC-SHA for each by= te.

-Ekr


On Sat, Jan 8, 2011 at 6:5= 7 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Sat, Jan 8, 2011 at 12:12 AM, Willy Tarreau <w@1wt.eu>= wrote:
On Fri, Jan 07, 2011 at 06:08:53PM -0800, Eric Rescorla wrote:
> You haven't said anything new here do I think we are officially do= ne

If you want, we can say that : I officially object to the cost of you= r
proposal given that it relies on pure guess and not a quantification
of the risk, and it is easily provable that it is overkill for the
simplest requests we have to care about (eg: "GET /\n", 48-bit lo= ng).

You have proven no such thing.=A0

-Ekr
= =A0



--0016e6407c64210ed804995721c2-- From w@1wt.eu Sat Jan 8 07:21:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4018D3A696A for ; Sat, 8 Jan 2011 07:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePshkoonm9RG for ; Sat, 8 Jan 2011 07:21:52 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 271B13A6934 for ; Sat, 8 Jan 2011 07:21:51 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p08FNrpW005045; Sat, 8 Jan 2011 16:23:53 +0100 Date: Sat, 8 Jan 2011 16:23:53 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110108152353.GK2479@1wt.eu> References: <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 15:21:53 -0000 On Sat, Jan 08, 2011 at 06:57:49AM -0800, Eric Rescorla wrote: > On Sat, Jan 8, 2011 at 12:12 AM, Willy Tarreau wrote: > > > On Fri, Jan 07, 2011 at 06:08:53PM -0800, Eric Rescorla wrote: > > > You haven't said anything new here do I think we are officially done > > > > If you want, we can say that : I officially object to the cost of your > > proposal given that it relies on pure guess and not a quantification > > of the risk, and it is easily provable that it is overkill for the > > simplest requests we have to care about (eg: "GET /\n", 48-bit long). > > > > You have proven no such thing. Sending 2^48 different patterns on the wire, how ever they're mangled will make your desired 48-bit pattern appear. Using keys smaller than the pattern may help the attacker establish a relation which helps him send less than 2^48 patterns, but using larger keys will not prevent one 48-bit pattern from appearing in a series of 2^48 random-looking different patterns. You could even send /dev/random to the wire if you want. At one point you will find "GET /\n", and you know that. Also, I'd like to state that it's important to define what we're trying to achieve. It has been speculated that some intermediaries might skip non-HTTP looking garbage and automatically resync on what looks like HTTP. That probably means that those intermediaries will automatically consider a pattern starting as "GET " as a new request ? If so it will appear every 2^32 32-bit message, or every 16 GB in a random stream. Why use 160-bit cryptographically strong ciphers to generate better random when 32 bits of those random will be enough to get the faulty component to resync ? It would be nice if you could for once defend your points based on *facts* and not intimate feelings. All we know is that I have proven nothing, but that's for sure considering that you're asking me to prove that we can remain protected against a risk we cannot even reliably describe ! If the components you're talking about exist, what allows you to think that by sending random garbage when they're expecting a valid HTTP request, you won't make them seek past the end of their request buffer, to a point that it cleanly syncs on another request buffer which contains a valid HTTP request ? How could you prove that it cannot happen ? That's a real risk for a component which is able to do complex things such as skipping over random data looking for a valid HTTP request, when the required behaviour is a lot simpler to implement. Willy From w@1wt.eu Sat Jan 8 07:29:43 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DECB53A6934 for ; Sat, 8 Jan 2011 07:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+sI66hpbCAv for ; Sat, 8 Jan 2011 07:29:43 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id C57253A6908 for ; Sat, 8 Jan 2011 07:29:42 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p08FVl1V005096; Sat, 8 Jan 2011 16:31:47 +0100 Date: Sat, 8 Jan 2011 16:31:47 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110108153147.GL2479@1wt.eu> References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 15:29:44 -0000 On Sat, Jan 08, 2011 at 07:09:07AM -0800, Eric Rescorla wrote: > Chairs; I think it's clear that we're long past anything that is new being > said here. You're exagerating Eric. I have provided code, examples and performance measurements to make progress. You desperately remained on your position without any *fact* to explain it. > Can you please run a straw poll to resolve the question of masking. IMO the > relevant options are: > > > 0. No masking. > 1. A short fixed mask carried entirely in the packet. 1.5. A short sliding mask derived from a short one carried in the frame and which does not require many CPU cycles per frame. > 2. A longish repeated mask computed from the packet. For concreteness, > suppose > HMAC-SHA1(, || || > ), but > obviously there's flexibility here. > 3. A fully generated mask, e.g., using AES-CTR or HMAC-SHA for each byte. We should clarify one important point as well : 1. mask framing headers 2. mask payload only Regards, Willy From neonux@gmail.com Sat Jan 8 07:38:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81CC3A6975 for ; Sat, 8 Jan 2011 07:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMIbJNsXg4uZ for ; Sat, 8 Jan 2011 07:38:36 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DDBFC3A6954 for ; Sat, 8 Jan 2011 07:38:35 -0800 (PST) Received: by wwa36 with SMTP id 36so18364433wwa.13 for ; Sat, 08 Jan 2011 07:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=9SqzLib3j1dPou1AK8lS3KJelEY0kLfO+VmclfK45l0=; b=H6kQRtbh1qerBICsLkxKoa2pOPbO3OTytcPuLLFMthCaj/YDokmNvY96oSoMRCjnDG cMImO95jeZ2Hbbg93cmH3xyq612E0GJd0V+/tsm2BvICxMJLE66ryeXMsEdKoOpXYYPC 7SPziyjW/2jnq/Tf5X04WmUlGz5WkCuS+eUuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=XslcD/68kzcJhmT48MEPpGd4s4BP0HlRKLFlkSBGEdwwH+DOwwz3kpaJBAz2AkREh0 rsBhKP7MqjfpyzAmSVM6q0mRFkZ624iQZvaUlWb/fUYsQIvm+x8lsz9cWhm8aUVB3yKy ehzZfekuqBbuJUiSNFgG/QAy2pY9ALqgwSRzw= Received: by 10.227.143.18 with SMTP id s18mr16725867wbu.98.1294501242795; Sat, 08 Jan 2011 07:40:42 -0800 (PST) MIME-Version: 1.0 Sender: neonux@gmail.com Received: by 10.227.3.19 with HTTP; Sat, 8 Jan 2011 07:40:12 -0800 (PST) In-Reply-To: <20110108152353.GK2479@1wt.eu> References: <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> From: Cedric Vivier Date: Sat, 8 Jan 2011 23:40:12 +0800 X-Google-Sender-Auth: yE3xoeakbLXERdheWHWYA4V8Q3A Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=UTF-8 Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 15:40:29 -0000 On Sat, Jan 8, 2011 at 23:23, Willy Tarreau wrote: > You could even send /dev/random to the wire if you want. At one point > you will find "GET /\n", and you know that. This might be a stupid idea but wouldn't fragmenting the frame at every "HTTP/" [1] occurence within a message guarantee that no broken proxy would ever interpret any 'request' ? Eg: 0x04 0x0F "GET / HTTP/1.1" becomes : 0x84 0x06 "GET / " 0x04 0x08 "HTTP/1.1" (maybe it would need an IMPLICIT_MORE bit rather than already spec'ed MORE bit) Looks much simpler to implement as part of WebSocket's data framing on the client and still allows servers to use sendfile or similar as they see fit. Sorry for the noise if I'm completely off-track :-) Regards, From w@1wt.eu Sat Jan 8 07:58:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ED7228C10E for ; Sat, 8 Jan 2011 07:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GPI1z3OD9u5 for ; Sat, 8 Jan 2011 07:58:40 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 215E928C10C for ; Sat, 8 Jan 2011 07:58:39 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p08G0k0A005178; Sat, 8 Jan 2011 17:00:46 +0100 Date: Sat, 8 Jan 2011 17:00:46 +0100 From: Willy Tarreau To: Cedric Vivier Message-ID: <20110108160046.GN2479@1wt.eu> References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 15:58:41 -0000 Hello Cedric, On Sat, Jan 08, 2011 at 11:40:12PM +0800, Cedric Vivier wrote: > On Sat, Jan 8, 2011 at 23:23, Willy Tarreau wrote: > > You could even send /dev/random to the wire if you want. At one point > > you will find "GET /\n", and you know that. > > This might be a stupid idea but wouldn't fragmenting the frame at > every "HTTP/" [1] occurence within a message guarantee that no broken > proxy would ever interpret any 'request' ? > > Eg: > 0x04 0x0F "GET / HTTP/1.1" > > becomes : > > 0x84 0x06 "GET / " > 0x04 0x08 "HTTP/1.1" > > (maybe it would need an IMPLICIT_MORE bit rather than already spec'ed MORE bit) > > > Looks much simpler to implement as part of WebSocket's data framing on > the client and still allows servers to use sendfile or similar as they > see fit. > Sorry for the noise if I'm completely off-track :-) No you're not off-track and it's a really good idea. In my opinion it is hard for the sender to ensure it does that for specific strings, however we could very well decide that frames emitted by a browser must not be larger than XXX bytes (eg: 4 or 8 bytes). That way we'll have two bytes of framing everywhere in the middle of requests. And that does not even require complex changes at all. For instance, preventing the browser from sending frames larger than 8 bytes will imply a 25% size overhead for frames larger than 8 bytes, which is equivalent to sending a 32-bit key with a 16-bytes frame. Possibly that can be studied. Thanks, Willy From ekr@rtfm.com Sat Jan 8 08:01:25 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1751128C117 for ; Sat, 8 Jan 2011 08:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS1KIRYRIw3D for ; Sat, 8 Jan 2011 08:01:24 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 2501728C116 for ; Sat, 8 Jan 2011 08:01:24 -0800 (PST) Received: by gyd12 with SMTP id 12so7763300gyd.31 for ; Sat, 08 Jan 2011 08:03:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.232.6 with SMTP id e6mr29394907agh.52.1294502612071; Sat, 08 Jan 2011 08:03:32 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sat, 8 Jan 2011 08:03:31 -0800 (PST) In-Reply-To: <20110108153147.GL2479@1wt.eu> References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108153147.GL2479@1wt.eu> Date: Sat, 8 Jan 2011 08:03:31 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: multipart/alternative; boundary=001636284f605a8342049957e047 Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:01:25 -0000 --001636284f605a8342049957e047 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jan 8, 2011 at 7:31 AM, Willy Tarreau wrote: > On Sat, Jan 08, 2011 at 07:09:07AM -0800, Eric Rescorla wrote: > > Chairs; I think it's clear that we're long past anything that is new > being > > said here. > > You're exagerating Eric. I have provided code, examples and performance > measurements to make progress. You desperately remained on your position > without any *fact* to explain it. > > Yeah, whatever. -Ekr > > Can you please run a straw poll to resolve the question of masking. IMO > the > > relevant options are: > > > > > > 0. No masking. > > 1. A short fixed mask carried entirely in the packet. > > 1.5. A short sliding mask derived from a short one carried in the > frame and which does not require many CPU cycles per frame. > > > 2. A longish repeated mask computed from the packet. For concreteness, > > suppose > > HMAC-SHA1(, || || > > ), but > > obviously there's flexibility here. > > 3. A fully generated mask, e.g., using AES-CTR or HMAC-SHA for each byte. > > We should clarify one important point as well : > 1. mask framing headers > 2. mask payload only > > Regards, > Willy > > --001636284f605a8342049957e047 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jan 8, 2011 at 7:31 AM, Willy T= arreau <w@1wt.eu> wrote:
On Sat, Jan 08, 2011 at 07:09:07AM -0800, Eric Rescorla w= rote:
> Chairs; I think it's clear that we're long past anything that = is new being
> said here.

You're exagerating Eric. I have provided code, examples and perfo= rmance
measurements to make progress. You desperately remained on your position without any *fact* to explain it.


Yeah, whatever= .

-Ekr
=A0
> Can you please run a straw poll to resolve the question of masking. IM= O the
> relevant options are:
>
>
> 0. No masking.
> 1. A short fixed mask carried entirely in the packet.

1.5. A short sliding mask derived from a short one carried in the
=A0 =A0 frame and which does not require many CPU cycles per frame.

> 2. A longish repeated mask computed from the packet. For concreteness,=
> suppose
> =A0 =A0 HMAC-SHA1(<uuid>, <server-conn-key> || <client-= conn-key> ||
> <packet-key>), but
> =A0 =A0 obviously there's flexibility here.
> 3. A fully generated mask, e.g., using AES-CTR or HMAC-SHA for each by= te.

We should clarify one important point as well :
1. mask framing headers
2. mask payload only

Regards,
Willy


--001636284f605a8342049957e047-- From andy.warmcat.com@googlemail.com Sat Jan 8 08:11:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40BAE28C115 for ; Sat, 8 Jan 2011 08:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJhdyQKAeOwi for ; Sat, 8 Jan 2011 08:11:39 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 743D628C118 for ; Sat, 8 Jan 2011 08:11:38 -0800 (PST) Received: by wwa36 with SMTP id 36so18380535wwa.13 for ; Sat, 08 Jan 2011 08:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5TYE7V5a0mczDSq2NBi/lE9MNlRGuKdXQSHO6oEx/x0=; b=Aau6ofJJJa9QRbgUNqWA/x5qgqoemwD6l2OGGiV3HjSNOIXljODeiY+FxeMbWBtZ/T SwnnBI5UIC7u0Ejqf0L/mCDVt/UK0acB9VTd1Lw6T1BwlGZQQEVM3vFZ4zjH/NRjdzgG XiIe3vjwmsi87PbQLH2/XqCkIMpGU4UKVqXZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=v1wxBho25mxSNeMCqzLvVSLcJDtkdjrciuDY7n9eioxUWQKQJac7/L4LQsKyXqhe7h PGTpxNbH84NKO25iuvJKgZ7GvyO8sTCS90koxcsOJdh022pUOaE2eL4JwDRxNG3JUcxd p1hcPkeHRmkIK7LUgkDFoygftnyXHHw6rZotA= Received: by 10.227.154.69 with SMTP id n5mr729683wbw.131.1294503225478; Sat, 08 Jan 2011 08:13:45 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id q18sm18600411wbe.23.2011.01.08.08.13.43 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 08:13:44 -0800 (PST) Sender: Andy Green Message-ID: <4D288D36.8090901@warmcat.com> Date: Sat, 08 Jan 2011 16:13:42 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> In-Reply-To: <20110108152353.GK2479@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:11:40 -0000 On 01/08/11 15:23, Somebody in the thread at some point said: > Also, I'd like to state that it's important to define what we're trying > to achieve. It has been speculated that some intermediaries might skip Yeah that might be a good idea. But, maybe I missed the "point". -Andy From pieterh@gmail.com Sat Jan 8 08:18:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C9D28C15E for ; Sat, 8 Jan 2011 08:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1gqGQThW+FZ for ; Sat, 8 Jan 2011 08:18:14 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6D7BC28C132 for ; Sat, 8 Jan 2011 08:18:14 -0800 (PST) Received: by wyf23 with SMTP id 23so19233816wyf.31 for ; Sat, 08 Jan 2011 08:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=KvQFeSkNwfl9MJZCImAXbiroPhQVWI6PYB3ShrTpNBc=; b=H96qQZWCjyOcT8T9VQxcSJhLEnFUkvk4Y6HHRXymrp9Wso+qsmJ0M6RRH7/wBfEFsa bFhnsTNQvKwCoiZ6e/eyWJVeXKCQLTrXtFtWEIlHyd2SLiWuflsoF6awd9KUiK++Hfhd ngPCSZ2Bf5zbWJlciO9Es7q33ARNtObVXtYzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=i3T5ja3zRJb4kPi1lfHEdWJxvrjO/3VCGECupsEZFyR9Nckr/hXr9WLG4MHxs6LdFa wwZ8qTQjkP22MJsyjj31Bsq1oGo+M0ZtN7zFR4RZjLa95BgtlL/FpuDX57bRxbNb1pWJ 49JbRdgHsJPsU1KJrn9uDjIapj2jPTYIa8GXc= Received: by 10.216.21.66 with SMTP id q44mr1517270weq.10.1294503622116; Sat, 08 Jan 2011 08:20:22 -0800 (PST) MIME-Version: 1.0 Sender: pieterh@gmail.com Received: by 10.216.46.78 with HTTP; Sat, 8 Jan 2011 08:20:01 -0800 (PST) In-Reply-To: <20110108153147.GL2479@1wt.eu> References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108153147.GL2479@1wt.eu> From: Pieter Hintjens Date: Sat, 8 Jan 2011 17:20:01 +0100 X-Google-Sender-Auth: o1FSALPyzAR1cajV74pmwG_37vQ Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:18:16 -0000 On Sat, Jan 8, 2011 at 4:31 PM, Willy Tarreau wrote: > On Sat, Jan 08, 2011 at 07:09:07AM -0800, Eric Rescorla wrote: >> Can you please run a straw poll to resolve the question of masking. IMO = the >> relevant options are: > 1.5. A short sliding mask derived from a short one carried in the > =A0 =A0 frame and which does not require many CPU cycles per frame. +1 until specific issues are raised with it that can be solved reasonably. Willy, I appreciated the running code. -Pieter From andy.warmcat.com@googlemail.com Sat Jan 8 08:18:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4D028C137 for ; Sat, 8 Jan 2011 08:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.254 X-Spam-Level: X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n0EPE3+UyGS for ; Sat, 8 Jan 2011 08:18:50 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 1A88228C11E for ; Sat, 8 Jan 2011 08:18:47 -0800 (PST) Received: by wyf23 with SMTP id 23so19234128wyf.31 for ; Sat, 08 Jan 2011 08:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pc4xL92LzlmLlD0twHadFrGBLJhy+O2kzD3wvFKBo3c=; b=S5RCYMGk34D4lfnGwpT3QdJBQYHfD1sZVDHtlIYwiNt7/xyRgnlmxTDRG9hityySqy AdwD+xVlOzhuXqXPfiZMj5l5OWGZ2KYGngZxzm1oaInWyeRoxWphP/zDFox6pj1njYqy rjOdW002bUEbYar4UaP9Um5l0qiy4IKbjvcaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=vyJtnHA9TrHuqmbeiqBvKgozn8e8Dzwd5xSo3UgnPdjvl7QGCbiBjfbfCQ+pcOQ6BF rXRFTPJVkA4LgiUIHnAbzlFzTKSF+Yx/qnA2KjFiwQLBfrZxKhBoI3W5Gc0hfkgx8UzT FZk9O8r42iaC7zTUuiad98CccfgVMBXzCMmQE= Received: by 10.227.156.69 with SMTP id v5mr595696wbw.10.1294503655817; Sat, 08 Jan 2011 08:20:55 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id f35sm18589450wbf.14.2011.01.08.08.20.54 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 08:20:54 -0800 (PST) Sender: Andy Green Message-ID: <4D288EE1.3060601@warmcat.com> Date: Sat, 08 Jan 2011 16:20:49 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> <20110108160046.GN2479@1wt.eu> In-Reply-To: <20110108160046.GN2479@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:18:51 -0000 On 01/08/11 16:00, Somebody in the thread at some point said: >> 0x84 0x06 "GET / " >> 0x04 0x08 "HTTP/1.1" >> >> (maybe it would need an IMPLICIT_MORE bit rather than already spec'ed MORE bit) >> >> >> Looks much simpler to implement as part of WebSocket's data framing on >> the client and still allows servers to use sendfile or similar as they >> see fit. >> Sorry for the noise if I'm completely off-track :-) > > No you're not off-track and it's a really good idea. In my opinion it Making HTTP/ unspeakable sounds a lot more lightweight and deterministic to me too than some terrifically high bar of obfuscation crypto defined by some particular dude "just because". -Andy From mcmanus@ducksong.com Sat Jan 8 09:02:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CE43A67DF for ; Sat, 8 Jan 2011 09:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKBypXO68SG6 for ; Sat, 8 Jan 2011 09:02:13 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 060963A67C0 for ; Sat, 8 Jan 2011 09:02:09 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id C698410305; Sat, 8 Jan 2011 12:04:17 -0500 (EST) 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 087FD1030A; Sat, 8 Jan 2011 12:04:12 -0500 (EST) From: "Pat McManus @Mozilla" To: andy@warmcat.com In-Reply-To: <4D288EE1.3060601@warmcat.com> References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> <20110108160046.GN2479@1wt.eu> <4D288EE1.3060601@warmcat.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 08 Jan 2011 12:04:01 -0500 Message-ID: <1294506241.7650.40.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:02:14 -0000 On Sat, 2011-01-08 at 16:20 +0000, Andy Green wrote: > defined > by some particular dude "just because". > You are being unfair to Eric and his substantive contributions to both this group, this discussion, and the Internet community. That being said, I haven't yet heard anything that makes me concerned that an attacker can "produce a messasge with a particular structure" using an inexpensive sliding mask. It appears that that concern falls outside the class of attacks we should realistically be worrying about which is the attacker generating specific byte sequences of her choosing. I'm interested in hearing any arguments that advance my understanding of the risk of such a simple mask beyond "it allows the attacker to produce non-random (but also non-controllable) bytes". What is the relationship here that leads us down a dangerous looking path? If I've missed them in the recent torrent of dialogue, I apologize in advance and appreciate the pointers. -Pat -- http://www.getfirefox.com/ From ekr@rtfm.com Sat Jan 8 09:29:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FED93A67AD for ; Sat, 8 Jan 2011 09:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAoYTGdpzpo4 for ; Sat, 8 Jan 2011 09:29:31 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id B65013A67E3 for ; Sat, 8 Jan 2011 09:29:31 -0800 (PST) Received: by ywk9 with SMTP id 9so8022104ywk.31 for ; Sat, 08 Jan 2011 09:31:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.2.23 with SMTP id 23mr4538670agb.106.1294507899690; Sat, 08 Jan 2011 09:31:39 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sat, 8 Jan 2011 09:31:39 -0800 (PST) In-Reply-To: <1294506241.7650.40.camel@ds9.ducksong.com> References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> <20110108160046.GN2479@1wt.eu> <4D288EE1.3060601@warmcat.com> <1294506241.7650.40.camel@ds9.ducksong.com> Date: Sat, 8 Jan 2011 09:31:39 -0800 Message-ID: From: Eric Rescorla To: "Pat McManus @Mozilla" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:29:32 -0000 On Sat, Jan 8, 2011 at 9:04 AM, Pat McManus @Mozilla wrote: > On Sat, 2011-01-08 at 16:20 +0000, Andy Green wrote: >> =A0defined >> by some particular dude "just because". >> > > You are being unfair to Eric and his substantive contributions to both > this group, this discussion, and the Internet community. > > That being said, I haven't yet heard anything that makes me concerned > that an attacker can "produce a messasge with a particular structure" > using an inexpensive sliding mask. It appears that that concern falls > outside the class of attacks we should realistically be worrying about > which is the attacker generating specific byte sequences of her > choosing. > > I'm interested in hearing any arguments that advance my understanding of > the risk of such a simple mask beyond "it allows the attacker to produce > non-random (but also non-controllable) bytes". What is the relationship > here that leads us down a dangerous looking path? If I've missed them in > the recent torrent of dialogue, I apologize in advance and appreciate > the pointers. Hi Patrick, I don't really have anything that I expect to be convincing to the non-paranoid. The attack vector (if there is any) is as you say: an attacker can control the bytes so that they are non-random, but only partly controllable (i.e., they can guarantee any chosen relationship between two bytes masklen apart). I don't have an attack that actually exploits this, it just gives me a bad feeling: in the security community we try to design stuff that is secure with only very weak assumptions about the threat model and it seems clear that indistinguishability requires weaker assumptions, so all else being equal, that seems like a better choice. Now, obviously all else isn't equal, and if there is a major objection to stronger masking, then that should override my (and others, I would note) icky feelings about weak masking. However, the only argument against stronger masking that I'm aware of, namely that it has a performance cost, seems to me to be extremely weak in view not only of the performance of existing machines and of the expected increase in performance in the future. So on balance I continue to favor stronger masking. However, I can certainly understand how others would feel differently. -Ekr From andy.warmcat.com@googlemail.com Sat Jan 8 09:33:45 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C3A3A67F1 for ; Sat, 8 Jan 2011 09:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2MHDZOexYZM for ; Sat, 8 Jan 2011 09:33:44 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id CE3E63A67DF for ; Sat, 8 Jan 2011 09:33:40 -0800 (PST) Received: by wyf23 with SMTP id 23so19275736wyf.31 for ; Sat, 08 Jan 2011 09:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GWoMa7ACw18NgLHJDyxNUOzgUGpONJ2rJZRxNWyRtkc=; b=muHQtqC2Z9S/qpNixEKm9v/LAM8gKiypYG4+PpoLPBWgfe09E+88TbciqTEqm0PPDv E6Nev21Cpeu1dhjoaMlbSjPFvTULqkc3uY3QcS/3l1SRThfdbUSczbVEU3q6/8MDiIju V1zXybLStwaqVKRsVNy/m7i5F3TdzsNsJP2nA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=s9/zf0W8Pb+U1Iy70STv36k+BjsckJPJ2Uv6wNoo3ICaEYgI0bJcdwn4rnBO99tEXb eS8wghs4L4yOdzSFCrQSLd3ZlIFi+f4Vl+tGUyOm52UkYYERGGfAnpbSglXh2Eea+ZV0 Ms3iZn9oXLBmjDU8vcmDXOmgGlzXCx/ejz6eE= Received: by 10.227.159.68 with SMTP id i4mr9883186wbx.176.1294508129103; Sat, 08 Jan 2011 09:35:29 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id q18sm18637761wbe.17.2011.01.08.09.35.28 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 09:35:28 -0800 (PST) Sender: Andy Green Message-ID: <4D28A05F.9070100@warmcat.com> Date: Sat, 08 Jan 2011 17:35:27 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Pat McManus @Mozilla" References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> <20110108160046.GN2479@1wt.eu> <4D288EE1.3060601@warmcat.com> <1294506241.7650.40.camel@ds9.ducksong.com> In-Reply-To: <1294506241.7650.40.camel@ds9.ducksong.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:33:45 -0000 On 01/08/11 17:04, Somebody in the thread at some point said: > On Sat, 2011-01-08 at 16:20 +0000, Andy Green wrote: >> defined >> by some particular dude "just because". >> > > You are being unfair to Eric and his substantive contributions to both > this group, this discussion, and the Internet community. Hey, thanks for alerting me to how unfair you think I am being. If you could provide any evidence about why what I said is unfair other than just announcing your opinion out of the blue, that would be even more awesome. I base what I am saying on what I read on this list, where Willy seems to be sending out facts and code and Eric is sending out "whatever". > That being said, I haven't yet heard anything that makes me concerned > that an attacker can "produce a messasge with a particular structure" > using an inexpensive sliding mask. It appears that that concern falls > outside the class of attacks we should realistically be worrying about > which is the attacker generating specific byte sequences of her > choosing. As I have said several times, I do not believe the case has been made we should care about even that; IMO we should wash our hands of these alleged broken intermediaries because there is no end to it. Don't forget this is in a context where it can only be an intermediary targeted, and one that is broken in specific ways that is claimed to exist only after one unrepeatable -- Pons and Fleischmann style -- test. > I'm interested in hearing any arguments that advance my understanding of How about you turn your intellect to Cedric Vivier's novel suggestion to simply disallow "HTTP/" in websocket packets as well as the "political mainstream" masking and announce your thoughts on that. -Andy From neonux@gmail.com Sat Jan 8 09:59:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382C53A677C for ; Sat, 8 Jan 2011 09:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YQSE24vkS98 for ; Sat, 8 Jan 2011 09:59:56 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 729463A635F for ; Sat, 8 Jan 2011 09:59:51 -0800 (PST) Received: by wyf23 with SMTP id 23so19288681wyf.31 for ; Sat, 08 Jan 2011 10:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=nnQin8/+tw9GN92v+z3N7FGHR5FIejC67igUU7B7Dn4=; b=DJ3gLBjuKG9Zq2l9QdT+2dKXqCO9r+j+yujctW19GBi8s23d+kU5zmf6oytSqvKVls ocqUDQJ7vU7AQClz/eN2GdqKTRuPav0tAa6v0SHd7H2D7iKdE2hcACwzxzUNC8Pdiz6e igxFIZF+HP8r+WN16MYvFmRyJK8c4VQn9pWxU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=GOc1iEEHl067il63l60cbPs7V94nXqhJVF6IPBHRmq0jH1kTkRkaXYu7AAJhtHJuOt eu8+LlHNaZxpVgE1ZnkjLX4gWkvDTQHIae64v20tAcJWUUM2wGGieOmO6swqpb8Gm+xC yrxzxDEcpsKYJ+S1WBc0X4p+t+VRHt3FPMvrQ= Received: by 10.227.143.18 with SMTP id s18mr16817450wbu.98.1294509714834; Sat, 08 Jan 2011 10:01:54 -0800 (PST) MIME-Version: 1.0 Sender: neonux@gmail.com Received: by 10.227.3.19 with HTTP; Sat, 8 Jan 2011 10:01:24 -0800 (PST) In-Reply-To: <1294506241.7650.40.camel@ds9.ducksong.com> References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> <20110108160046.GN2479@1wt.eu> <4D288EE1.3060601@warmcat.com> <1294506241.7650.40.camel@ds9.ducksong.com> From: Cedric Vivier Date: Sun, 9 Jan 2011 02:01:24 +0800 X-Google-Sender-Auth: GQisc7KuaOAn0lasLRBOroSGisU Message-ID: To: "Pat McManus @Mozilla" Content-Type: text/plain; charset=UTF-8 Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:59:57 -0000 On Sun, Jan 9, 2011 at 01:04, Pat McManus @Mozilla wrote: > I'm interested in hearing any arguments that advance my understanding of > the risk of such a simple mask beyond "it allows the attacker to produce > non-random (but also non-controllable) bytes". Considering an attacker could control of both the JavaScript application and the WebSocket server (ie. a malicious website rather than a XSS), simple masking certainly feels a fragile protection against a determined attacker and I share Eric's concerns about it. On top of this, even simple inexpensive masking significantly limits potential efficiency of WebSocket servers as it makes any payload essentially uncacheable therefore blocks usage of efficient and scalable zero-copy mechanisms (sendfile/splice/tee/..) that are used in modern HTTP servers. Fragmenting messages containing "HTTP/" or, even simpler, inserting a 'break' byte every 8 bytes of the payload, seems like a simple and minimum overhead way to guarantee an attacker cannot send out bytes that would look like a request, while keeping the payload zero-copy friendly for servers. Regards, From salvatore.loreto@ericsson.com Sat Jan 8 10:16:49 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D09233A67FC for ; Sat, 8 Jan 2011 10:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq5i9vIw2Gx3 for ; Sat, 8 Jan 2011 10:16:48 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9CE303A677C for ; Sat, 8 Jan 2011 10:16:47 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-38-4d28aa8f3ef9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 16.EC.13987.F8AA82D4; Sat, 8 Jan 2011 19:18:55 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Sat, 8 Jan 2011 19:18:54 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2CACB2595 for ; Sat, 8 Jan 2011 20:18:55 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EA8B450115 for ; Sat, 8 Jan 2011 20:18:54 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 73CBD4E704 for ; Sat, 8 Jan 2011 20:18:54 +0200 (EET) Message-ID: <4D28AA8E.4080400@ericsson.com> Date: Sat, 8 Jan 2011 19:18:54 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:16:49 -0000 On 1/8/11 4:09 PM, Eric Rescorla wrote: > Or more properly, you have not proven that there is no risk, but > rather that > there is no risk, but merely chosen a particular attack. To repeat > myself for > the umpteenth time, an attacker can use a sliding mask to produce a > message > with a particular structure. They cannot do that with a generated (CTR > or HMAC) > solution. No, I do not have an attack, but indistinguishability from > random > is stronger than not. > > As for your "official" objection, yes, yes, I know you object. Making > it "official" > doesn't somehow change anything. > > > Chairs; I think it's clear that we're long past anything that is new > being said here. > > Can you please run a straw poll to resolve the question of masking. > IMO the > relevant options are: > > > 0. No masking. (as co-chair) there is already a clear consensus about masking from the straw poll ended yesterday so "No masking" is not a possibility for a new poll. The straw poll ended yesterday has showed a great consensus about the GET+Upgrade+Masking approach with mandatory masking from client to server of course all the details about how it will play out are already agreed. So we will consider the possibility to run a poll to resolve the question of masking. cheers /Sal From salvatore.loreto@ericsson.com Sat Jan 8 10:18:54 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0E63A6804 for ; Sat, 8 Jan 2011 10:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls5RPohdV995 for ; Sat, 8 Jan 2011 10:18:52 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1BCA63A6810 for ; Sat, 8 Jan 2011 10:18:51 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-a1-4d28ab0b92a7 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B9.64.23694.B0BA82D4; Sat, 8 Jan 2011 19:20:59 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Sat, 8 Jan 2011 19:20:59 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5B7452595 for ; Sat, 8 Jan 2011 20:20:58 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 28E2E50115 for ; Sat, 8 Jan 2011 20:20:57 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B22874E704 for ; Sat, 8 Jan 2011 20:20:56 +0200 (EET) Message-ID: <4D28AB08.8080907@ericsson.com> Date: Sat, 8 Jan 2011 19:20:56 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <4D28AA8E.4080400@ericsson.com> In-Reply-To: <4D28AA8E.4080400@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:18:54 -0000 On 1/8/11 7:18 PM, Salvatore Loreto wrote: > On 1/8/11 4:09 PM, Eric Rescorla wrote: >> Or more properly, you have not proven that there is no risk, but >> rather that >> there is no risk, but merely chosen a particular attack. To repeat >> myself for >> the umpteenth time, an attacker can use a sliding mask to produce a >> message >> with a particular structure. They cannot do that with a generated (CTR >> or HMAC) >> solution. No, I do not have an attack, but indistinguishability from >> random >> is stronger than not. >> >> As for your "official" objection, yes, yes, I know you object. Making >> it "official" >> doesn't somehow change anything. >> >> >> Chairs; I think it's clear that we're long past anything that is new >> being said here. >> >> Can you please run a straw poll to resolve the question of masking. >> IMO the >> relevant options are: >> >> >> 0. No masking. > (as co-chair) > > there is already a clear consensus about masking from the straw poll > ended yesterday > so "No masking" is not a possibility for a new poll. > > > The straw poll ended yesterday has showed a great consensus about the > GET+Upgrade+Masking approach > with mandatory masking from client to server > > of course all the details about how it will play out are already agreed. I meant "all the details about how it will play out are not yet decided neither agreed" > So we will consider the possibility to run a poll to resolve the > question of masking. > > > cheers > /Sal > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi -- Salvatore Loreto www.sloreto.com From mcmanus@ducksong.com Sat Jan 8 10:19:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5B83A67FC for ; Sat, 8 Jan 2011 10:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1DVmefmB6tM for ; Sat, 8 Jan 2011 10:19:39 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id C58D03A677C for ; Sat, 8 Jan 2011 10:19:39 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id 23B9210305; Sat, 8 Jan 2011 13:21:47 -0500 (EST) 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 6566010157; Sat, 8 Jan 2011 13:21:43 -0500 (EST) From: "Pat McManus @Mozilla" To: Cedric Vivier In-Reply-To: References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> <20110108160046.GN2479@1wt.eu> <4D288EE1.3060601@warmcat.com> <1294506241.7650.40.camel@ds9.ducksong.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 08 Jan 2011 13:21:31 -0500 Message-ID: <1294510891.7650.87.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:19:41 -0000 Hi Cedric, On Sun, 2011-01-09 at 02:01 +0800, Cedric Vivier wrote: > On Sun, Jan 9, 2011 at 01:04, Pat McManus @Mozilla wrote: > > I'm interested in hearing any arguments that advance my understanding of > > the risk of such a simple mask beyond "it allows the attacker to produce > > non-random (but also non-controllable) bytes". > > Considering an attacker could control of both the JavaScript > application and the WebSocket server (ie. a malicious website rather > than a XSS), simple masking certainly feels a fragile protection > against a determined attacker and I share Eric's concerns about it. > "feels fragile" doesn't resonate with me in this context on its own without more reasoning. I'm not speaking for anyone else. > On top of this, even simple inexpensive masking significantly limits > potential efficiency of WebSocket servers as it makes any payload > essentially uncacheable therefore blocks usage of efficient and > scalable zero-copy mechanisms (sendfile/splice/tee/..) that are used > in modern HTTP servers. > In order to mitigate this the masking is applied unidirectionally from client toward the server. The client is unlikely to have the kind of data that benefits from zero copy (i.e. in page cache sent to multiple recipients) and in any event is much less likely to have highly scalable workloads where the copy-based IO is super relevant. A compromised server can already send whatever bytes it wants in the server->client direction. The mask prevents the server from generating bytes that travel from client to server and potentially cross an intermediary along the way. > > Fragmenting messages containing "HTTP/" or, even simpler, inserting a > 'break' byte every 8 bytes of the payload, seems like a simple and > minimum overhead way to guarantee an attacker cannot send out bytes > that would look like a request, while keeping the payload zero-copy > friendly for servers. > in general I don't like the complexity of things that have to statefully scan, pad to different lengths, and fragment payloads. Lots of state and branching in the algorithm and in turn it only addresses a particular attack rather than a category of attack. I don't see an advantage over a simple cheap-per-message XOR. -Pat -- http://www.getfirefox.com/ From jat@google.com Sat Jan 8 10:26:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118133A677C for ; Sat, 8 Jan 2011 10:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.753 X-Spam-Level: X-Spam-Status: No, score=-104.753 tagged_above=-999 required=5 tests=[AWL=-1.776, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWnqOY9irsal for ; Sat, 8 Jan 2011 10:26:00 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 0EE793A67FC for ; Sat, 8 Jan 2011 10:25:59 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p08IS6bl029005 for ; Sat, 8 Jan 2011 10:28:06 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294511287; bh=Cn3ZKf7EFZtA2pVSkg0O0yjOWPU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tcg3MB7QadCOGsFzXg7uVdAMXT0ExWEL7zBveSszwJSQLQGOsdkgyTHUtFSwEjT08 3z/JodZuVr2gh3w9euQsA== Received: from yie19 (yie19.prod.google.com [10.243.66.19]) by wpaz33.hot.corp.google.com with ESMTP id p08IS499011247 for ; Sat, 8 Jan 2011 10:28:04 -0800 Received: by yie19 with SMTP id 19so5585402yie.17 for ; Sat, 08 Jan 2011 10:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=4PLsrCE7nJ8nH7wa0Oe04Pmaks0QGrg2/8jvLn1ZDRE=; b=FdNp5pAQUoOc+0rN28gXNlyK5zaAIl8syuG+6rpw2KKy9Kx8JkQk07Lgr+B9perNrv 3m7wBG8jCSvkneFKyDLA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=QoSTfswNydfQOy+xUQo705+tr0ywZVxk3R/VkGUhJwJP3Y4C1mjV0IZ6tITykF8wS3 13/l5bpDHqTOADPsSArw== Received: by 10.151.143.12 with SMTP id v12mr27229982ybn.35.1294511284334; Sat, 08 Jan 2011 10:28:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Sat, 8 Jan 2011 10:27:44 -0800 (PST) In-Reply-To: References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> <20110108160046.GN2479@1wt.eu> <4D288EE1.3060601@warmcat.com> <1294506241.7650.40.camel@ds9.ducksong.com> From: John Tamplin Date: Sat, 8 Jan 2011 13:27:44 -0500 Message-ID: To: Cedric Vivier Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:26:01 -0000 On Sat, Jan 8, 2011 at 1:01 PM, Cedric Vivier wrote: > Fragmenting messages containing "HTTP/" or, even simpler, inserting a > 'break' byte every 8 bytes of the payload, seems like a simple and > minimum overhead way to guarantee an attacker cannot send out bytes > that would look like a request, while keeping the payload zero-copy > friendly for servers. I am not sure zero-copy of 8 byte payloads is something to count as an advantage, and it also seems unlikely the client is going to benefit from zero-copy sends anyway (as an example, many browsers store the text internally as UTF16 so it already has to be converted to UTF8 before sending in a text frame -- it is easy to just do the XOR as you build that frame). Also, this feels very fragile -- do you also split on "http/", "Http/", etc for ones that might interpret it in a case insensitive manner? Finally, from an implementation point of view, this seems far more complicated than a simple XOR and the extra branches are likely to be slower than in-register math if you are counting down to that level. -- John A. Tamplin Software Engineer (GWT), Google From bruce@callenish.com Sat Jan 8 10:31:25 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4213A67FC for ; Sat, 8 Jan 2011 10:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZKy2UcNU3fP for ; Sat, 8 Jan 2011 10:31:23 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 6F67B3A677C for ; Sat, 8 Jan 2011 10:31:23 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PbdbX-00015a-7O for hybi@ietf.org; Sat, 08 Jan 2011 10:33:31 -0800 Message-ID: <4D28AE05.4070500@callenish.com> Date: Sat, 08 Jan 2011 10:33:41 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> In-Reply-To: <10468.1294398928.011152@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:31:25 -0000 On 07/01/2011 3:15 AM, Dave Cridland wrote: > > Would the working group consider masking in this parallel universe? Of > course not, because that would be silly. I disagree. I think an argument can be made for masking even in the absence of a known attack. Call me silly if you want to. The simple fact is that there have been a number of protocols introduced over the years where attacks have been developed that were never envisioned by the designers of the specs. I think you can assume the same thing will happen with Websockets, no matter how careful the WG is. But we can see in hindsight that had attackers not been able to control the bits on the wire, a huge class of attacks would not have been possible. Not all attacks, mind you, but a large number. So it is not unreasonable for people to say now, with this new protocol, let us stop attackers from controlling bits on the wire as much as we can. It may never prove to be beneficial, but experience shows us that it is likely to be. The question is how much are we willing to pay for a benefit that we can't quantify and that may never appear. Hopefully, if there were no cost at all to masking you would not have an issue with it. As the cost goes up, we start seeing more and more people decide that the price is too high for a risk that is so nebulous. So there is a real incentive to keeeping the cost of masking low, to me. The other question is whether we can eliminate that cost altogether in situations where we can guarantee via other means that attackers are not controlling the bits. > > intermediaries that are already vulnerable to attacks of the form > we're trying to protect against by using Flash or Java. I keep seeing comparisons of Websockets to Flash and Java. These are not even close to being the same situation. Browser vendors do not develop Flash or Java plugins. They do not ship with them. Many environments forbid the installation of any plugins for exactly the reason that Flash and Java are security risks. When a user installs the plugin, they have to take responsibility for doing so, and any bugs or security issues are directed to Adobe or Oracle or whoever developed the plugin. Websockets is different. Websockets is going to be part of the browser. The browser vendors are going to ship their own code. That means that they are responsible for Websockets, as they are not responsible for Flash and Java. It also means that browsers will always have an implementation of Websockets installed in all environments, including the ones that don't allow plugins (although they may be configured to turn it off). > (And, maybe, ActiveX?) One assumes that, therefore, these will be > fixed, and not just due to websockets, but due to the far more widely > used rich content technologies of today. That seems to be false given that they haven't been fixed to date. I doubt that any browser vendor wants to take the risk and assume they will be fixed, only to see themselves labeled "Insecure" by people who don't understand where the real security vulnerability was. This is a known vulnerability. No major browser vendor is going to ship a Websockets implementation that is exposed to it. They have all said so on this list. Let's move on. From neonux@gmail.com Sat Jan 8 10:39:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4033A6804 for ; Sat, 8 Jan 2011 10:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtFqzOSIW4Se for ; Sat, 8 Jan 2011 10:39:36 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A16CB3A67FC for ; Sat, 8 Jan 2011 10:39:36 -0800 (PST) Received: by wyf23 with SMTP id 23so19309596wyf.31 for ; Sat, 08 Jan 2011 10:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=J4JlTWm+wlSbfVDrffPvCufxIe+Fpnuyqhy3vxEMuvQ=; b=rijcs0bpriDXnrrgOm6NSS9uqPWSB7MFMbEC7mbuIm3wuIOQEhd506IbXUoPfop+fk j4V0KrJJ1j/hvCTT25s6DMPj4KIZS0XRESH6/n/lVP+NJyLwM03ctJf9+83n/uMHAxwT BvJSzxaxAUnZVKymGJ3RDSYbRMLDgIQCLt2PY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Y/WhV/jw3MRDlAK1HUkKZhxEurJtUtyNSBqkaSm9ooNtNA5i6cCAtgLVgc0N/c3W2z NKKQ+R2843RFyLT06uNKRXsSgfUMIJf4DWzXIwXtH0X2atmyZgauqGpN6uQYiOltgEZ5 J3QpISrxLX1UMCbsTKZxEAB43rig3QrlEd/rA= Received: by 10.227.107.99 with SMTP id a35mr4717006wbp.156.1294512076347; Sat, 08 Jan 2011 10:41:16 -0800 (PST) MIME-Version: 1.0 Sender: neonux@gmail.com Received: by 10.227.3.19 with HTTP; Sat, 8 Jan 2011 10:40:46 -0800 (PST) In-Reply-To: References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> <20110108160046.GN2479@1wt.eu> <4D288EE1.3060601@warmcat.com> <1294506241.7650.40.camel@ds9.ducksong.com> From: Cedric Vivier Date: Sun, 9 Jan 2011 02:40:46 +0800 X-Google-Sender-Auth: G7y4U2MI1Wdr2f6tgmEM_qYVpDs Message-ID: To: John Tamplin Content-Type: text/plain; charset=UTF-8 Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:39:37 -0000 On Sun, Jan 9, 2011 at 02:27, John Tamplin wrote: > On Sat, Jan 8, 2011 at 1:01 PM, Cedric Vivier wrote: >> Fragmenting messages containing "HTTP/" or, even simpler, inserting a >> 'break' byte every 8 bytes of the payload, seems like a simple and >> minimum overhead way to guarantee an attacker cannot send out bytes >> that would look like a request, while keeping the payload zero-copy >> friendly for servers. > > I am not sure zero-copy of 8 byte payloads is something to count as an > advantage, and it also seems unlikely the client is going to benefit > from zero-copy sends anyway (as an example, many browsers store the > text internally as UTF16 so it already has to be converted to UTF8 > before sending in a text frame -- it is easy to just do the XOR as you > build that frame). Indeed. I assumed the masking was bi-directional, so a simple fragmentation or byte insertion would have still kept the payload easily cacheable on the server after preprocessing once (later send the whole-length cached preload in one 'zero-copy call'). Now that masking is clarified to be for client-to-server direction only, the concern regarding above use case is moot. Regards, From bruce@callenish.com Sat Jan 8 10:58:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86513A6805 for ; Sat, 8 Jan 2011 10:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt5kfnux0EWH for ; Sat, 8 Jan 2011 10:58:03 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 2098F3A6802 for ; Sat, 8 Jan 2011 10:58:03 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pbe1K-00009v-Vp for hybi@ietf.org; Sat, 08 Jan 2011 11:00:11 -0800 Message-ID: <4D28B445.2010402@callenish.com> Date: Sat, 08 Jan 2011 11:00:21 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4D25A492.20701@warmcat.com> <10468.1294318555.770054@puncture> <4D25C033.3010501@warmcat.com> <10468.1294322396.906068@puncture> <4D25D82A.8070302@warmcat.com> <20110106184607.GB27099@1wt.eu> <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:58:03 -0000 On 06/01/2011 9:47 PM, Eric Rescorla wrote: > Really? That's not the behavior I'm familar of with chat systems, > where things > are generally phrased in stanzas that are > 20 bytes longs. This is > true of > XMPP, for instance. What systems are you thinking of? Why are you claiming to know all the ways a protocol that hasn't even been released yet is going to be used? How many bytes long will Google Wave Websocket messages be 5 years from now? Or Suggest? Or any of a million other examples, including a bunch that will only be invented if Websockets is lean enough to allow them to exist. Bulking things up because current usage doesn't allow for the kinds of applications and message sizes that Willy is talking about is pretty shortsighted. From andy.warmcat.com@googlemail.com Sat Jan 8 11:39:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1146228C145 for ; Sat, 8 Jan 2011 11:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDhiuIhqfIJs for ; Sat, 8 Jan 2011 11:39:02 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DA90C28C157 for ; Sat, 8 Jan 2011 11:38:59 -0800 (PST) Received: by wwa36 with SMTP id 36so18475411wwa.13 for ; Sat, 08 Jan 2011 11:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yBrBxIryVGbExGx26OtdNWj2LjhmvzJMmi62Dg/o470=; b=Ppdyes3ER130r5Bg9S1sKv9Bvle8ZKvevZuaA0rMFNBvhQOaXvZ8OJGJA2Kt4BbWZa dKO/p7etDK32lS/WZd4F1fazKunT1b0sRFzAtKVlseSHemMv2wVQgRar2VeQ45vhIOnZ aahQD68GXk5N0HodZrOfL7JYb5tizgLKAT/YE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=e3dfd5Kltw7Dc/wCNBuk6XRZfqwXjimQhhpxHMbjBCYKd3sLb4E9+aKh5CWzw5yOxu gtH5ObrKO7GFMeA1pe4WexiKu/9O701ovTgdrKIa9z98hIy1BCtxzLoQXY4juGOsRsq7 F9+IkCws6qVXweJmyl+J8kh+uIyKhiH3vm0iI= Received: by 10.227.134.129 with SMTP id j1mr16904508wbt.56.1294515667693; Sat, 08 Jan 2011 11:41:07 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id m10sm18719080wbc.22.2011.01.08.11.40.09 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 11:41:06 -0800 (PST) Sender: Andy Green Message-ID: <4D28BD89.70704@warmcat.com> Date: Sat, 08 Jan 2011 19:39:53 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruce Atherton References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <4D28AE05.4070500@callenish.com> In-Reply-To: <4D28AE05.4070500@callenish.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:39:03 -0000 On 01/08/11 18:33, Somebody in the thread at some point said: > So it is not unreasonable for people to say now, with this new protocol, > let us stop attackers from controlling bits on the wire as much as we > can. It may never prove to be beneficial, but experience shows us that > it is likely to be. Sure that this is not unreasonable? Don't forget a websocket connection that the client can send something on has had to go through the initial handshake dance proving it is talking to a willing partner. It means you can't just spray packets around the internet already; it's a very very narrow attack path for sure, not a generic one. Therefore all this brow-furrowing about what is, if anything, needed in addition to be "nice to the internet" is restricted to unidentified intermediaries broken in a specific way inbetween a client and a real websocket server -- everyone on every side of the debate is willing to concede that AFAIK. > This is a known vulnerability. No major browser vendor is going to ship > a Websockets implementation that is exposed to it. They have all said so > on this list. Let's move on. Actually handwaving that it is a "known vulnerability" over-eggs the pudding. It is very much an unknown and unreproducible alleged vulnerability in software that has not been identified publicly (or AFAIK privately) and may be a byproduct of the interpretation of the testing action. Nobody seems to want to "out" these alleged broken intermediaries as part of the protocol either. Nor is Websockets "exposed" to this alleged vuln as you say, it is claimed it is part of the attack vector, along with wget, curl, nc, anything else you can open a socket connection with. -Andy From gregw@intalio.com Sat Jan 8 12:04:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7CA3A681E for ; Sat, 8 Jan 2011 12:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiArr39DMn6z for ; Sat, 8 Jan 2011 12:04:59 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 08FB63A6814 for ; Sat, 8 Jan 2011 12:04:58 -0800 (PST) Received: by vws7 with SMTP id 7so7391968vws.31 for ; Sat, 08 Jan 2011 12:07:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.194.69 with SMTP id dx5mr8989460vcb.60.1294517226943; Sat, 08 Jan 2011 12:07:06 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sat, 8 Jan 2011 12:07:06 -0800 (PST) In-Reply-To: <4D28AA8E.4080400@ericsson.com> References: <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <4D28AA8E.4080400@ericsson.com> Date: Sat, 8 Jan 2011 21:07:06 +0100 X-Google-Sender-Auth: TpT8mm4hqeF1eEOz4Gy7qcGsOpI Message-ID: From: Greg Wilkins To: Salvatore Loreto Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 20:04:59 -0000 On 8 January 2011 19:18, Salvatore Loreto wrote: > The straw poll ended yesterday has showed a great consensus about the > GET+Upgrade+Masking approach > with mandatory masking from client to server Sal, I certainly did not vote for mandatory masking! The straw poll I voted for was only "upgrade-with-unidirectional-xor-mask" No mention of mandatory and certainly no mention of strong masking that makes the payload totally random. regards From gregw@intalio.com Sat Jan 8 12:07:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B81C3A6818 for ; Sat, 8 Jan 2011 12:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Oc3MaeZTd1d for ; Sat, 8 Jan 2011 12:07:55 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 821993A6814 for ; Sat, 8 Jan 2011 12:07:55 -0800 (PST) Received: by qyk34 with SMTP id 34so423687qyk.10 for ; Sat, 08 Jan 2011 12:10:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.87.13 with SMTP id u13mr22900980qcl.55.1294517400896; Sat, 08 Jan 2011 12:10:00 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sat, 8 Jan 2011 12:10:00 -0800 (PST) In-Reply-To: References: <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108153147.GL2479@1wt.eu> Date: Sat, 8 Jan 2011 21:10:00 +0100 X-Google-Sender-Auth: i9DE7pofaIUEVx8NMtkhvBaFz_I Message-ID: From: Greg Wilkins To: Pieter Hintjens Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 20:07:56 -0000 On 8 January 2011 17:20, Pieter Hintjens wrote: > On Sat, Jan 8, 2011 at 4:31 PM, Willy Tarreau wrote: >> On Sat, Jan 08, 2011 at 07:09:07AM -0800, Eric Rescorla wrote: > >>> Can you please run a straw poll to resolve the question of masking. IMO= the >>> relevant options are: > >> 1.5. A short sliding mask derived from a short one carried in the >> =A0 =A0 frame and which does not require many CPU cycles per frame. > > +1 until specific issues are raised with it that can be solved reasonably= . +1 From salvatore.loreto@ericsson.com Sat Jan 8 12:11:51 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910F828C133 for ; Sat, 8 Jan 2011 12:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmGXULzGveCR for ; Sat, 8 Jan 2011 12:11:50 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4172E28C120 for ; Sat, 8 Jan 2011 12:11:49 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-16-4d28c585196e Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E1.28.23694.585C82D4; Sat, 8 Jan 2011 21:13:58 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Sat, 8 Jan 2011 21:13:57 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 909C22595 for ; Sat, 8 Jan 2011 22:13:57 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5218250535 for ; Sat, 8 Jan 2011 22:13:57 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D6BC04FCB2 for ; Sat, 8 Jan 2011 22:13:56 +0200 (EET) Message-ID: <4D28C584.5080709@ericsson.com> Date: Sat, 8 Jan 2011 21:13:56 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary="------------080609010400030404080909" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] consensus result on Straw Poll: GET+Upgrade+masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 20:11:51 -0000 --------------080609010400030404080909 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit (as co-chair) The straw poll on "*is Upgrade with client->sever XOR mask acceptable*" is over: http://www.ietf.org/mail-archive/web/hybi/current/msg05426.html The mailing list discussion generated by the straw-poll has showed a rough consensus to draft the new WebSocket handshake (and insert it in the 04 version of the draft) based on a GET + Upgrade + Masking approach where - Masking is mandatory on the client-to-server direction - Masking is not done on the server-to-client direction moreover from the discussion is also emerged a strong consensus on a XOR-based masking. as said in a previous mail (in a different thread) details how this will play out are yet to be discussed/agreed. best regards /Sal -- Salvatore Loreto www.sloreto.com --------------080609010400030404080909 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit (as co-chair)

The straw poll on "is Upgrade with client->sever XOR mask acceptable" is over:
http://www.ietf.org/mail-archive/web/hybi/current/msg05426.html


The mailing list discussion generated by the straw-poll has showed a rough consensus
to draft the new WebSocket handshake (and insert it in the 04 version of the draft) based on

a GET + Upgrade + Masking approach

where
- Masking is mandatory on the client-to-server direction
- Masking is not done on the server-to-client direction

moreover from the discussion is also emerged a strong consensus on a XOR-based masking.


as said in a previous mail (in a different thread) details how this will play out are yet to be discussed/agreed.

best regards
/Sal
-- 
Salvatore Loreto
www.sloreto.com
--------------080609010400030404080909-- From salvatore.loreto@ericsson.com Sat Jan 8 12:20:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C913A681B for ; Sat, 8 Jan 2011 12:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wasBK2aUTGxd for ; Sat, 8 Jan 2011 12:20:52 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 679003A681A for ; Sat, 8 Jan 2011 12:20:52 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-af-4d28c7a45427 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 27.F0.13987.4A7C82D4; Sat, 8 Jan 2011 21:23:00 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Sat, 8 Jan 2011 21:22:59 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A4CDC2595; Sat, 8 Jan 2011 22:22:59 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 690F750535; Sat, 8 Jan 2011 22:22:59 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D6C184FCB2; Sat, 8 Jan 2011 22:22:58 +0200 (EET) Message-ID: <4D28C7A2.1060504@ericsson.com> Date: Sat, 8 Jan 2011 21:22:58 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Greg Wilkins References: <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <20110107222312.GA2479@1wt.eu> <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <4D28AA8E.4080400@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 20:20:58 -0000 On 1/8/11 9:07 PM, Greg Wilkins wrote: > On 8 January 2011 19:18, Salvatore Loreto wrote: >> The straw poll ended yesterday has showed a great consensus about the >> GET+Upgrade+Masking approach >> with mandatory masking from client to server > Sal, > > I certainly did not vote for mandatory masking! > The straw poll I voted for was only "upgrade-with-unidirectional-xor-mask" as I said in the mails there are still details that need to be agreed. one is what mandatory means! the John proposal (http://www.ietf.org/mail-archive/web/hybi/current/msg05559.html) seems to be a possible compromise we can work on > No mention of mandatory and certainly no mention of strong masking > that makes the payload totally random. what kind of masking and how strong it has to be is another point yet to be discussed/agreed cheers /Sal > > regards -- Salvatore Loreto www.sloreto.com From bruce@callenish.com Sat Jan 8 14:02:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524D83A68B9 for ; Sat, 8 Jan 2011 14:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPYVJvNJHxkD for ; Sat, 8 Jan 2011 14:02:12 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 8F9573A6831 for ; Sat, 8 Jan 2011 14:02:12 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PbgtY-0005VR-Ie for hybi@ietf.org; Sat, 08 Jan 2011 14:04:20 -0800 Message-ID: <4D28DF6E.4080003@callenish.com> Date: Sat, 08 Jan 2011 14:04:30 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 22:02:13 -0000 On 07/01/2011 1:19 PM, Eric Rescorla wrote: > > My objective is to make the bits that appear on the wire > indistinguishable from random > from the attacker's perspective. I think it's clear that this is the > strongest form of masking > available, and the method I proposed does that. It is true that your goal is clear, but I don't understand why you think this goal is necessary. The specification already allows for two forms of Websocket, a simple one denoted by the scheme "ws:" and a secure one denoted with "wss:". The latter one will have the random byte stream characteristics you are interested in. If you are uncomfortable with any other kind of stream, make sure your client only supports secure Websockets. The reason for the division between the two types is that in some situations, people want the ability to trade-off some security for lower cost. This cost is not just in terms of machine processing, but other things as well. For example, the decreased cost of debugging streams of data when they are decipherable with a tool like Wireshark. Keeping masking simple decreases a bunch of costs in ways that matter enough to people that they are willing to support two separate websocket schemes in order to have that choice. Or perhaps you are actually arguing that your masking should be the mechanism for the wss: scheme? Or that there should be no ws: scheme for anyone? From mjs@apple.com Sat Jan 8 14:24:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592DE3A68BD for ; Sat, 8 Jan 2011 14:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+Nt7IJXwme1 for ; Sat, 8 Jan 2011 14:24:55 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id D79DC3A6842 for ; Sat, 8 Jan 2011 14:24:55 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id B5CA8C5B9BAC for ; Sat, 8 Jan 2011 14:26:52 -0800 (PST) X-AuditID: 11807134-b7cfdae000001831-72-4d28e4acb803 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id 1C.1B.06193.CA4E82D4; Sat, 8 Jan 2011 14:26:52 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.151.81.229] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LEQ00L586CRKI30@elliott.apple.com> for hybi@ietf.org; Sat, 08 Jan 2011 14:26:52 -0800 (PST) From: Maciej Stachowiak In-reply-to: <20110108111632.GI2479@1wt.eu> Date: Sat, 08 Jan 2011 14:26:50 -0800 Message-id: <91303A50-B94E-45C6-8392-9AA9EFD43D94@apple.com> References: <20110108111632.GI2479@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 22:24:57 -0000 Hi Willy, Thanks for actually testing! One thing to note about your experiment - you're testing only a single part of a complete WebSocket service, omitting the I/O parts and whatever processing actually occurs in response to a message received. So I don't think it's correct to infer a percent overhead from this experiment. What we can do, though, is see whether this isolated component alone would be too slow to let us process some number of messages per second. Looking at this another way, I'd like to see how this compares to the goal of 200k messages processed per second on a server handling 1 million concurrent connections. Your test runs everything serially and therefore makes use of only a single CPU core. A realistic scenario would involve processing many connections in parallel. On my system (apparently somewhat slower than yours), here's what I get running 4 tests in parallel: $ time sh -c './ws-parse 1 < /tmp/stream.bin > /dev/null & ./ws-parse 1 < /tmp/stream.bin > /dev/null & ./ws-parse 1 < /tmp/stream.bin > /dev/null & ./ws-parse 1 < /tmp/stream.bin > /dev/null' 20000002 messages forwarded 20000002 messages forwarded 20000002 messages forwarded 20000002 messages forwarded real 1m34.343s user 4m37.364s sys 0m1.459s That's 94 seconds total to process 80 million messages. This would imply a rate of ~850k operations per second, well within the margins for 200k messages processed a second, with plenty of CPU to spare to do the actual processing. Note: I doubt my laptop could actually handle a million concurrent connections as in the example scenario. A dual 6-core 3 GHz Xeon, for example would probably be able to do this 10-20x as fast as my single dual-core 2.66Ghz Core i7. My conclusion: HMAC to compute a per-frame mask would not be an obstacle to handling a million concurrent connections on a single server. It falls well within a reasonable performance target. Regards, Maciej On Jan 8, 2011, at 3:16 AM, Willy Tarreau wrote: > Since I was not convinced at all by the supposedly very low > overhead of using HMAC to compute a masking key, I have written > a WebSocket framing parser which reads, parses and forwards frames. > It supports 7, 16 and 63-bit lengths, stops after forwarding the > last frame with opcode 0x01 and exits with an error if the input > is broken before reaching the end of the closing frame. > > When called with any argument, it computes an hmac-sha1 key derived > from a simple 32-bit constant key (for simplicity) for each frame. > > The payload is not even unmasked with the key, the purpose is just > to evaluate the cost for a front server/load balancer/switch supposed > to switch frames to a server farm. > > I have ran it over a stream of messages whose payload was between 1 > and 125 bytes, with an average of 29 bytes (rnd(1..5) ^ 3), so that > we're in line with many legitimate uses of the protocol such as online > chat, and it happens to always fit in one byte length, making the > stream generator even easier to write. > > The results : > > willy@pcw:~/c$ wc -c /dev/shm/ws-stream.bin > 579976835 /dev/shm/ws-stream.bin > > - without masking : > willy@pcw:~/c$ time ./ws-parse < /dev/shm/ws-stream.bin >/dev/null > 20000001 messages forwarded > > real 0m1.753s > user 0m1.544s > sys 0m0.208s > > => average bit rate : 4.1 Gbps > > - with HMAC-based masking : > willy@pcw:~/c$ time ./ws-parse 1 < /dev/shm/ws-stream.bin >/dev/null > 20000001 messages forwarded > > real 0m42.098s > user 0m41.759s > sys 0m0.212s > > => average bit rate : 172 Mbps > > Masking the stream with HMAC multiplies the parsing time by 24 on small > messages !!! We're not at all in the range of a few percent more. The > parser with HMAC is limited to only 172 Mbps on a 3 GHz system, which > is the speed at which the non-masking parser would run on a 125 MHz > system. > > Considering those facts, I'm strongly opposed to using HMAC as well as > any algorithm which has a similar level of complexity, which is normally > required only for cryptographically strong usages. > > We're not trying to encrypt the stream, we're just ensuring that no > broken intermediary will accidentally find a request that was put > there on purpose by an attacker. Such a complexity is not required > at all and is way overkill. The per-byte masking cost must remain > very low even for small frames. > > I still think that a simple sliding XOR based on a cheap modification > of the seed is far more than enough against choosen text attacks for > this use case, such as the example code I provided yesterday, or any > other one with the same level of complexity. > > The code to reproduce those tests can be freely downloaded there : > > http://1wt.eu/websocket/ > > It's clearly not a model of beauty as it's only a POC. So it's not needed > to comment on its ugliness or its possible improvements. > > Regards, > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From derhoermi@gmx.net Sat Jan 8 14:36:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE233A68D1 for ; Sat, 8 Jan 2011 14:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK7f1OxNG401 for ; Sat, 8 Jan 2011 14:36:40 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 85E013A68D0 for ; Sat, 8 Jan 2011 14:36:38 -0800 (PST) Received: (qmail invoked by alias); 08 Jan 2011 22:38:46 -0000 Received: from dslb-094-223-191-191.pools.arcor-ip.net (EHLO hive) [94.223.191.191] by mail.gmx.net (mp025) with SMTP; 08 Jan 2011 23:38:46 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+IM0ZDTXaIQ5lZLhtPGfTqNsn51w4EjvP/lCzovV v4pwinRISxwIvX From: Bjoern Hoehrmann To: "Pat McManus @Mozilla" Date: Sat, 08 Jan 2011 23:38:36 +0100 Message-ID: <9g6hi6tjasqui4m9m66jtdlvm1c6u6semp@hive.bjoern.hoehrmann.de> References: <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <20110108152353.GK2479@1wt.eu> <20110108160046.GN2479@1wt.eu> <4D288EE1.3060601@warmcat.com> <1294506241.7650.40.camel@ds9.ducksong.com> In-Reply-To: <1294506241.7650.40.camel@ds9.ducksong.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 22:36:41 -0000 * Pat McManus @Mozilla wrote: >That being said, I haven't yet heard anything that makes me concerned >that an attacker can "produce a messasge with a particular structure" >using an inexpensive sliding mask. It appears that that concern falls >outside the class of attacks we should realistically be worrying about >which is the attacker generating specific byte sequences of her >choosing. > >I'm interested in hearing any arguments that advance my understanding of >the risk of such a simple mask beyond "it allows the attacker to produce >non-random (but also non-controllable) bytes". What is the relationship >here that leads us down a dangerous looking path? If I've missed them in >the recent torrent of dialogue, I apologize in advance and appreciate >the pointers. (I wish someone'd thought of asking this before another 100+ thread...) Well, if you take my simple straw man (prefix a mask, xor the following bytes with it, repeating the mask as necessary) then you simple need to arrange the traffic in a manner that keeps the connection alive and send a lot of data; eventually you get the attack payload you want on the wire. If a proxy listening in on the connection somehow manages to skip over all the rubbish and then takes up your attack payload and then does something dangerous with it, then your attack has succeeded. The only questions are whether such proxies are deployed in quantities and configurations that should have us worried (there is no evidence at all that there is a proxy that has the relevant combination of flaws) and how much data you have to make the browser put on the wire. You most likely don't need exactly one out of n keys for an attack to succeed as you have some tolerances like case-insensitive protocol ele- ments, and you can do some things to cleverly arrange the bytes you ask the browser to mask and send, or for that matter you can make the pay- load very large so many keys would work (if the key is just a byte you simply generate all 256 masked payloads). One could look at this by comparing it to another threat. There are for sure intermediaries that have an integer overflow vulnerability with requests that are longer than 2 or 4 GB, so if an attacker can make a HTTP client send a very large crafted payload, an intermediary might take part of the payload as second HTTP request. Should that mean all HTTP clients that send untrusted data must limit the size to 2 GB, or at least heavily encrypt data that is longer? Earlier we talked about using a WEBSOCKET method in the handshake, and Adam Barth reminded us that as far as cross-protocol attacks go, that's a problem because sending "W" at the beginning hasn't been studied. So should that mean over at the W3C "CORS" cannot use "OPTIONS" to verfiy certain requests are welcome because "O" hasn't been studied there? We haven't learned about any new attacks from Adam et al.'s paper, the cache poisoning issue has been known since at least 2005 with request smuggling attacks (fill in a couple of newlines in some XHR header and the proxy sees two requests where the browser thought it's sending one) and the host misdirection attack has been known since at least 2008, it is even mentioned in the Wikipedia article on transparent proxies since 2009 and Roy T. Fielding and Jeff Hodges posted links to Robert Auger's paper to the list in 2009, and the paper also discusses the cache issue. Hasn't stopped Flash and Java plugin vendors from allowing attackers to exploit these issues, hasn't stopped browser vendors from allowing the plugins to run in their software, hasn't stopped Websocket drafts from being adopted in browsers. Again, immediately after this list has been created, Roy T. Fielding noted that an Upgrade handshake succeeding does not mean intermediaries won't mistake further traffic as HTTP traffic. I've been reading this whole discussion as an attempt to find something that's simple and efficient with reasonably low risk. Robustness is the last requirement in our requirements document with a lowercase "should". You can't make any and all servers and intermediaries stop treating traffic as HTTP traffic by sending a couple of magic bits. Water is wet. Seriously, if browser vendors required a zero-risk design where the zero is easy to prove, they should have shot down any and all proposals that do not meet that requirement immediately instead of implementing drafts that very obviously don't meet that requirement. So with the masking straw man above the concern is essentially about a proxy that has never been seen or heard of being vulnerable to attacks we don't quite know how to make feasible. I can understand some worry that this very simple scheme is insufficient, but going from there to "the mask must include a client nonce, must include a server nonce, must include some special secret, must include a block counter, must include a per-frame key, the frame key must at least be 4 bytes long, all the key material must be passed through HMAC-SHA1, the header must be masked, any and all Websocket clients must mask always, ideally put some CONNECT talisman ahead on the connection" and probably things I've missed, is a very very long way. Obviously I am not entirely comfortable with a scheme this simple, or I would not keep calling it a straw man, but among all the proposals we've had, it does seem to meet the many conflicting requirements best, and, unlike the super duper double plus plus extra robust scheme, it's somewhat consistent with how we got here. It also seems wrong to look at this solely from the bits-on-the-wire perspective. Browsers regularily check the web for browser updates and anti-phising lists and whatnot, they could do sanity checks whether the user is behind a vulnerably proxy. They also have XSS filters to check for seemingly dangerous patterns, they could simply pre-scan the masked frame, if it could be mistaken for a HTTP request, pick a different key, if that fails, split the message into multiple frames, or whatever. "If masked payload contains case-insensitively 'Host' regardless of the key chosen, split message at after each 'Ho' into two frames". You now need the previous miracle proxy we don't know exists and an attack we don't know how to make feasible and also some additional proxy bug that allows you to do dangerous things without "Host", at the cost of rare failures because whatever key is applied doesn't prevent "Host", and the server assumed the message would arrive as one frame but did not. Add whatever additional bad words you care about, say "http", or make the patterns a bit more complex to avoid the odd maybe-failure, checking for a double newline somewhere after "Host" for instance. I'm sure of course that's unacceptable, just like all the other proposals. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From w@1wt.eu Sat Jan 8 14:38:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FAF3A68CB for ; Sat, 8 Jan 2011 14:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd9IJtpk33JV for ; Sat, 8 Jan 2011 14:38:26 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 1E65F3A68BD for ; Sat, 8 Jan 2011 14:38:25 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p08MeWuk006661; Sat, 8 Jan 2011 23:40:32 +0100 Date: Sat, 8 Jan 2011 23:40:32 +0100 From: Willy Tarreau To: Salvatore Loreto Message-ID: <20110108224032.GG5743@1wt.eu> References: <20110108001549.GD2479@1wt.eu> <20110108015002.GG2479@1wt.eu> <20110108081232.GH2479@1wt.eu> <4D28AA8E.4080400@ericsson.com> <4D28C7A2.1060504@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D28C7A2.1060504@ericsson.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: [hybi] Using extensions for masking (was: A bit of pragmatism) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 22:38:27 -0000 On Sat, Jan 08, 2011 at 09:22:58PM +0100, Salvatore Loreto wrote: > On 1/8/11 9:07 PM, Greg Wilkins wrote: > >I certainly did not vote for mandatory masking! > >The straw poll I voted for was only "upgrade-with-unidirectional-xor-mask" > as I said in the mails there are still details that need to be agreed. > > one is what mandatory means! > the John proposal > (http://www.ietf.org/mail-archive/web/hybi/current/msg05559.html) > seems to be a possible compromise we can work on I noticed this proposal, it looks like a nice starting point, as well as Greg's reply who reminded his close proposal to help merging the two threads. http://www.ietf.org/mail-archive/web/hybi/current/msg05589.html Since I've not seen any progress after that, and the last poll is over, I think that it could be a good opportunity to try to merge them both. One difference I'm seeing that we should get rid of to start more easily is that John's proposal already names the masking type, and Greg already suggests a fixed length masking key. => we could for now consider "the masking type" and "its key of the adequate length for the masking type". This will make it easier to focus on the general principle of using the extensions for that. Among the comments I have on the proposals, I still think we should use one of the reserved bit to indicate presence of extensions or not, for the day we want to support multiplexing. Otherwise, and old version intermediary might get the framing wrong if it can't detect presence of extensions nor know their length (or maybe we could have the payload len cover the extension data, though that would probably be harder to implement for clients). It could also make it possible to strongly mask some frames (eg: login/passwd). I'm not saying the reserved bit is enough, but rather that it can help decide how to handle extensions when some frames use them and others don't. I find it interesting that both allow some types of communications to happen without masking, considering that there has been some demand that some non-browser clients could avoid masking in some situations. After all, it leaves a choice comparable to how we currently decide whether to use HTTP or HTTPS for some intra-enterprise communications. I like the ability to mask some extensions too, though we should be careful to keep the ability to have some in clear text (eg: support for NAT by some dumb equipments of addresses sent in extension data). Maybe the order of the extensions is enough for that. Regards, Willy From w@1wt.eu Sat Jan 8 15:34:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE1A28C127 for ; Sat, 8 Jan 2011 15:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEWWB4QKjPpT for ; Sat, 8 Jan 2011 15:34:54 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 5F7B928C120 for ; Sat, 8 Jan 2011 15:34:52 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p08NawtD006785; Sun, 9 Jan 2011 00:36:58 +0100 Date: Sun, 9 Jan 2011 00:36:58 +0100 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20110108233658.GH5743@1wt.eu> References: <20110108111632.GI2479@1wt.eu> <91303A50-B94E-45C6-8392-9AA9EFD43D94@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91303A50-B94E-45C6-8392-9AA9EFD43D94@apple.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 23:34:56 -0000 Hi Maciej, On Sat, Jan 08, 2011 at 02:26:50PM -0800, Maciej Stachowiak wrote: > > Hi Willy, > > Thanks for actually testing! One thing to note about your experiment - you're > testing only a single part of a complete WebSocket service, omitting the I/O > parts I/O parts are intentionally not emphasized because depending on what the intermediary does and how the lower levels work, it can represent a very low overhead. For instance, the 10 Gbps Myricom NICs I'm working with are very efficient at doing LRO (Large Receive Offload, which consists in aggregating segments before passing through network layers). The application layer receives TCP segments of about 20-50 kB, which precisely is in the range of the read size I've used in the experiment (32 kB). Sending many segments to a NIC already costs almost nothing with most NICs and drivers today. So as long as the framing permits it, it is possible that a front proxy splits aggregate streams to multiple server farms without too much cost. In fact, what I predict we'll see in the medium term is that we'll have for WebSocket exactly what we already have with HTTP: dedicated boxes which will do TCP packet splicing in ASICs and deliver it to the CPU to perform content-based switching and policy enforcement. Thus the theorical I/O operations cannot really be counted as I/O operations, but much more as messages processed and/or bandwidth. Also, please note that I/Os were not really omitted either, as currently the fwrite() calls are of major concern, because they're responsible for 63% of the CPU usage. I could not count for the read(). I should have used mmap() for that, it was way out of the scope. > and whatever processing actually occurs in response to a message received. Yes indeed. > So I don't think it's correct to infer a percent overhead from this experiment. It depends how you see it, it shows that on the amount of CPU spent in the WS handling code, 96% was spent in HMAC, >2.5% in I/Os, <1.5% in frame parsing. > What we can do, though, is see whether this isolated component alone would be > too slow to let us process some number of messages per second. Which finally is equivalent to see how to size the isolated component for a given task. > Looking at this another way, I'd like to see how this compares to the goal > of 200k messages processed per second on a server handling 1 million concurrent > connections. Your test runs everything serially and therefore makes use of only > a single CPU core. Yes, but that's common across stream processing devices to dedicate cores to functions. That avoids the high cost of locking when there is a need for any type of shared data. > A realistic scenario would involve processing many connections in parallel. > On my system (apparently somewhat slower than yours), here's what I get > running 4 tests in parallel: > > > $ time sh -c './ws-parse 1 < /tmp/stream.bin > /dev/null & ./ws-parse 1 < /tmp/stream.bin > /dev/null & ./ws-parse 1 < /tmp/stream.bin > /dev/null & ./ws-parse 1 < /tmp/stream.bin > /dev/null' > 20000002 messages forwarded > 20000002 messages forwarded > 20000002 messages forwarded > 20000002 messages forwarded > > real 1m34.343s > user 4m37.364s > sys 0m1.459s > > That's 94 seconds total to process 80 million messages. This would imply a rate of ~850k operations per second, well within the margins for 200k messages processed a second, with plenty of CPU to spare to do the actual processing. Note: I doubt my laptop could actually handle a million concurrent connections as in the example scenario. A dual 6-core 3 GHz Xeon, for example would probably be able to do this 10-20x as fast as my single dual-core 2.66Ghz Core i7. Once again, it depends if the workload can realistically be split on multiple cores, but I'm following you on this. > My conclusion: HMAC to compute a per-frame mask would not be an obstacle to handling a million concurrent connections on a single server. It falls well within a reasonable performance target. In a single server the size of yours. Without the HMAC, a much lower-end processor is able to do the task. That means that it can enable routers to perform software-based framing analysis for NAT. It can enable firewalls to perform content analysis at a small cost. Now look at it the other side. Right now we're finding high-end HTTP load balancers capable of handling one million HTTP requests per second, and almost as many connections per second. Those devices sell well BTW, because there is a demand at large ISPs or enterprises. At these rates, they do very little thing. They connect, forward, splice connections together and that's almost all they do. But that's huge because they're offloading a lot of the I/O job for multiple other devices that will be able to individually process their share of the job. Such devices require extremely fast frame processing, that's the key point. The more expensive the per-frame forwarding cost, the higher the number of equipments will be required for the task. Some large sites already struggle with limited infrastructure performance. I recently read somewhere from a Facebook engineer that they were impatient to get 100GB Ethernet, because all their servers are connected at 10GB and that's not enough. Ah it was here : http://www.pcworld.com/businesscenter/article/188412/facebook_sees_need_for_terabit_ethernet.html I don't know what's their bandwidth, but at 500 million users and 250 regular (at least once a month), they must have big fat pipes well used in both directions, with I-don't-know-how-many parallel chat sessions. Also it's important to keep in mind that if WebSocket gets success, it can be adopted in areas we've not thought about. For instance, HTTP is currently used by some databases. It's never fast enough. The "nosql" DBs as some like to call them are stressed to process hundreds of thousands of requests/response a second at even moderately sized sites. HTTP is overkill for the task since the job consists in returning a variable from RAM or storing one, but it's handy. WebSocket might be a very well suited alternative to HTTP for these uses. Wasting a major part of the DB's CPU sycle and latency decoding frames in an environment where it's irrelevant is simply a shame. Other uses : mobile phone operators are progressively pushing IP closer to the radio, even for voice. We could think that WebSocket could be used as an underlying block at some point in those environments for its ability to frame data, and mix various types of frames together (eg: data+voice+signaling with different opcodes). The endpoint which has to process the frames should avoid spending its time doing HMACs that are irrelevant to its use. So as you can see, I'm really concerned by the relative overhead because we'll always find a usage for a given sizing, and that's always been the case since the first network protocols were designed. If IP conceptors 30 years ago had imagined that their packets would be processed by switches at rates over 100 million per second, they would probably have adapted it a little bit to make a few things easier to process for the hardware. That's my concern too : how to ensure it scales smoothly in case it works. Regards, Willy From ekr@rtfm.com Sat Jan 8 15:57:06 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F2628C14F for ; Sat, 8 Jan 2011 15:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP1bQfeMZSdI for ; Sat, 8 Jan 2011 15:57:05 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 73F7E28C120 for ; Sat, 8 Jan 2011 15:57:05 -0800 (PST) Received: by ywk9 with SMTP id 9so8091230ywk.31 for ; Sat, 08 Jan 2011 15:59:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.114.5 with SMTP id m5mr4755195agc.25.1294531153294; Sat, 08 Jan 2011 15:59:13 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sat, 8 Jan 2011 15:59:13 -0800 (PST) In-Reply-To: <91303A50-B94E-45C6-8392-9AA9EFD43D94@apple.com> References: <20110108111632.GI2479@1wt.eu> <91303A50-B94E-45C6-8392-9AA9EFD43D94@apple.com> Date: Sat, 8 Jan 2011 15:59:13 -0800 Message-ID: From: Eric Rescorla To: Maciej Stachowiak Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 23:57:07 -0000 FWIW, I don't know how you're computing HMAC, but the naive implementation is about 1/2 as fast as optimized implementations. The trick is to precompute and cache the hash state after you have incorporated the keys. This saves a bunch of setup overhead. Best, -Ekr On Sat, Jan 8, 2011 at 2:26 PM, Maciej Stachowiak wrote: > > Hi Willy, > > Thanks for actually testing! One thing to note about your experiment - yo= u're testing only a single part of a complete WebSocket service, omitting t= he I/O parts and whatever processing actually occurs in response to a messa= ge received. So I don't think it's correct to infer a percent overhead from= this experiment. What we can do, though, is see whether this isolated comp= onent alone would be too slow to let us process some number of messages per= second. > > > Looking at this another way, I'd like to see how this compares to the goa= l of 200k messages processed per second on a server handling 1 million conc= urrent connections. Your test runs everything serially and therefore makes = use of only a single CPU core. A realistic scenario would involve processin= g many connections in parallel. On my system (apparently somewhat slower th= an yours), here's what I get running 4 tests in parallel: > > > $ time sh -c './ws-parse 1 < /tmp/stream.bin > /dev/null & ./ws-parse 1 <= /tmp/stream.bin > /dev/null & ./ws-parse 1 < /tmp/stream.bin > /dev/null &= ./ws-parse 1 < /tmp/stream.bin > /dev/null' > 20000002 messages forwarded > 20000002 messages forwarded > 20000002 messages forwarded > 20000002 messages forwarded > > real =A0 =A01m34.343s > user =A0 =A04m37.364s > sys =A0 =A0 0m1.459s > > That's 94 seconds total to process 80 million messages. This would imply = a rate of ~850k operations per second, well within the margins for 200k mes= sages processed a second, with plenty of CPU to spare to do the actual proc= essing. Note: I doubt my laptop could actually handle a million concurrent = connections as in the example scenario. A dual 6-core 3 GHz Xeon, for examp= le would probably be able to do this 10-20x as fast as my single dual-core = 2.66Ghz Core i7. > > My conclusion: HMAC to compute a per-frame mask would not be an obstacle = to handling a million concurrent connections on a single server. It falls w= ell within a reasonable performance target. > > Regards, > Maciej > > > > On Jan 8, 2011, at 3:16 AM, Willy Tarreau wrote: > >> Since I was not convinced at all by the supposedly very low >> overhead of using HMAC to compute a masking key, I have written >> a WebSocket framing parser which reads, parses and forwards frames. >> It supports 7, 16 and 63-bit lengths, stops after forwarding the >> last frame with opcode 0x01 and exits with an error if the input >> is broken before reaching the end of the closing frame. >> >> When called with any argument, it computes an hmac-sha1 key derived >> from a simple 32-bit constant key (for simplicity) for each frame. >> >> The payload is not even unmasked with the key, the purpose is just >> to evaluate the cost for a front server/load balancer/switch supposed >> to switch frames to a server farm. >> >> I have ran it over a stream of messages whose payload was between 1 >> and 125 bytes, with an average of 29 bytes (rnd(1..5) ^ 3), so that >> we're in line with many legitimate uses of the protocol such as online >> chat, and it happens to always fit in one byte length, making the >> stream generator even easier to write. >> >> The results : >> >> willy@pcw:~/c$ wc -c /dev/shm/ws-stream.bin >> 579976835 /dev/shm/ws-stream.bin >> >> - without masking : >> =A0willy@pcw:~/c$ time ./ws-parse < /dev/shm/ws-stream.bin >/dev/null >> =A020000001 messages forwarded >> >> =A0real =A0 =A00m1.753s >> =A0user =A0 =A00m1.544s >> =A0sys =A0 =A0 0m0.208s >> >> =A0=3D> average bit rate : 4.1 Gbps >> >> - with HMAC-based masking : >> =A0willy@pcw:~/c$ time ./ws-parse 1 < /dev/shm/ws-stream.bin >/dev/null >> =A020000001 messages forwarded >> >> =A0real =A0 =A00m42.098s >> =A0user =A0 =A00m41.759s >> =A0sys =A0 =A0 0m0.212s >> >> =A0=3D> average bit rate : 172 Mbps >> >> Masking the stream with HMAC multiplies the parsing time by 24 on small >> messages !!! We're not at all in the range of a few percent more. The >> parser with HMAC is limited to only 172 Mbps on a 3 GHz system, which >> is the speed at which the non-masking parser would run on a 125 MHz >> system. >> >> Considering those facts, I'm strongly opposed to using HMAC as well as >> any algorithm which has a similar level of complexity, which is normally >> required only for cryptographically strong usages. >> >> We're not trying to encrypt the stream, we're just ensuring that no >> broken intermediary will accidentally find a request that was put >> there on purpose by an attacker. Such a complexity is not required >> at all and is way overkill. The per-byte masking cost must remain >> very low even for small frames. >> >> I still think that a simple sliding XOR based on a cheap modification >> of the seed is far more than enough against choosen text attacks for >> this use case, such as the example code I provided yesterday, or any >> other one with the same level of complexity. >> >> The code to reproduce those tests can be freely downloaded there : >> >> =A0 =A0http://1wt.eu/websocket/ >> >> It's clearly not a model of beauty as it's only a POC. So it's not neede= d >> to comment on its ugliness or its possible improvements. >> >> Regards, >> Willy >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From ekr@rtfm.com Sat Jan 8 15:58:21 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EED28C14F for ; Sat, 8 Jan 2011 15:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFPOtN+4-1GV for ; Sat, 8 Jan 2011 15:58:20 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 75B4128C120 for ; Sat, 8 Jan 2011 15:58:20 -0800 (PST) Received: by yxt33 with SMTP id 33so8075648yxt.31 for ; Sat, 08 Jan 2011 16:00:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.83.18 with SMTP id k18mr4746477agl.79.1294531229344; Sat, 08 Jan 2011 16:00:29 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sat, 8 Jan 2011 16:00:29 -0800 (PST) In-Reply-To: <4D28DF6E.4080003@callenish.com> References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <4D28DF6E.4080003@callenish.com> Date: Sat, 8 Jan 2011 16:00:29 -0800 Message-ID: From: Eric Rescorla To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 23:58:21 -0000 On Sat, Jan 8, 2011 at 2:04 PM, Bruce Atherton wrote: > On 07/01/2011 1:19 PM, Eric Rescorla wrote: >> >> My objective is to make the bits that appear on the wire indistinguishable >> from random >> from the attacker's perspective. I think it's clear that this is the >> strongest form of masking >> available, and the method I proposed does that. > > It is true that your goal is clear, but I don't understand why you think > this goal is necessary. > > The specification already allows for two forms of Websocket, a simple one > denoted by the scheme "ws:" and a secure one denoted with "wss:". The latter > one will have the random byte stream characteristics you are interested in. > If you are uncomfortable with any other kind of stream, make sure your > client only supports secure Websockets. Regrettably, this is not the case except for certain specific ciphers (in particular block cipher in CBC mode.) It's not at all the case for RC4 and only the case for some CTR mode implementations. Best, -Ekr From metajack@gmail.com Sat Jan 8 15:59:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43DE28C14F for ; Sat, 8 Jan 2011 15:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YImtzCED89ub for ; Sat, 8 Jan 2011 15:59:22 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B2F3228C120 for ; Sat, 8 Jan 2011 15:59:21 -0800 (PST) Received: by bwz12 with SMTP id 12so18169480bwz.31 for ; Sat, 08 Jan 2011 16:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=nTwULFkeVW4cTyca+V+mjQhfdxWi1oVnMqGpjYSJ/uo=; b=DfgnvjT/fj2ILsIA6/I9mo1zUSJH7fe5jNWs2xhwIed+IpkgqpM0Zzxkj10yOB7K64 rT1LUhq/AEX+0p5kSavSSBB0D+NoiNiLQV0oXJDpg3tL2EqIuj6/7NoKLUn28jXNOkAB Ilk/R4xhgb4hqRQEvvSY4z6ugOHCiHnP7h+Ec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ri+bCuh/UNyzuuK8B2DxmxEmXm9lYs3eTLw7d69f/ipOGMdb+e7AxVmhwUvCt4c3uj XfH61FwxHrryiCZNQQ9sjD+t7SExe33EzlQDBL0xQ0MtGVuddyV1+sn+nyc4iDTTuqsI wv5LzlIN4x482kOEuOR6kGnMGR9XIrKUH8ZHQ= MIME-Version: 1.0 Received: by 10.204.59.76 with SMTP id k12mr20285645bkh.70.1294531289985; Sat, 08 Jan 2011 16:01:29 -0800 (PST) Sender: metajack@gmail.com Received: by 10.204.119.211 with HTTP; Sat, 8 Jan 2011 16:01:29 -0800 (PST) In-Reply-To: References: <20110108111632.GI2479@1wt.eu> <91303A50-B94E-45C6-8392-9AA9EFD43D94@apple.com> Date: Sat, 8 Jan 2011 17:01:29 -0700 X-Google-Sender-Auth: _kc70bHzoyEN_QRhKvu6RANN5Fo Message-ID: From: Jack Moffitt To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 23:59:22 -0000 > FWIW, I don't know how you're computing HMAC, but the naive > implementation is about > 1/2 as fast as optimized implementations. The trick is to precompute > and cache the > hash state after you have incorporated the keys. This saves a bunch of > setup overhead. He used openssl's HMAC implementation. I'm not familiar with it particularly, but it seems a reasonable approximation of what most people will do. It's good to know there may be a 2x speedup to be gained. jack. From mcmanus@ducksong.com Sat Jan 8 16:03:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7B9B28C14F for ; Sat, 8 Jan 2011 16:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE5uWq-LGj79 for ; Sat, 8 Jan 2011 16:03:37 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 0739928C120 for ; Sat, 8 Jan 2011 16:03:36 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id F380510307; Sat, 8 Jan 2011 19:05:45 -0500 (EST) 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 23321102A8; Sat, 8 Jan 2011 19:05:41 -0500 (EST) From: "Pat McManus @Mozilla" To: Willy Tarreau In-Reply-To: <20110108111632.GI2479@1wt.eu> References: <20110108111632.GI2479@1wt.eu> Content-Type: multipart/alternative; boundary="=-DBISiLqJezWDu+Ahu+Jg" Date: Sat, 08 Jan 2011 19:05:27 -0500 Message-ID: <1294531527.7650.535.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 00:03:38 -0000 --=-DBISiLqJezWDu+Ahu+Jg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Willy, this is great. Thanks. On Sat, 2011-01-08 at 12:16 +0100, Willy Tarreau wrote: > I have written > a WebSocket framing parser which reads, parses and forwards frames. [..] > The payload is not even unmasked with the key, the purpose is just > to evaluate the cost for a front server/load balancer/switch supposed > to switch frames to a server farm. > > I have ran it over a stream of messages whose payload was between 1 > and 125 bytes, with an average of 29 bytes (rnd(1..5) ^ 3), so that > we're in line with many legitimate uses of the protocol such as online > chat, and it happens to always fit in one byte length, making the > stream generator even easier to write. > > The results : [..] > Masking the stream with HMAC multiplies the parsing time by 24 on small > messages !!! Based on your experiment I was able to repeat it here on a single core of a 2.7ghz i5. (I got a multiple of about 22x). I thought a few other datapoints were in order. So I rearranged your test to be more like a server doing dispatch. I measured just frame parsing, frame parsing with a xor on the data, and frame parsing with a xor and a 20 byte hmac for each frame for frame sizes ranging on average from 27 bytes up to 32KB. The xor just uses a constant even when we calculate the hmac. It shouldn't matter for measurement. These are gigabits per second of payload data: Msgs parsed plain-xor xor-hmac -------- ------ --------- -------- 27 byte 11.7 7.1 0.15 250 byte 40.4 20.6 1.3 1 KB 50.8 25.2 5.1 4 KB 57.1 26.7 12.3 8 KB 57.1 26.7 17.0 32 KB 58.32 26.7 23.6 These are K-messages per second: Msgs parsed plain-xor xor-hmac -------- ------ --------- -------- 27 byte 54000 33000 692 250 byte 20000 10000 668 1 KB 6349 3000 597 4 KB 1785 833 394 8 KB 892 416 265 32 KB 222 102 90 Most of the tests moved about 4GB of data that was all in page cache. It looks like plain xor is expensive, but that basically is just measuring memory bandwidth of streaming all the data bytes through the processor cache which you have to figure a server is going to need to do eventually - you can see the limit on my desktop is reached around 26gbit/s. I replaced xor with an accumulator and and got the same timings. One of the things only marginally related to the question at hand that this tells me is that even at its most pathological case of 27 byte messages the xor and ws framing doesn't kill us if we can process 33million of them per second on a single core of a commodity desktop. I also ran a test that just calculated hmacs across the same 20 bytes to find the bottleneck. It was 694K on one core of this box. One way to look at the 27 byte test is that the core was doing almost exclusively HMAC instead of core WS, but the other way is to say even though hmac dominated the core it still did 692K messages per second! We can do a deep dive on the I/O and where it matters, but the hmac rate is probably the interesting limit for this discussion. (ekr suggests perhaps this could preform better - but I think it is sufficient to use this as a conservative number for now). I guess I am swayed by what Maciej has to say - even though the hmac is imo grotesquely way too expensive compared to the amount of risk it is avoiding, it really doesn't add up to anything all that important to obsess over. Claims of "a few percent" are not true, but even at its most pathological a server can process 694 thousand of them per second with a single core of a commodity desktop. Anyone interested in those kinds of volumes easily has a LOT more processor (heck I have 3 unused cores - and this is not a server class machine), and probably specialized security processors (e.g. cavium nitrox) in the case of routing switches, that can cope without breaking a sweat - and in turn can accommodate easily millions of messages per second. Even with hmac enabled, processing this purely in software on even old systems is totally reasonable for significant data flows. Giant multiplexing servers will require more oomph. I can live with that - they'll almost certainly have a lot more trouble terminating the commensurate TCP than parsing websockets. To sum it up: This is a lot like masking in general. I'm not a proponent of HMAC because I think it is an un-necessary cost. But if that's what we need to get consensus and ship this thing that is a reasonable compromise I can support because I don't think it materially damages the utility of websockets. And that is the question I find myself asking all the time lately. -Pat -- http://www.getfirefox.com/ --=-DBISiLqJezWDu+Ahu+Jg Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Willy, this is great. Thanks.

On Sat, 2011-01-08 at 12:16 +0100, Willy Tarreau wrote: 
 I have written
a WebSocket framing parser which reads, parses and forwards frames.
[..] 
The payload is not even unmasked with the key, the purpose is just
to evaluate the cost for a front server/load balancer/switch supposed
to switch frames to a server farm.

I have ran it over a stream of messages whose payload was between 1
and 125 bytes, with an average of 29 bytes (rnd(1..5) ^ 3), so that
we're in line with many legitimate uses of the protocol such as online
chat, and it happens to always fit in one byte length, making the
stream generator even easier to write.

The results :
[..] 
Masking the stream with HMAC multiplies the parsing time by 24 on small
messages !!!

Based on your experiment I was able to repeat it here on a single core of a 2.7ghz i5. (I got a multiple of about 22x).

I thought a few other datapoints were in order. So I rearranged your test to be more like a server doing dispatch. I measured just frame parsing, frame parsing with a xor on the data, and frame parsing with a xor and a 20 byte hmac for each frame for frame sizes ranging on average from 27 bytes up to 32KB.

The xor just uses a constant even when we calculate the hmac. It shouldn't matter for measurement.

These are gigabits per second of payload data: 

Msgs      parsed    plain-xor    xor-hmac
--------  ------    ---------    --------
27 byte    11.7          7.1       0.15
250 byte   40.4         20.6       1.3
1 KB       50.8         25.2       5.1
4 KB       57.1         26.7      12.3
8 KB       57.1         26.7      17.0
32 KB      58.32        26.7      23.6

These are K-messages per second:

Msgs      parsed       plain-xor    xor-hmac
--------  ------       ---------    --------
27 byte    54000       33000          692
250 byte   20000       10000          668
1 KB        6349        3000          597
4 KB        1785         833          394
8 KB         892         416          265
32 KB        222         102           90
Most of the tests moved about 4GB of data that was all in page cache. It looks like plain xor is expensive, but that basically is just measuring memory bandwidth of streaming all the data bytes through the processor cache which you have to figure a server is going to need to do eventually - you can see the limit on my desktop is reached around 26gbit/s. I replaced xor with an accumulator and and got the same timings.

One of the things only marginally related to the question at hand that  this tells me is that even at its most pathological case of 27 byte messages the xor and ws framing doesn't kill us if we can process 33million of them per second on a single core of a commodity desktop.

I also ran a test that just calculated hmacs across the same 20 bytes to find the bottleneck. It was 694K on one core of this box. One way to look at the 27 byte test is that the core was doing almost exclusively HMAC instead of core WS, but the other way is to say even though hmac dominated the core it still did 692K messages per second! We can do a deep dive on the I/O and where it matters, but the hmac rate is probably the interesting limit for this discussion. (ekr suggests perhaps this could preform better - but I think it is sufficient to use this as a conservative number for now).

I guess I am swayed by what Maciej has to say - even though the hmac is imo grotesquely way too expensive compared to the amount of risk it is avoiding, it really doesn't add up to anything all that important to obsess over. Claims of "a few percent" are not true, but even at its most pathological a server can process 694 thousand of them per second with a single core of a commodity desktop. Anyone interested in those kinds of volumes easily has a LOT more processor (heck I have 3 unused cores - and this is not a server class machine), and probably specialized security processors (e.g. cavium nitrox) in the case of routing switches,  that can cope without breaking a sweat - and in turn can accommodate easily millions of messages per second.

Even with hmac enabled, processing this purely in software on even old systems is totally reasonable for significant data flows. Giant multiplexing servers will require more oomph. I can live with that - they'll almost certainly have a lot more trouble terminating the commensurate TCP than parsing websockets.

To sum it up: This is a lot like masking in general. I'm not a proponent of HMAC because I think it is an un-necessary cost. But if that's what we need to get consensus and ship this thing that is a reasonable compromise I can support because I don't think it materially damages the utility of websockets. And that is the question I find myself asking all the time lately.

-Pat

-- 
http://www.getfirefox.com/
--=-DBISiLqJezWDu+Ahu+Jg-- From bruce@callenish.com Sat Jan 8 16:10:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A30428C0D8 for ; Sat, 8 Jan 2011 16:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pByQnjE87sS2 for ; Sat, 8 Jan 2011 16:10:56 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 7827028C120 for ; Sat, 8 Jan 2011 16:10:56 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pbiu8-00065F-Dg for hybi@ietf.org; Sat, 08 Jan 2011 16:13:04 -0800 Message-ID: <4D28FD92.60803@callenish.com> Date: Sat, 08 Jan 2011 16:13:06 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <4D28AE05.4070500@callenish.com> <4D28BD89.70704@warmcat.com> In-Reply-To: <4D28BD89.70704@warmcat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 00:10:58 -0000 On 08/01/2011 11:39 AM, Andy Green wrote: > > Actually handwaving that it is a "known vulnerability" over-eggs the > pudding. It is very much an unknown and unreproducible alleged > vulnerability in software that has not been identified publicly (or > AFAIK privately) and may be a byproduct of the interpretation of the > testing action. As others have suggested, feel free to try to convince the browser vendors of that. But please do it off-list, as it has been tried on list many times without success and it is getting tedious to wade through. When you have convinced them, come back and let us know. > Nobody seems to want to "out" these alleged broken intermediaries as > part of the protocol either. > They are already "out" through all the other ways they can be accessed on the net. I don't see why making Websockets able to exploit the defects would have any more effect. > Nor is Websockets "exposed" to this alleged vuln as you say, it is > claimed it is part of the attack vector, along with wget, curl, nc, > anything else you can open a socket connection with. This comment suggests to me that you are still not understanding the reason that masking has been suggested. No one has ever claimed it could stop an attacker putting malicious bits into a Websocket connection. It is intended to stop them from doing it from within a browser. Browser vendors do not ship wget, curl, or anything that opens a raw socket. From w@1wt.eu Sat Jan 8 23:45:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496193A6948 for ; Sat, 8 Jan 2011 23:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jDsCr7LUufU for ; Sat, 8 Jan 2011 23:45:05 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 499FB3A6956 for ; Sat, 8 Jan 2011 23:45:03 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p097l96I008032; Sun, 9 Jan 2011 08:47:09 +0100 Date: Sun, 9 Jan 2011 08:47:09 +0100 From: Willy Tarreau To: "Pat McManus @Mozilla" Message-ID: <20110109074709.GK5743@1wt.eu> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1294531527.7650.535.camel@ds9.ducksong.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 07:45:08 -0000 Hi Pat, On Sat, Jan 08, 2011 at 07:05:27PM -0500, Pat McManus @Mozilla wrote: > Based on your experiment I was able to repeat it here on a single core > of a 2.7ghz i5. (I got a multiple of about 22x). Nice to see that results are easily reproduceable :-) > I thought a few other datapoints were in order. So I rearranged your > test to be more like a server doing dispatch. I measured just frame > parsing, frame parsing with a xor on the data, and frame parsing with a > xor and a 20 byte hmac for each frame for frame sizes ranging on average > from 27 bytes up to 32KB. Cool. I started to do that and stopped at one point because it was taking too much time to me for little added value. Do not hesitate to post your updates, as apparently the prog can serve as a basis for experiments. Maybe if we complete it we could even post the parser as an example implementation in an annex of the spec (it needs some improvements though). > The xor just uses a constant even when we calculate the hmac. It > shouldn't matter for measurement. That's not a problem for me either. As you've seen, I made similar choices for the experiment. > These are gigabits per second of payload data: > > > Msgs parsed plain-xor xor-hmac > -------- ------ --------- -------- > 27 byte 11.7 7.1 0.15 > 250 byte 40.4 20.6 1.3 > 1 KB 50.8 25.2 5.1 > 4 KB 57.1 26.7 12.3 > 8 KB 57.1 26.7 17.0 > 32 KB 58.32 26.7 23.6 > > These are K-messages per second: > > Msgs parsed plain-xor xor-hmac > -------- ------ --------- -------- > 27 byte 54000 33000 692 > 250 byte 20000 10000 668 > 1 KB 6349 3000 597 > 4 KB 1785 833 394 > 8 KB 892 416 265 > 32 KB 222 102 90 > Most of the tests moved about 4GB of data that was all in page cache. It > looks like plain xor is expensive, but that basically is just measuring > memory bandwidth of streaming all the data bytes through the processor > cache which you have to figure a server is going to need to do > eventually - you can see the limit on my desktop is reached around > 26gbit/s. I replaced xor with an accumulator and and got the same > timings. I'm not surprised you hit memory bandwidth limits. In find, I was impressed to see how efficient the framing is for a parser, as it's very easy to handle. I suspect we can optimize the xor if we want so that it works on 32- or 64- bit quantities at a time on aligned boundaries, but that's not the point for now. > One of the things only marginally related to the question at hand that > this tells me is that even at its most pathological case of 27 byte > messages the xor and ws framing doesn't kill us if we can process > 33million of them per second on a single core of a commodity desktop. Agreed. We must just keep in mind that we don't update the xor mask right now, but if properly done it should not cause significantly more memory accesses. > I also ran a test that just calculated hmacs across the same 20 bytes to > find the bottleneck. It was 694K on one core of this box. One way to > look at the 27 byte test is that the core was doing almost exclusively > HMAC instead of core WS, but the other way is to say even though hmac > dominated the core it still did 692K messages per second! We can do a > deep dive on the I/O and where it matters, but the hmac rate is probably > the interesting limit for this discussion. (ekr suggests perhaps this > could preform better - but I think it is sufficient to use this as a > conservative number for now). I've seen his suggestion too, but I don't know how to do what he suggests. It was already not easy to find some example code for using HMAC, as the openssl man is not particularly helpful on the subject. > I guess I am swayed by what Maciej has to say - even though the hmac is > imo grotesquely way too expensive compared to the amount of risk it is > avoiding, it really doesn't add up to anything all that important to > obsess over. That's the point where I disagree. Granted for a browser with one message once in a while, nobody will even notice the difference. But on some intermediaries, we'll have to oversize their CPUs just for being able to process a given amount of messages. > Claims of "a few percent" are not true, but even at its > most pathological a server can process 694 thousand of them per second > with a single core of a commodity desktop. Anyone interested in those > kinds of volumes easily has a LOT more processor No, I disagree with this point too. It really depends on target usage. Imagine that a product such as memcache is updated to support WebSocket as an exchange protocol. There would be nothing wrong with that. The message rate could be much higher on the centralized server. Also, more and more services are migrating to virtualized environments. People do pay for small systems, they order them in 500 MHz steps. Here we're saying that someone who implements that in such an environment will have to afford a bigger VM just to be able to process HMAC between two VMs running on the same hypervisor ! > (heck I have 3 unused > cores - and this is not a server class machine), and probably > specialized security processors (e.g. cavium nitrox) in the case of > routing switches, that can cope without breaking a sweat - and in turn > can accommodate easily millions of messages per second. Not necessarily. From my experience, security processors excel on streaming but are not better than commodity processors running at amazing frequencies when it comes to key setups or such things (and often their libraries still make use of the main processor power for those complex tasks). Also, keep in mind that contrary to a common belief, border infrastructure equipments are generally equipped with smaller processors than what you can find in your average server or desktop. They often have dedicted ASICs for switching and/or packet forwarding, state matching, but the upper layers are handled by much smaller processors running finely tuned software. For instance, I remember that the Alteon web switches were using two ASICs per port for wire-speed packet forwarding and session processing, but when it came to content inspection or layer 7 processing, the management CPU was involved (a 150 MHz PPC) for that task. If you check what's inside a big F5 LB such as an 8800, you'll be surprized to discover a smaller CPU than in the servers it distributes traffic to. > Even with hmac enabled, processing this purely in software on even old > systems is totally reasonable for significant data flows. Giant > multiplexing servers will require more oomph. I can live with that - > they'll almost certainly have a lot more trouble terminating the > commensurate TCP than parsing websockets. Precisely not. Efficient software and hardware already exists to process TCP. HMAC processing can be improved but will always find a limit. Hashing algorithms are designed to ensure that there is a non-null setup cost in order to limit the ability to brute-force them. So even if we manage to gain a nice 2x gain there, we'll still spend 90% of the CPU time in HMAC computations. > To sum it up: This is a lot like masking in general. I'm not a proponent > of HMAC because I think it is an un-necessary cost. But if that's what > we need to get consensus and ship this thing that is a reasonable > compromise I can support because I don't think it materially damages the > utility of websockets. And that is the question I find myself asking all > the time lately. I think that it sensibly limits the use cases and that's what I don't agree with. Considering what improvement it brings over simple XOR masking, and the huge additional cost, I'd really vote for the simpler mask method. Thanks, Willy From gregw@intalio.com Sun Jan 9 01:41:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254803A6950 for ; Sun, 9 Jan 2011 01:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF+ffEoNUzBw for ; Sun, 9 Jan 2011 01:41:09 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D2C613A694F for ; Sun, 9 Jan 2011 01:41:08 -0800 (PST) Received: by vws7 with SMTP id 7so7575846vws.31 for ; Sun, 09 Jan 2011 01:43:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.187.132 with SMTP id cw4mr5636333vcb.25.1294566198593; Sun, 09 Jan 2011 01:43:18 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 01:43:18 -0800 (PST) In-Reply-To: <1294531527.7650.535.camel@ds9.ducksong.com> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> Date: Sun, 9 Jan 2011 10:43:18 +0100 X-Google-Sender-Auth: B6H7-YtS2xc59lrSmfVRBeivde8 Message-ID: From: Greg Wilkins To: "Pat McManus @Mozilla" Content-Type: multipart/alternative; boundary=90e6ba4fbd9c67cb0d049966ae33 Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 09:41:10 -0000 --90e6ba4fbd9c67cb0d049966ae33 Content-Type: text/plain; charset=ISO-8859-1 On 9 January 2011 01:05, Pat McManus @Mozilla wrote: > I guess I am swayed by what Maciej has to say - even though the hmac is imo > grotesquely way too expensive compared to the amount of risk it is avoiding, > it really doesn't add up to anything all that important to obsess over. > Claims of "a few percent" are not true, but even at its most pathological a > server can process 694 thousand of them per second with a single core of a > commodity desktop. Anyone interested in those kinds of volumes easily has a > LOT more processor (heck I have 3 unused cores - and this is not a server > class machine), and probably specialized security processors (e.g. cavium > nitrox) in the case of routing switches, that can cope without breaking a > sweat - and in turn can accommodate easily millions of messages per second. > The HMAC message rate may be sufficient for a intermediary that does nothing but forward messages. But the CPU cost is significant and on server boxes that will be running WS and running the application, then message rate is not the only thing as servers have other things they need to use the CPU's for. So if WS with no masking at my required message rate takes 5% of my CPU, but I can probably live with XOR masking taking 10%, but HMAC masking taking 25-50% of my CPU is going to be prohibitive! Not all of the high volume servers I've worked with have been CPU bound, but certainly some of them have been. regards --90e6ba4fbd9c67cb0d049966ae33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 9 January 2011 01:05, Pat McManus @Mo= zilla <mcmanus= @ducksong.com> wrote:
I guess I am swayed by what Maciej has to say - even though the hmac is imo= grotesquely way too expensive compared to the amount of risk it is avoidin= g, it really doesn't add up to anything all that important to obsess ov= er. Claims of "a few percent" are not true, but even at its most = pathological a server can process 694 thousand of them per second with a si= ngle core of a commodity desktop. Anyone interested in those kinds of volum= es easily has a LOT more processor (heck I have 3 unused cores - and this i= s not a server class machine), and probably specialized security processors= (e.g. cavium nitrox) in the case of routing switches,=A0 that can cope wit= hout breaking a sweat - and in turn can accommodate easily millions of mess= ages per second.

The HMAC message rate may be sufficient for a i= ntermediary that does nothing but forward messages.

But the CPU cost= is significant and on server boxes that will be running WS and running the= application, then message rate is not the only thing as servers have other= things they need to use the CPU's for.
So if WS with no masking at my required message rate takes 5% of my CPU, bu= t I can probably live with XOR masking taking 10%, but HMAC masking taking = 25-50% of my CPU is going to be prohibitive!

Not all of the high vol= ume servers I've worked with have been CPU bound, but certainly some of= them have been.

regards

--90e6ba4fbd9c67cb0d049966ae33-- From andy.warmcat.com@googlemail.com Sun Jan 9 03:49:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54623A697F for ; Sun, 9 Jan 2011 03:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MYYeFxgRlvB for ; Sun, 9 Jan 2011 03:49:27 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 600343A696E for ; Sun, 9 Jan 2011 03:49:26 -0800 (PST) Received: by wyf23 with SMTP id 23so19651239wyf.31 for ; Sun, 09 Jan 2011 03:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=P0h6hxdrWpW6v8iMmNEnpQmK27ZOiEOrrzi1a3F3rX4=; b=oEfv3eVhk8a5TQ8+ZufQ5MLCM+npJwn5gc818zTTBiyYoQDen63kohsmUDxc6VtDkn Ao5Pl/rFlp3eErDEgt8cfvRfv/3cmfNBFF1ESOqCF4OkpNCQ4rKk+hZEcCnvCfKgeoxm BhiZanylA7TfByjxBJEFu3NWB3L+qlKVYeVgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=T+aCGhOlJ4pGyjAjwBcd2Nms+YY84MRZ9ZGZ7pOMGzeXN7+B6RkD6UmySiVpHIySxw HGpL6BBSvoHn75DTdu+O777Ou0bqmhHBqWZ8t1LKQOkHMFZN82QRvJh/2BAm+KamG0T2 zuzW7rJz+CHepk0fhyISKnmur1lh48N9il38k= Received: by 10.227.132.208 with SMTP id c16mr1586137wbt.72.1294573896174; Sun, 09 Jan 2011 03:51:36 -0800 (PST) Received: from [192.168.1.72] (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id 11sm19189516wbi.6.2011.01.09.03.51.34 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 03:51:34 -0800 (PST) Sender: Andy Green Message-ID: <4D29A145.1080003@warmcat.com> Date: Sun, 09 Jan 2011 11:51:33 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruce Atherton References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <4D28AE05.4070500@callenish.com> <4D28BD89.70704@warmcat.com> <4D28FD92.60803@callenish.com> In-Reply-To: <4D28FD92.60803@callenish.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 11:49:28 -0000 On 01/09/11 00:13, Somebody in the thread at some point said: > On 08/01/2011 11:39 AM, Andy Green wrote: >>> This is a known vulnerability. No major browser vendor is going >>> to ship a Websockets implementation that is exposed to it. >>> They have all said so on this list. Let's move on. >> Actually handwaving that it is a "known vulnerability" over-eggs the >> pudding. It is very much an unknown and unreproducible alleged >> vulnerability in software that has not been identified publicly (or >> AFAIK privately) and may be a byproduct of the interpretation of the >> testing action. > As others have suggested, feel free to try to convince the browser > vendors of that. But please do it off-list, as it has been tried on list Bruce, you are the guy who handwaved about "known vulnerability" on the list so it is you I replied to on the list. I agree it is tiresome to keep posting reality-based corrections when the centre of gravity of the group doesn't care and is off agreeing something completely different. >> Nor is Websockets "exposed" to this alleged vuln as you say, it is >> claimed it is part of the attack vector, along with wget, curl, nc, >> anything else you can open a socket connection with. > > This comment suggests to me that you are still not understanding the > reason that masking has been suggested. No one has ever claimed it could > stop an attacker putting malicious bits into a Websocket connection. It > is intended to stop them from doing it from within a browser. Browser > vendors do not ship wget, curl, or anything that opens a raw socket. What you wrote is incorrect, websockets is not exposed to any vulnerability (I added your quote back in at the top). The reason I don't bother engaging with what you think is the reason for munging, is that the error in logic leading to people thinking that munging does anything useful occurred a step or two back: when they accepted that fighting troll / ghost / alleged broken intermediaries was the problem of websocket protocol to fix, when they can't even point at one and the intermediaries remain exposed until they get updated themselves. Even that they might ever exist is the problem that must be solved now by munging. The browser guys now need some figleaf to explain why they revert their security taint on websockets and munging fits the bill perfectly, so they will just sit until munging comes. Sure! -Andy From julian.reschke@gmx.de Sun Jan 9 04:04:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A2A3A6983 for ; Sun, 9 Jan 2011 04:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.457 X-Spam-Level: X-Spam-Status: No, score=-104.457 tagged_above=-999 required=5 tests=[AWL=-1.858, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DPqsc9TZQlb for ; Sun, 9 Jan 2011 04:04:03 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 9A8C93A6980 for ; Sun, 9 Jan 2011 04:04:01 -0800 (PST) Received: (qmail invoked by alias); 09 Jan 2011 12:06:11 -0000 Received: from p508FAAD2.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.170.210] by mail.gmx.net (mp049) with SMTP; 09 Jan 2011 13:06:11 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/QKbkFbg7QtQOPmi/L2dzgcq5c/SgPZnVorbZS0M oaiwPXAvMKBU/J Message-ID: <4D29A4B1.4020603@gmx.de> Date: Sun, 09 Jan 2011 13:06:09 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: andy@warmcat.com References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <4D28AE05.4070500@callenish.com> <4D28BD89.70704@warmcat.com> <4D28FD92.60803@callenish.com> <4D29A145.1080003@warmcat.com> In-Reply-To: <4D29A145.1080003@warmcat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 12:04:03 -0000 On 09.01.2011 12:51, Andy Green wrote: > ... > The browser guys now need some figleaf to explain why they revert their > security taint on websockets and munging fits the bill perfectly, so > they will just sit until munging comes. Sure! > ... One thing I'd like to understand is why Apple and Chrome haven't stopped shipping browsers with the -00 protocol enabled by default. One could think the problem isn't nearly as serious it seems. Best regards, Julian From mjs@apple.com Sun Jan 9 04:45:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9323A6990 for ; Sun, 9 Jan 2011 04:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PztlrfzlmGWI for ; Sun, 9 Jan 2011 04:45:52 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id A5EA83A698E for ; Sun, 9 Jan 2011 04:45:52 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 1A1B3C5D52AC for ; Sun, 9 Jan 2011 04:48:03 -0800 (PST) X-AuditID: 11807136-b7bf8ae00000244a-a7-4d29ae82c786 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id 63.33.09290.28EA92D4; Sun, 9 Jan 2011 04:48:03 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.14] ([24.6.209.6]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LER00G4DA82RH10@gertie.apple.com> for hybi@ietf.org; Sun, 09 Jan 2011 04:48:02 -0800 (PST) From: Maciej Stachowiak In-reply-to: <4D29A4B1.4020603@gmx.de> Date: Sun, 09 Jan 2011 04:48:01 -0800 Message-id: References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <4D28AE05.4070500@callenish.com> <4D28BD89.70704@warmcat.com> <4D28FD92.60803@callenish.com> <4D29A145.1080003@warmcat.com> <4D29A4B1.4020603@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 12:45:53 -0000 On Jan 9, 2011, at 4:06 AM, Julian Reschke wrote: > On 09.01.2011 12:51, Andy Green wrote: >> ... >> The browser guys now need some figleaf to explain why they revert their >> security taint on websockets and munging fits the bill perfectly, so >> they will just sit until munging comes. Sure! >> ... > > One thing I'd like to understand is why Apple and Chrome haven't stopped shipping browsers with the -00 protocol enabled by default. One could think the problem isn't nearly as serious it seems. Our thinking so far is that the problem is severe enough that it should be addressed in the protocol design, since the protocol is not yet final, but not (at this time) severe enough to merit an emergency security update. The bar for security in a brand new protocol should be much higher than just "shouldn't be so bad that vendors will spin security updates just to disable it". Regards, Maciej From gregw@intalio.com Sun Jan 9 04:49:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F68A3A6990 for ; Sun, 9 Jan 2011 04:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wb+qhdgVU8H for ; Sun, 9 Jan 2011 04:49:21 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 27FF33A698E for ; Sun, 9 Jan 2011 04:49:21 -0800 (PST) Received: by vws7 with SMTP id 7so7619193vws.31 for ; Sun, 09 Jan 2011 04:51:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.187.132 with SMTP id cw4mr5686640vcb.25.1294577491304; Sun, 09 Jan 2011 04:51:31 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 04:51:31 -0800 (PST) In-Reply-To: <4D29A145.1080003@warmcat.com> References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <4D28AE05.4070500@callenish.com> <4D28BD89.70704@warmcat.com> <4D28FD92.60803@callenish.com> <4D29A145.1080003@warmcat.com> Date: Sun, 9 Jan 2011 13:51:31 +0100 X-Google-Sender-Auth: mlwoIeAuUU-R18nDeqyN0La4sv8 Message-ID: From: Greg Wilkins To: andy@warmcat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 12:49:22 -0000 On 9 January 2011 12:51, Andy Green wrote: > The browser guys now need some figleaf to explain why they revert their > security taint on websockets and munging fits the bill perfectly, so they > will just sit until munging comes. =A0Sure! Andy, I think that is a slightly unfair characterisation of why a consensus has formed around masking. I'm as dubious as any that WS enables any exploits against any real deployed browsers with the cache poisoning vulnerability. The reason I believe that masking is looked at favourably is that it is not targeted at a specific known exploit (as CONNECT handshake is), but is instead targeted at a class of conceivable vulnerabilities that result from sending arbitrary content in non-HTTP framing through HTTP intermediaries. We really need to try to take some of the heat out of this discussion, so that progress made is not lost. regards From mjs@apple.com Sun Jan 9 06:10:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B753A69B5 for ; Sun, 9 Jan 2011 06:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.086 X-Spam-Level: X-Spam-Status: No, score=-106.086 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2hmmhym741G for ; Sun, 9 Jan 2011 06:10:54 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id A6B473A69B2 for ; Sun, 9 Jan 2011 06:10:54 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 897BFC5D74CB for ; Sun, 9 Jan 2011 06:13:05 -0800 (PST) X-AuditID: 11807130-b7cb4ae000001037-80-4d29c2711950 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id 4C.B2.04151.172C92D4; Sun, 9 Jan 2011 06:13:05 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YweqZOt3Zh+jG1imsVJowg)" Received: from [10.0.1.14] ([24.6.209.6]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LER00F96E5S5800@elliott.apple.com> for hybi@ietf.org; Sun, 09 Jan 2011 06:13:05 -0800 (PST) From: Maciej Stachowiak In-reply-to: <1294531527.7650.535.camel@ds9.ducksong.com> Date: Sun, 09 Jan 2011 06:13:03 -0800 Message-id: <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> To: "Pat McManus @Mozilla" X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 14:10:58 -0000 --Boundary_(ID_YweqZOt3Zh+jG1imsVJowg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Pat, including XOR seems like a great idea. I coded up my own XORing version, and I decided to also test HMAC with cached state as suggested by Eric, and AES-CTR instead of XOR. Here is a summary of my results on two-way parallel runs: Plain XOR: ~5.1 million msg/sec HMAC+XOR: ~370 thousand msg/sec cached state HMAC+XOR: 1.2 million msg/sec AES-CTR: 2.6 million msg/sec == Conclusions == - HMAC is much faster if you do the state caching thing. - AES-CTR is even faster than that. - We should use AES-CTR for masking. Here is my code (based on Willy's version): Here is the raw data: == Plain XOR == time (./ws-parse < /tmp/stream.bin > /dev/null & ./ws-parse < /tmp/stream.bin > /dev/null) Mode: 0 Mode: 0 20000002 messages forwarded 20000002 messages forwarded real 0m3.922s user 0m7.314s sys 0m0.519s == HMAC+XOR == $ time (./ws-parse 1 < /tmp/stream.bin > /dev/null & ./ws-parse 1 < /tmp/stream.bin > /dev/null) Mode: 1 Mode: 1 20000002 messages forwarded 20000002 messages forwarded real 0m53.586s user 0m53.222s sys 0m0.347s == cached state HMAC+XOR == $ time (./ws-parse 2 < /tmp/stream.bin > /dev/null & ./ws-parse 2 < /tmp/stream.bin > /dev/null) Mode: 2 Mode: 2 20000002 messages forwarded 20000002 messages forwarded real 0m16.399s user 0m32.098s sys 0m0.631s == AES-CTR == $ time (./ws-parse 3 < /tmp/stream.bin > /dev/null & ./ws-parse 3 < /tmp/stream.bin > /dev/null) Mode: 3 Mode: 3 20000002 messages forwarded 20000002 messages forwarded real 0m7.695s user 0m7.396s sys 0m0.290s On Jan 8, 2011, at 4:05 PM, Pat McManus @Mozilla wrote: > Willy, this is great. Thanks. > > On Sat, 2011-01-08 at 12:16 +0100, Willy Tarreau wrote: >> >> I have written >> a WebSocket framing parser which reads, parses and forwards frames. > [..] >> >> The payload is not even unmasked with the key, the purpose is just >> to evaluate the cost for a front server/load balancer/switch supposed >> to switch frames to a server farm. >> >> I have ran it over a stream of messages whose payload was between 1 >> and 125 bytes, with an average of 29 bytes (rnd(1..5) ^ 3), so that >> we're in line with many legitimate uses of the protocol such as online >> chat, and it happens to always fit in one byte length, making the >> stream generator even easier to write. >> >> The results : > [..] >> >> Masking the stream with HMAC multiplies the parsing time by 24 on small >> messages !!! > > Based on your experiment I was able to repeat it here on a single core of a 2.7ghz i5. (I got a multiple of about 22x). > > I thought a few other datapoints were in order. So I rearranged your test to be more like a server doing dispatch. I measured just frame parsing, frame parsing with a xor on the data, and frame parsing with a xor and a 20 byte hmac for each frame for frame sizes ranging on average from 27 bytes up to 32KB. > > The xor just uses a constant even when we calculate the hmac. It shouldn't matter for measurement. > > These are gigabits per second of payload data: > > Msgs parsed plain-xor xor-hmac > -------- ------ --------- -------- > 27 byte 11.7 7.1 0.15 > 250 byte 40.4 20.6 1.3 > 1 KB 50.8 25.2 5.1 > 4 KB 57.1 26.7 12.3 > 8 KB 57.1 26.7 17.0 > 32 KB 58.32 26.7 23.6 > > These are K-messages per second: > > Msgs parsed plain-xor xor-hmac > -------- ------ --------- -------- > 27 byte 54000 33000 692 > 250 byte 20000 10000 668 > 1 KB 6349 3000 597 > 4 KB 1785 833 394 > 8 KB 892 416 265 > 32 KB 222 102 90 > > Most of the tests moved about 4GB of data that was all in page cache. It looks like plain xor is expensive, but that basically is just measuring memory bandwidth of streaming all the data bytes through the processor cache which you have to figure a server is going to need to do eventually - you can see the limit on my desktop is reached around 26gbit/s. I replaced xor with an accumulator and and got the same timings. > > One of the things only marginally related to the question at hand that this tells me is that even at its most pathological case of 27 byte messages the xor and ws framing doesn't kill us if we can process 33million of them per second on a single core of a commodity desktop. > > I also ran a test that just calculated hmacs across the same 20 bytes to find the bottleneck. It was 694K on one core of this box. One way to look at the 27 byte test is that the core was doing almost exclusively HMAC instead of core WS, but the other way is to say even though hmac dominated the core it still did 692K messages per second! We can do a deep dive on the I/O and where it matters, but the hmac rate is probably the interesting limit for this discussion. (ekr suggests perhaps this could preform better - but I think it is sufficient to use this as a conservative number for now). > > I guess I am swayed by what Maciej has to say - even though the hmac is imo grotesquely way too expensive compared to the amount of risk it is avoiding, it really doesn't add up to anything all that important to obsess over. Claims of "a few percent" are not true, but even at its most pathological a server can process 694 thousand of them per second with a single core of a commodity desktop. Anyone interested in those kinds of volumes easily has a LOT more processor (heck I have 3 unused cores - and this is not a server class machine), and probably specialized security processors (e.g. cavium nitrox) in the case of routing switches, that can cope without breaking a sweat - and in turn can accommodate easily millions of messages per second. > > Even with hmac enabled, processing this purely in software on even old systems is totally reasonable for significant data flows. Giant multiplexing servers will require more oomph. I can live with that - they'll almost certainly have a lot more trouble terminating the commensurate TCP than parsing websockets. > > To sum it up: This is a lot like masking in general. I'm not a proponent of HMAC because I think it is an un-necessary cost. But if that's what we need to get consensus and ship this thing that is a reasonable compromise I can support because I don't think it materially damages the utility of websockets. And that is the question I find myself asking all the time lately. > > -Pat > > -- > http://www.getfirefox.com/ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --Boundary_(ID_YweqZOt3Zh+jG1imsVJowg) Content-type: multipart/mixed; boundary="Boundary_(ID_wzrGxTIoH/HWAsOBkWnp4A)" --Boundary_(ID_wzrGxTIoH/HWAsOBkWnp4A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Pat, including XOR seems like a great idea. I coded up my own XORing version, and I decided to also test HMAC with cached state as suggested by Eric, and AES-CTR instead of XOR. 

Here is a summary of my results on two-way parallel runs:

Plain XOR: ~5.1 million msg/sec
HMAC+XOR: ~370 thousand msg/sec
cached state HMAC+XOR: 1.2 million msg/sec
AES-CTR: 2.6 million msg/sec

== Conclusions ==

- HMAC is much faster if you do the state caching thing.
- AES-CTR is even faster than that.
- We should use AES-CTR for masking.


Here is my code (based on Willy's version):

--Boundary_(ID_wzrGxTIoH/HWAsOBkWnp4A) Content-type: application/octet-stream; name=ws-parse-extended.c Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ws-parse-extended.c /* Simple stupid WebSocket framing parser - Willy Tarreau - 2011. * Designed as a proof of concept. I claim no copyright on the code below, * you may use it at your own risk. * * gcc -O2 -s ws-parse.c -o ws-parse -lssl */ #include #include #include #include #include #define MAXBUF 32768 struct buf { int len; unsigned char *start; unsigned char *end; unsigned char data[MAXBUF]; }; struct buf buf; unsigned char crypt_buf[MAXBUF]; HMAC_CTX cached_ctx; static mode = 0; /* reads bytes into buffer, returns 0 if none read, -1 on end/abort, or bytes read */ int recv_buf(struct buf *buf) { int ret; if (buf->len >= MAXBUF / 2) return 0; if (buf->len == 0) buf->start = buf->end = buf->data; ret = read(0, buf->end, buf->end >= buf->start ? buf->data + MAXBUF - buf->end : buf->start - buf->end); if (ret <= 0) return -1; buf->len += ret; buf->end += ret; if (buf->end >= buf->data + MAXBUF) buf->end = buf->data; return ret; } /* sends bytes from buffer, returns number of bytes sent, -1 on abort */ int send_buf(struct buf *buf, int max) { int ret; int sent; sent = 0; while (max && buf->len) { if (buf->end > buf->start) { if (max > buf->end - buf->start) max = buf->end - buf->start; } else { if (max > buf->data + MAXBUF - buf->start) max = buf->data + MAXBUF - buf->start; } ret = fwrite(buf->start, 1, max, stdout); if (ret < 0) return -1; sent += ret; max -= ret; buf->len -= ret; buf->start += ret; if (buf->start >= buf->data + MAXBUF) buf->start = buf->data; } if (!buf->len) buf->start = buf->end = buf->data; return sent; } void realign_buf(struct buf *buf) { unsigned char tmpbuf[MAXBUF]; int block1, block2; unsigned char *end; if (!buf->len) { buf->start = buf->end = buf->data; return; } if (buf->end > buf->start) block1 = buf->end - buf->start; else block1 = buf->data + MAXBUF - buf->start; if (block1 != buf->len) memcpy(tmpbuf, buf->data, buf->len - block1); memmove(buf->data, buf->start, block1); if (block1 != buf->len) memcpy(buf->data + block1, tmpbuf, buf->len - block1); buf->start = buf->data; buf->end = buf->start + buf->len; if (buf->end >= buf->data + MAXBUF) buf->end = buf->data; } /* parse a frame's length, returns header length, 0 if more data is needed */ int parse_frame_length(struct buf *buf, int *opcode, unsigned long long *length) { unsigned long long len; int hl; if (buf->len < 2) return 0; if (buf->start >= buf->data + MAXBUF - 10) realign_buf(buf); *opcode = buf->start[0] & 0xF; len = buf->start[1] & 0x7F; hl = 2; if (len == 126) { hl += 2; if (buf->len < hl) return 0; len = (buf->start[2] << 8) + buf->start[3]; } else if (len == 127) { hl += 8; if (buf->len < hl) return 0; len = (buf->start[2] << 24) + (buf->start[3] << 16) + (buf->start[4] << 8) + buf->start[5]; len <<= 32; len += (buf->start[6] << 24) + (buf->start[7] << 16) + (buf->start[8] << 8) + buf->start[9]; } *length = len; return hl; } void init_masking_key(struct buf *buf, int hl) { HMAC_CTX ctx; unsigned int seed; unsigned int entropy = 0; unsigned char mask_key[20]; int mask_key_len; seed = 0; // use that as the random seed for now HMAC_Init(&ctx, (unsigned char *)&seed, sizeof(seed), EVP_sha1( )); HMAC_Update(&ctx, (unsigned char *)&entropy, sizeof(entropy)); HMAC_Final(&ctx, mask_key, &mask_key_len); HMAC_cleanup(&ctx); } void init_masking_key_with_cached_state(struct buf *buf, int hl) { HMAC_CTX ctx = cached_ctx; unsigned int entropy = 0; unsigned char mask_key[20]; int mask_key_len; HMAC_Update(&ctx, (unsigned char *)&entropy, sizeof(entropy)); HMAC_Final(&ctx, mask_key, &mask_key_len); } /* call it with any argument to enable payload masking */ int main(int argc, char **argv) { int ret; int opcode = 0; int last = 0; int stop_recv = 0; int nb_msg = 0; unsigned long long send_so_far; unsigned long long to_send = 0; AES_KEY key; unsigned char iv[AES_BLOCK_SIZE]; unsigned char ecount_buf[AES_BLOCK_SIZE]; unsigned int num; unsigned int seed = 0; unsigned char mask[4] = { 0, 0, 0, 0 }; if (argc > 1) mode = strtol(argv[1], 0, 10); fprintf(stderr, "Mode: %d\n", mode); if (mode == 2) { HMAC_Init(&cached_ctx, (unsigned char *)&seed, sizeof(seed), EVP_sha1( )); } if (mode == 3) { memset(iv, 0, sizeof(iv)); memset(ecount_buf, 0, sizeof(ecount_buf)); AES_set_decrypt_key("abcdefghijklmnop", 128, &key); } memset(&buf, 0, sizeof(buf)); while (!last || to_send) { if (!stop_recv) { ret = recv_buf(&buf); if (ret < 0) stop_recv = 1; // end reached } else if (!buf.len) { fprintf(stderr, "truncated input after %d messages\n", nb_msg); exit(1); } /* parse a new frame length */ if (!to_send && buf.len) { ret = parse_frame_length(&buf, &opcode, &to_send); if (ret > 0) { nb_msg++; if (mode == 1) init_masking_key(&buf, ret); else if (mode == 2) init_masking_key_with_cached_state(&buf, ret); to_send += ret; if (opcode == 0x01) last = 1; } } puts("HERE"); if (mode == 3) { /* AES_ctr128_encrypt is its own inverse so can be used to decrypt. */ AES_ctr128_encrypt(buf.start, crypt_buf, to_send > MAXBUF ? MAXBUF : to_send, &key, iv, ecount_buf, &num); memcpy(buf.start, crypt_buf, to_send > MAXBUF ? MAXBUF : to_send); } else { int i; for (i = 0; i < to_send; ++i) { buf.start[i] ^= mask[i %4]; } } /* send what we have */ if (to_send) { ret = send_buf(&buf, to_send > MAXBUF ? MAXBUF : to_send); if (ret < 0) { fprintf(stderr, "write error after %d messages\n", nb_msg); exit(2); } to_send -= ret; } } fprintf(stderr, "%d messages forwarded\n", nb_msg); return 0; } --Boundary_(ID_wzrGxTIoH/HWAsOBkWnp4A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable 0m3.922s
user = 0m7.314s
sys = 0m0.519s

=3D=3D HMAC+XOR = =3D=3D

$ time (./ws-parse 1 < = /tmp/stream.bin > /dev/null & ./ws-parse 1 < /tmp/stream.bin = > /dev/null)
Mode: 1
Mode: 1
20000002 = messages forwarded
20000002 messages = forwarded

real = 0m53.586s
user 0m53.222s
sys = 0m0.347s

=3D=3D cached = state HMAC+XOR =3D=3D

$ time = (./ws-parse 2 < /tmp/stream.bin > /dev/null & ./ws-parse 2 = < /tmp/stream.bin > /dev/null)
Mode: 2
Mode: = 2
20000002 messages forwarded
20000002 messages = forwarded

real 0m16.399s
user = 0m32.098s
sys = 0m0.631s

=3D=3D AES-CTR = =3D=3D

$ time (./ws-parse 3 < = /tmp/stream.bin > /dev/null & ./ws-parse 3 < /tmp/stream.bin = > /dev/null)
Mode: 3
Mode: 3
20000002 = messages forwarded
20000002 messages = forwarded

real = 0m7.695s
user 0m7.396s
sys = 0m0.290s



On Jan 8, 2011, at 4:05 PM, Pat McManus @Mozilla = wrote:

Willy, this is great. Thanks.

On Sat, 2011-01-08 at 12:16 +0100, Willy Tarreau wrote: 
 I have written
a WebSocket framing parser which reads, parses and forwards frames.
[..] 
The payload is not even unmasked with the key, the purpose is just
to evaluate the cost for a front server/load balancer/switch supposed
to switch frames to a server farm.

I have ran it over a stream of messages whose payload was between 1
and 125 bytes, with an average of 29 bytes (rnd(1..5) ^ 3), so that
we're in line with many legitimate uses of the protocol such as online
chat, and it happens to always fit in one byte length, making the
stream generator even easier to write.

The results :
[..] 
Masking the stream with HMAC multiplies the parsing time by 24 on =
small
messages !!!=20

Based on your experiment I was able to repeat it here on a single core = of a 2.7ghz i5. (I got a multiple of about 22x).

I thought a few other datapoints were in order. So I rearranged your = test to be more like a server doing dispatch. I measured just frame = parsing, frame parsing with a xor on the data, and frame parsing with a = xor and a 20 byte hmac for each frame for frame sizes ranging on average = from 27 bytes up to 32KB.

The xor just uses a constant even when we calculate the hmac. It = shouldn't matter for measurement.

These are gigabits per second of payload data: 
Msgs      parsed    =
plain-xor    xor-hmac
--------  ------    ---------    =
--------
27 byte    =
11.7          =
7.1       0.15
250 byte   =
40.4         =
20.6       1.3
1 KB       =
50.8         =
25.2       5.1
4 KB       =
57.1         =
26.7      12.3
8 KB       =
57.1         =
26.7      17.0
32 KB      =
58.32        =
26.7      23.6

These are K-messages per second:

Msgs      =
parsed       plain-xor    =
xor-hmac
--------  ------       =
---------    --------
27 byte    54000       =
33000          692
250 byte   20000       =
10000          668
1 KB        =
6349        =
3000          597
4 KB        =
1785         =
833          394
8 KB         =
892         =
416          265
32 KB        =
222         =
102           90
Most of the tests moved about 4GB of data that was all in page cache. It = looks like plain xor is expensive, but that basically is just measuring = memory bandwidth of streaming all the data bytes through the processor = cache which you have to figure a server is going to need to do = eventually - you can see the limit on my desktop is reached around = 26gbit/s. I replaced xor with an accumulator and and got the same = timings.

One of the things only marginally related to the question at hand = that  this tells me is that even at its most pathological case of = 27 byte messages the xor and ws framing doesn't kill us if we can = process 33million of them per second on a single core of a commodity = desktop.

I also ran a test that just calculated hmacs across the same 20 bytes to = find the bottleneck. It was 694K on one core of this box. One way to = look at the 27 byte test is that the core was doing almost exclusively = HMAC instead of core WS, but the other way is to say even though hmac = dominated the core it still did 692K messages per second! We can do a = deep dive on the I/O and where it matters, but the hmac rate is probably = the interesting limit for this discussion. (ekr suggests perhaps this = could preform better - but I think it is sufficient to use this as a = conservative number for now).

I guess I am swayed by what Maciej has to say - even though the hmac is = imo grotesquely way too expensive compared to the amount of risk it is = avoiding, it really doesn't add up to anything all that important to = obsess over. Claims of "a few percent" are not true, but even at its = most pathological a server can process 694 thousand of them per second = with a single core of a commodity desktop. Anyone interested in those = kinds of volumes easily has a LOT more processor (heck I have 3 unused = cores - and this is not a server class machine), and probably = specialized security processors (e.g. cavium nitrox) in the case of = routing switches,  that can cope without breaking a sweat - and in = turn can accommodate easily millions of messages per second.

Even with hmac enabled, processing this purely in software on even old = systems is totally reasonable for significant data flows. Giant = multiplexing servers will require more oomph. I can live with that - = they'll almost certainly have a lot more trouble terminating the = commensurate TCP than parsing websockets.

To sum it up: This is a lot like masking in general. I'm not a proponent = of HMAC because I think it is an un-necessary cost. But if that's what = we need to get consensus and ship this thing that is a reasonable = compromise I can support because I don't think it materially damages the = utility of websockets. And that is the question I find myself asking all = the time lately.

-Pat

--=20
http://www.getfirefox.com/
_______________________________________________
hybi mailing = list
hybi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/hybi

= --Boundary_(ID_wzrGxTIoH/HWAsOBkWnp4A)-- --Boundary_(ID_YweqZOt3Zh+jG1imsVJowg)-- From w@1wt.eu Sun Jan 9 06:32:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DCC3A69BE for ; Sun, 9 Jan 2011 06:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiQd1C5fkGFJ for ; Sun, 9 Jan 2011 06:32:23 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 6A98F3A69B1 for ; Sun, 9 Jan 2011 06:32:22 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09EYNX9008790; Sun, 9 Jan 2011 15:34:23 +0100 Date: Sun, 9 Jan 2011 15:34:23 +0100 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20110109143423.GM5743@1wt.eu> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 14:32:24 -0000 Hi Maciej, On Sun, Jan 09, 2011 at 06:13:03AM -0800, Maciej Stachowiak wrote: > > Hi Pat, including XOR seems like a great idea. I coded up my own XORing version, and I decided to also test HMAC with cached state as suggested by Eric, and AES-CTR instead of XOR. > > Here is a summary of my results on two-way parallel runs: > > Plain XOR: ~5.1 million msg/sec > HMAC+XOR: ~370 thousand msg/sec > cached state HMAC+XOR: 1.2 million msg/sec > AES-CTR: 2.6 million msg/sec Those are indeed better results. > == Conclusions == > > - HMAC is much faster if you do the state caching thing. > - AES-CTR is even faster than that. > - We should use AES-CTR for masking. >From what was previously said, AES cannot be used due to export regulations, so this can be quite a showstopper for broader adoption. Regards, Willy From ekr@rtfm.com Sun Jan 9 07:09:46 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A16B3A69DF for ; Sun, 9 Jan 2011 07:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCdDjXTdtDFr for ; Sun, 9 Jan 2011 07:09:45 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id AA7F23A69DE for ; Sun, 9 Jan 2011 07:09:45 -0800 (PST) Received: by yie19 with SMTP id 19so5918324yie.31 for ; Sun, 09 Jan 2011 07:11:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.83.18 with SMTP id k18mr5128334agl.79.1294585916429; Sun, 09 Jan 2011 07:11:56 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sun, 9 Jan 2011 07:11:56 -0800 (PST) In-Reply-To: <20110109074709.GK5743@1wt.eu> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <20110109074709.GK5743@1wt.eu> Date: Sun, 9 Jan 2011 07:11:56 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 15:09:46 -0000 On Sat, Jan 8, 2011 at 11:47 PM, Willy Tarreau wrote: >> I also ran a test that just calculated hmacs across the same 20 bytes to >> find the bottleneck. It was 694K on one core of this box. One way to >> look at the 27 byte test is that the core was doing almost exclusively >> HMAC instead of core WS, but the other way is to say even though hmac >> dominated the core it still did 692K messages per second! We can do a >> deep dive on the I/O and where it matters, but the hmac rate is probably >> the interesting limit for this discussion. (ekr suggests perhaps this >> could preform better - but I think it is sufficient to use this as a >> conservative number for now). > > I've seen his suggestion too, but I don't know how to do what he suggests. > It was already not easy to find some example code for using HMAC, as the > openssl man is not particularly helpful on the subject. I'm not an expert on the OpenSSL interface, but the general procedure in most systems is to call HMAC_Init() or equivalent and then memcpy() the result so that it incorporates the key. > I >> Even with hmac enabled, processing this purely in software on even old >> systems is totally reasonable for significant data flows. Giant >> multiplexing servers will require more oomph. I can live with that - >> they'll almost certainly have a lot more trouble terminating the >> commensurate TCP than parsing websockets. > > Precisely not. Efficient software and hardware already exists to process > TCP. HMAC processing can be improved but will always find a limit. Hashing > algorithms are designed to ensure that there is a non-null setup cost in > order to limit the ability to brute-force them. (1) As far as I know, this is not in fact a design criterion for hash algorithms. Indeed, how could it be since the "key schedule" for a hash is fixed and so you can always precompute. Perhaps you're thinking of encryption algorithms--though even then this is no longer really a design goal. (2) The precomputation I described above is precisely the optimization that removes any setup cost. -Ekr From ekr@rtfm.com Sun Jan 9 07:12:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEAF3A659C for ; Sun, 9 Jan 2011 07:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKyYZ93qs-zz for ; Sun, 9 Jan 2011 07:12:04 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D7D9C3A657C for ; Sun, 9 Jan 2011 07:12:03 -0800 (PST) Received: by gxk28 with SMTP id 28so8670234gxk.31 for ; Sun, 09 Jan 2011 07:14:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.67.10 with SMTP id u10mr5170529agk.187.1294586054546; Sun, 09 Jan 2011 07:14:14 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sun, 9 Jan 2011 07:14:14 -0800 (PST) In-Reply-To: References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> Date: Sun, 9 Jan 2011 07:14:14 -0800 Message-ID: From: Eric Rescorla To: Greg Wilkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 15:12:04 -0000 On Sun, Jan 9, 2011 at 1:43 AM, Greg Wilkins wrote: > > > On 9 January 2011 01:05, Pat McManus @Mozilla wrot= e: >> >> I guess I am swayed by what Maciej has to say - even though the hmac is >> imo grotesquely way too expensive compared to the amount of risk it is >> avoiding, it really doesn't add up to anything all that important to obs= ess >> over. Claims of "a few percent" are not true, but even at its most >> pathological a server can process 694 thousand of them per second with a >> single core of a commodity desktop. Anyone interested in those kinds of >> volumes easily has a LOT more processor (heck I have 3 unused cores - an= d >> this is not a server class machine), and probably specialized security >> processors (e.g. cavium nitrox) in the case of routing switches,=A0 that= can >> cope without breaking a sweat - and in turn can accommodate easily milli= ons >> of messages per second. > > The HMAC message rate may be sufficient for a intermediary that does noth= ing > but forward messages. > > But the CPU cost is significant and on server boxes that will be running = WS > and running the application, then message rate is not the only thing as > servers have other things they need to use the CPU's for. > So if WS with no masking at my required message rate takes 5% of my CPU, = but > I can probably live with XOR masking taking 10%, but HMAC masking taking > 25-50% of my CPU is going to be prohibitive! > > Not all of the high volume servers I've worked with have been CPU bound, = but > certainly some of them have been. Wow, I think you have this completely backwards: it's in systems that do almost nothing that the cost of adding a new, expensive operation is large. In systems that are already doing a lot of other processing, the marginal cost is comparaitvely low even though it may occasionally push you over some threshold; Amdahl's law and all that. -Ekr From ekr@rtfm.com Sun Jan 9 07:16:33 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F7D3A67ED for ; Sun, 9 Jan 2011 07:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhdyVIYK3Bqs for ; Sun, 9 Jan 2011 07:16:31 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 87CC03A67E5 for ; Sun, 9 Jan 2011 07:16:31 -0800 (PST) Received: by gwj17 with SMTP id 17so9905661gwj.31 for ; Sun, 09 Jan 2011 07:18:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.232.6 with SMTP id e6mr30051842agh.52.1294586321188; Sun, 09 Jan 2011 07:18:41 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sun, 9 Jan 2011 07:18:41 -0800 (PST) In-Reply-To: <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> Date: Sun, 9 Jan 2011 07:18:41 -0800 Message-ID: From: Eric Rescorla To: Maciej Stachowiak Content-Type: multipart/alternative; boundary=001636284f60ce3a8704996b5d02 Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 15:16:33 -0000 --001636284f60ce3a8704996b5d02 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 9, 2011 at 6:13 AM, Maciej Stachowiak wrote: > > Hi Pat, including XOR seems like a great idea. I coded up my own XORing > version, and I decided to also test HMAC with cached state as suggested by > Eric, and AES-CTR instead of XOR. > > Here is a summary of my results on two-way parallel runs: > > Plain XOR: ~5.1 million msg/sec > HMAC+XOR: ~370 thousand msg/sec > cached state HMAC+XOR: 1.2 million msg/sec > AES-CTR: 2.6 million msg/sec > > == Conclusions == > > - HMAC is much faster if you do the state caching thing. > - AES-CTR is even faster than that. > - We should use AES-CTR for masking. > > You'll recall this was Adam's and my original suggestion. :) We only started discussing hash-based systems when concerns about export were raised. If those concerns are still operative, we can get another factor of two by going from HMAC-SHA1 to SHA-1 alone. That doesn't thrill me from a cryptographic perspective because merging the key is tricky,but I'm sure we can figure something out that's sufficient unto the day. Best, -Ekr > Here is my code (based on Willy's version): > > > > Here is the raw data: > > == Plain XOR == > > time (./ws-parse < /tmp/stream.bin > /dev/null & ./ws-parse < > /tmp/stream.bin > /dev/null) > Mode: 0 > Mode: 0 > 20000002 messages forwarded > 20000002 messages forwarded > > real 0m3.922s > user 0m7.314s > sys 0m0.519s > > == HMAC+XOR == > > $ time (./ws-parse 1 < /tmp/stream.bin > /dev/null & ./ws-parse 1 < > /tmp/stream.bin > /dev/null) > Mode: 1 > Mode: 1 > 20000002 messages forwarded > 20000002 messages forwarded > > real 0m53.586s > user 0m53.222s > sys 0m0.347s > > == cached state HMAC+XOR == > > $ time (./ws-parse 2 < /tmp/stream.bin > /dev/null & ./ws-parse 2 < > /tmp/stream.bin > /dev/null) > Mode: 2 > Mode: 2 > 20000002 messages forwarded > 20000002 messages forwarded > > real 0m16.399s > user 0m32.098s > sys 0m0.631s > > == AES-CTR == > > $ time (./ws-parse 3 < /tmp/stream.bin > /dev/null & ./ws-parse 3 < > /tmp/stream.bin > /dev/null) > Mode: 3 > Mode: 3 > 20000002 messages forwarded > 20000002 messages forwarded > > real 0m7.695s > user 0m7.396s > sys 0m0.290s > > > > > On Jan 8, 2011, at 4:05 PM, Pat McManus @Mozilla wrote: > > Willy, this is great. Thanks. > > On Sat, 2011-01-08 at 12:16 +0100, Willy Tarreau wrote: > > I have written > a WebSocket framing parser which reads, parses and forwards frames. > > [..] > > The payload is not even unmasked with the key, the purpose is just > to evaluate the cost for a front server/load balancer/switch supposed > to switch frames to a server farm. > > I have ran it over a stream of messages whose payload was between 1 > and 125 bytes, with an average of 29 bytes (rnd(1..5) ^ 3), so that > we're in line with many legitimate uses of the protocol such as online > chat, and it happens to always fit in one byte length, making the > stream generator even easier to write. > > The results : > > [..] > > Masking the stream with HMAC multiplies the parsing time by 24 on small > messages !!! > > > Based on your experiment I was able to repeat it here on a single core of a > 2.7ghz i5. (I got a multiple of about 22x). > > I thought a few other datapoints were in order. So I rearranged your test > to be more like a server doing dispatch. I measured just frame parsing, > frame parsing with a xor on the data, and frame parsing with a xor and a 20 > byte hmac for each frame for frame sizes ranging on average from 27 bytes up > to 32KB. > > The xor just uses a constant even when we calculate the hmac. It shouldn't > matter for measurement. > > These are gigabits per second of payload data: > > Msgs parsed plain-xor xor-hmac > -------- ------ --------- -------- > 27 byte 11.7 7.1 0.15 > 250 byte 40.4 20.6 1.3 > 1 KB 50.8 25.2 5.1 > 4 KB 57.1 26.7 12.3 > 8 KB 57.1 26.7 17.0 > 32 KB 58.32 26.7 23.6 > > These are K-messages per second: > > Msgs parsed plain-xor xor-hmac > -------- ------ --------- -------- > 27 byte 54000 33000 692 > 250 byte 20000 10000 668 > 1 KB 6349 3000 597 > 4 KB 1785 833 394 > 8 KB 892 416 265 > 32 KB 222 102 90 > > > Most of the tests moved about 4GB of data that was all in page cache. It > looks like plain xor is expensive, but that basically is just measuring > memory bandwidth of streaming all the data bytes through the processor cache > which you have to figure a server is going to need to do eventually - you > can see the limit on my desktop is reached around 26gbit/s. I replaced xor > with an accumulator and and got the same timings. > > One of the things only marginally related to the question at hand that > this tells me is that even at its most pathological case of 27 byte messages > the xor and ws framing doesn't kill us if we can process 33million of them > per second on a single core of a commodity desktop. > > I also ran a test that just calculated hmacs across the same 20 bytes to > find the bottleneck. It was 694K on one core of this box. One way to look at > the 27 byte test is that the core was doing almost exclusively HMAC instead > of core WS, but the other way is to say even though hmac dominated the core > it still did 692K messages per second! We can do a deep dive on the I/O and > where it matters, but the hmac rate is probably the interesting limit for > this discussion. (ekr suggests perhaps this could preform better - but I > think it is sufficient to use this as a conservative number for now). > > I guess I am swayed by what Maciej has to say - even though the hmac is imo > grotesquely way too expensive compared to the amount of risk it is avoiding, > it really doesn't add up to anything all that important to obsess over. > Claims of "a few percent" are not true, but even at its most pathological a > server can process 694 thousand of them per second with a single core of a > commodity desktop. Anyone interested in those kinds of volumes easily has a > LOT more processor (heck I have 3 unused cores - and this is not a server > class machine), and probably specialized security processors (e.g. cavium > nitrox) in the case of routing switches, that can cope without breaking a > sweat - and in turn can accommodate easily millions of messages per second. > > Even with hmac enabled, processing this purely in software on even old > systems is totally reasonable for significant data flows. Giant multiplexing > servers will require more oomph. I can live with that - they'll almost > certainly have a lot more trouble terminating the commensurate TCP than > parsing websockets. > > To sum it up: This is a lot like masking in general. I'm not a proponent of > HMAC because I think it is an un-necessary cost. But if that's what we need > to get consensus and ship this thing that is a reasonable compromise I can > support because I don't think it materially damages the utility of > websockets. And that is the question I find myself asking all the time > lately. > > -Pat > > -- http://www.getfirefox.com/ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --001636284f60ce3a8704996b5d02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jan 9, 2011 at 6:13 AM, Maciej S= tachowiak <mjs@apple.= com> wrote:

Hi Pat, including X= OR seems like a great idea. I coded up my own XORing version, and I decided= to also test HMAC with cached state as suggested by Eric, and AES-CTR inst= ead of XOR.=A0

Here is a summary of my results on two-way parallel run= s:

Plain XOR: ~5.1 million msg/sec
HMAC+= XOR: ~370 thousand msg/sec
cached state HMAC+XOR: 1.2 million msg= /sec
AES-CTR: 2.6 million msg/sec

=3D=3D Conclusio= ns =3D=3D

- HMAC is much faster if you do the stat= e caching thing.
- AES-CTR is even faster than that.
- = We should use AES-CTR for masking.


You'll recall thi= s was Adam's and my original suggestion. :)

We= only started discussing hash-based systems when concerns about export were= raised. If those concerns are still operative, we can get another factor o= f two by=A0going from HMAC-SHA1 to SHA-1 alone. That doesn't thrill me = from a cryptographic perspective because merging the key is tricky,but I= 9;m sure we can figure something out that's sufficient unto the day.

Best,
-Ekr
=A0
Here i= s my code (based on Willy's version):



Here= is the raw data:

=3D=3D Plain XOR =3D=3D

time (./ws-parse < /tmp/stream.bin > /dev/null = & ./ws-parse < /tmp/stream.bin > /dev/null)
Mode: 0
Mode: 0
20000002 messages forwarded
<= div>20000002 messages forwarded

real 0m3.922s
user 0m7.314s
sys 0m0.519s

=3D=3D HMAC+XOR =3D=3D

$ time (./ws-parse 1 < /tmp/stream.bin > /dev/null & ./ws-= parse 1 < /tmp/stream.bin > /dev/null)
Mode: 1
Mode: 1
20000002 messages forwarded
<= div>
20000002 messages forwarded

real 0m53.586s
user 0m53.222s
sys 0m0.347s

=3D=3D cached state HMAC+XOR =3D=3D
=

$ time (./ws-parse 2 < /tmp/stream.bin &g= t; /dev/null & ./ws-parse 2 < /tmp/stream.bin > /dev/null)
Mode: 2
Mode: 2
20000002 messages forwarded
<= div>20000002 messages forwarded

real 0m16.399s
user 0m32.098s
sys 0m0.631s

=3D=3D AES-CTR =3D=3D

$ tim= e (./ws-parse 3 < /tmp/stream.bin > /dev/null & ./ws-parse 3 <= /tmp/stream.bin > /dev/null)
Mode: 3
Mode: 3
20000002 messages forwarded
<= div>
20000002 messages forwarded

real 0m7.695s
user 0m7.396s
sys 0m0.290s




On Jan 8, 2011, at= 4:05 PM, Pat McManus @Mozilla wrote:

Willy, this is great. Thanks.

On Sat, 2011-01-08 at 12:16 +0100, Willy Tarreau wrote: 
 I have written
a WebSocket framing parser which reads, parses and forwards frames.
[..] 
The payload is not even unmasked with the key, the purpose is just
to evaluate the cost for a front server/load balancer/switch supposed
to switch frames to a server farm.

I have ran it over a stream of messages whose payload was between 1
and 125 bytes, with an average of 29 bytes (rnd(1..5) ^ 3), so that
we're in line with many legitimate uses of the protocol such as online
chat, and it happens to always fit in one byte length, making the
stream generator even easier to write.

The results :
[..] 
Masking the stream with HMAC multiplies the parsing time by 24 on smal=
l
messages !!!=20

Based on your experiment I was able to repeat it here on a single core of a= 2.7ghz i5. (I got a multiple of about 22x).

I thought a few other datapoints were in order. So I rearranged your test t= o be more like a server doing dispatch. I measured just frame parsing, fram= e parsing with a xor on the data, and frame parsing with a xor and a 20 byt= e hmac for each frame for frame sizes ranging on average from 27 bytes up t= o 32KB.

The xor just uses a constant even when we calculate the hmac. It shouldn= 9;t matter for measurement.

These are gigabits per second of payload data: 
Msgs=A0=A0=A0=A0=A0 parsed=A0=A0=A0 plain-xor=A0=A0=A0 xor-hmac
--------=A0 ------=A0=A0=A0 ---------=A0=A0=A0 --------
27 byte=A0=A0=A0 11.7=A0=A0=A0=A0=A0=A0=A0=A0=A0 7.1=A0=A0=A0=A0=A0=A0 0.15
250 byte=A0=A0 40.4=A0=A0=A0=A0=A0=A0=A0=A0 20.6=A0=A0=A0=A0=A0=A0 1.3
1 KB=A0=A0=A0=A0=A0=A0 50.8=A0=A0=A0=A0=A0=A0=A0=A0 25.2=A0=A0=A0=A0=A0=A0 =
5.1
4 KB=A0=A0=A0=A0=A0=A0 57.1=A0=A0=A0=A0=A0=A0=A0=A0 26.7=A0=A0=A0=A0=A0 12.=
3
8 KB=A0=A0=A0=A0=A0=A0 57.1=A0=A0=A0=A0=A0=A0=A0=A0 26.7=A0=A0=A0=A0=A0 17.=
0
32 KB=A0=A0=A0=A0=A0 58.32=A0=A0=A0=A0=A0=A0=A0 26.7=A0=A0=A0=A0=A0 23.6

These are K-messages per second:

Msgs=A0=A0=A0=A0=A0 parsed=A0=A0=A0=A0=A0=A0 plain-xor=A0=A0=A0 xor-hmac
--------=A0 ------=A0=A0=A0=A0=A0=A0 ---------=A0=A0=A0 --------
27 byte=A0=A0=A0 54000=A0=A0=A0=A0=A0=A0 33000=A0=A0=A0=A0=A0=A0=A0=A0=A0 6=
92
250 byte=A0=A0 20000=A0=A0=A0=A0=A0=A0 10000=A0=A0=A0=A0=A0=A0=A0=A0=A0 668
1 KB=A0=A0=A0=A0=A0=A0=A0 6349=A0=A0=A0=A0=A0=A0=A0 3000=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 597
4 KB=A0=A0=A0=A0=A0=A0=A0 1785=A0=A0=A0=A0=A0=A0=A0=A0 833=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 394
8 KB=A0=A0=A0=A0=A0=A0=A0=A0 892=A0=A0=A0=A0=A0=A0=A0=A0 416=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 265
32 KB=A0=A0=A0=A0=A0=A0=A0 222=A0=A0=A0=A0=A0=A0=A0=A0 102=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 90
Most of the tests moved about 4GB of data that was all in page cache. It lo= oks like plain xor is expensive, but that basically is just measuring memor= y bandwidth of streaming all the data bytes through the processor cache whi= ch you have to figure a server is going to need to do eventually - you can = see the limit on my desktop is reached around 26gbit/s. I replaced xor with= an accumulator and and got the same timings.

One of the things only marginally related to the question at hand that=A0 t= his tells me is that even at its most pathological case of 27 byte messages= the xor and ws framing doesn't kill us if we can process 33million of = them per second on a single core of a commodity desktop.

I also ran a test that just calculated hmacs across the same 20 bytes to fi= nd the bottleneck. It was 694K on one core of this box. One way to look at = the 27 byte test is that the core was doing almost exclusively HMAC instead= of core WS, but the other way is to say even though hmac dominated the cor= e it still did 692K messages per second! We can do a deep dive on the I/O a= nd where it matters, but the hmac rate is probably the interesting limit fo= r this discussion. (ekr suggests perhaps this could preform better - but I = think it is sufficient to use this as a conservative number for now).

I guess I am swayed by what Maciej has to say - even though the hmac is imo= grotesquely way too expensive compared to the amount of risk it is avoidin= g, it really doesn't add up to anything all that important to obsess ov= er. Claims of "a few percent" are not true, but even at its most = pathological a server can process 694 thousand of them per second with a si= ngle core of a commodity desktop. Anyone interested in those kinds of volum= es easily has a LOT more processor (heck I have 3 unused cores - and this i= s not a server class machine), and probably specialized security processors= (e.g. cavium nitrox) in the case of routing switches,=A0 that can cope wit= hout breaking a sweat - and in turn can accommodate easily millions of mess= ages per second.

Even with hmac enabled, processing this purely in software on even old syst= ems is totally reasonable for significant data flows. Giant multiplexing se= rvers will require more oomph. I can live with that - they'll almost ce= rtainly have a lot more trouble terminating the commensurate TCP than parsi= ng websockets.

To sum it up: This is a lot like masking in general. I'm not a proponen= t of HMAC because I think it is an un-necessary cost. But if that's wha= t we need to get consensus and ship this thing that is a reasonable comprom= ise I can support because I don't think it materially damages the utili= ty of websockets. And that is the question I find myself asking all the tim= e lately.

-Pat

--=20
http://www.getfire=
fox.com/
_______________________________________________
hybi mailing list
hybi@ietf.org
https://= www.ietf.org/mailman/listinfo/hybi


__________________________________________= _____
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--001636284f60ce3a8704996b5d02-- From mcmanus@ducksong.com Sun Jan 9 07:39:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4FD03A6803 for ; Sun, 9 Jan 2011 07:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKyFu2DYtHKt for ; Sun, 9 Jan 2011 07:39:35 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id C58473A67FA for ; Sun, 9 Jan 2011 07:39:35 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id 845501043E; Sun, 9 Jan 2011 10:41:46 -0500 (EST) 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 7EB0210305; Sun, 9 Jan 2011 10:41:41 -0500 (EST) From: Patrick McManus To: Eric Rescorla In-Reply-To: References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 09 Jan 2011 10:41:28 -0500 Message-ID: <1294587688.7650.561.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 15:39:36 -0000 On Sun, 2011-01-09 at 07:14 -0800, Eric Rescorla wrote: > ges. > > > > But the CPU cost is significant and on server boxes that will be running WS > > and running the application, then message rate is not the only thing as > > servers have other things they need to use the CPU's for. > > So if WS with no masking at my required message rate takes 5% of my CPU, but > > I can probably live with XOR masking taking 10%, but HMAC masking taking > > 25-50% of my CPU is going to be prohibitive! > > > > Not all of the high volume servers I've worked with have been CPU bound, but > > certainly some of them have been. > > Wow, I think you have this completely backwards: it's in systems that > do almost nothing > that the cost of adding a new, expensive operation is large. In > systems that are already > doing a lot of other processing, the marginal cost is comparaitvely > low even though it may > occasionally push you over some threshold; Amdahl's law and all that. +1 ,.. at these volumes the concerning case is the ws-router, not the server doing useful things. It is of course a syllogism to conclude that the more expensive hmac means less resources for "real work". I think the more useful conclusion here given the raw volumes is that any reasonable volume of "real work" precludes reaching message rates where the hmac adds up to very much. Of course I cannot know that for certain before someone accuses me of presuming I know every use case for the protocol - it is a judgment based on experience. ymmv. That leaves us, imo: 1 - hmac adds a significant but bearable cost in return for a very minor reduction in risk 2 - aes costs computationally less for the same return but has potential hassles with legal vetting. aes is being deployed in new intel commodity processors, likely driving the cost down even further. 3 - xor with a sliding mask is probably the cheapest option given consensus on masking and comes bundled with a non-specific risk. My preference remains for #3 because I'm not paranoid about the specific risk - but I don't see any reason to object to #1 if that is needed for consensus. Websockets would still be a perfectly good protocol with #1 and the fact that it reflects input from wide points of view might only makes it stronger. I would want to research #2 more before supporting that as part of the standard. From w@1wt.eu Sun Jan 9 07:48:14 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08D33A6803 for ; Sun, 9 Jan 2011 07:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYX1kRpKz+sX for ; Sun, 9 Jan 2011 07:48:14 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 991843A6805 for ; Sun, 9 Jan 2011 07:48:13 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09FoLnr008932; Sun, 9 Jan 2011 16:50:21 +0100 Date: Sun, 9 Jan 2011 16:50:20 +0100 From: Willy Tarreau To: Patrick McManus Message-ID: <20110109155020.GN5743@1wt.eu> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <1294587688.7650.561.camel@ds9.ducksong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1294587688.7650.561.camel@ds9.ducksong.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 15:48:15 -0000 On Sun, Jan 09, 2011 at 10:41:28AM -0500, Patrick McManus wrote: > On Sun, 2011-01-09 at 07:14 -0800, Eric Rescorla wrote: > > ges. > > > > > > But the CPU cost is significant and on server boxes that will be running WS > > > and running the application, then message rate is not the only thing as > > > servers have other things they need to use the CPU's for. > > > So if WS with no masking at my required message rate takes 5% of my CPU, but > > > I can probably live with XOR masking taking 10%, but HMAC masking taking > > > 25-50% of my CPU is going to be prohibitive! > > > > > > Not all of the high volume servers I've worked with have been CPU bound, but > > > certainly some of them have been. > > > > Wow, I think you have this completely backwards: it's in systems that > > do almost nothing > > that the cost of adding a new, expensive operation is large. In > > systems that are already > > doing a lot of other processing, the marginal cost is comparaitvely > > low even though it may > > occasionally push you over some threshold; Amdahl's law and all that. > > +1 ,.. at these volumes the concerning case is the ws-router, not the > server doing useful things. It is of course a syllogism to conclude that > the more expensive hmac means less resources for "real work". > > I think the more useful conclusion here given the raw volumes is that > any reasonable volume of "real work" precludes reaching message rates > where the hmac adds up to very much. Of course I cannot know that for > certain before someone accuses me of presuming I know every use case for > the protocol - it is a judgment based on experience. ymmv. > > That leaves us, imo: > > 1 - hmac adds a significant but bearable cost in return for a very > minor reduction in risk > 2 - aes costs computationally less for the same return but has > potential hassles with legal vetting. aes is being deployed in new intel > commodity processors, likely driving the cost down even further. > 3 - xor with a sliding mask is probably the cheapest option given > consensus on masking and comes bundled with a non-specific risk. > > My preference remains for #3 because I'm not paranoid about the specific > risk - but I don't see any reason to object to #1 if that is needed for > consensus. Websockets would still be a perfectly good protocol with #1 > and the fact that it reflects input from wide points of view might only > makes it stronger. I would want to research #2 more before supporting > that as part of the standard. I agree with your approach Pat. Also, I'm still doing some work but it appears that for our precise concern, HMAC will finally not provide any better protection over a simple XOR due to the ease of making the client generate known small messages. Anyway, both do still offer quite a good masking capability, which is what we're looking for in the first place. More on that later. Cheers, Willy From w@1wt.eu Sun Jan 9 09:49:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C393A67D4 for ; Sun, 9 Jan 2011 09:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhbZ9GNcZBNR for ; Sun, 9 Jan 2011 09:49:11 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id B6DE03A67C1 for ; Sun, 9 Jan 2011 09:49:09 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09HpItZ009259 for hybi@ietf.org; Sun, 9 Jan 2011 18:51:18 +0100 Date: Sun, 9 Jan 2011 18:51:18 +0100 From: Willy Tarreau To: "hybi@ietf.org" Message-ID: <20110109175118.GP5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 17:49:13 -0000 Hi, I found that it was possible to sensibly reduce the difficulty in making an intermediary forward a valid HTTP request despite masking. My feeling is that the risk remains extremely low as it still requires a substantial amount of garbage to be skipped to find a request, and that we have not detected any such vulnerable intermediaries. Still I wanted to share my experiments. Abstract: The attack described here does not exploit any weakness in the mask generation algorithm, it only exploits the way the mask is applied. This means that the strongest algorithm such as HMAC will not provide any advantage over the simpler ones such as a simple 32-bit random number obtained from a valid source. The residual risk is still almost zero, so if the HMAC method is acceptable, then any cheaper method providing at least a 32-bit key is also acceptable. The goal of the initially proposed XOR masking is to prevent an attacker who controls a server from forcing a client to send known text to it via a caching intermediary which could see an HTTP request there and unduly cache the attacker server's response. It has been proven that some intermediaries will consider the 101+Upgrade response as a final response and expect a new request from the client. It has also been speculated that some lazy intermediaries might even scan the request stream to seek a request after some garbage, hence the need to mask all the stream. It is a fact that some intermediaries exist who accept HTTP/0.9 requests after an HTTP/1.1 request. Apache is one of them. And it even accepts requests composed only from a GET method followed by a line feed, without resource name. That might come from back in the old days where it was suggested that by default the resource was "/". What this means is that it's enough to send the 4 bytes "G", "E", "T", LF to Apache for it to see a request. Even better, Apache rewrites the request as a perfectly valid HTTP/1.1 request when forwarding it, which means that those 4 bytes are completely enough to fool a less lazy downstream cache : GET / HTTP/1.1 Host: 10.8.3.1:8080 X-Forwarded-For: 127.0.0.1 X-Forwarded-Server: dummy-host.example.com Connection: Keep-Alive This has several impacts : 1) A lazy intermediary which accepts the same requests as Apache, but which would search them anywhere in the stream could reformulate it as a plain valid request to next hop. 2) Even if the intermediary does not scan for the request anywhere in the stream, if we put the random key at the beginning of the stream, 1 time on 4 billion a random key will match "GET\n". Note1: Apache does not expect a second request after a 101 and is not fooled by this issue. Note2: It could probably be accepted that 4 billion connections to make a client emit such a request is high enough not to care more about the issue. Hence it was interesting to see how the XOR-based masking could be abused to make a client emit "GET\n" in less than 4 billion connections, regardless of the algorithm used to build the masking key. The principle is to make the client emit many incremental 32-bit values, hoping that "GET\n" will appear soon enough. In theory, such a pattern should happen every 2^32 patterns, which is every 16 gigabytes. This is far too much to expect from a client to pass through a server to hope it will spot anything useful. However, we have a way to reduce the analysis to two consecutive phases each of the complexity of the square root of the pattern space (65536). Since the currently discussed masking method involves a fixed mask which is repeated over the stream, it is possible since the beginning of the stream to determine how long it will take so a "GET\n" appear. The fact that we're using a 160-bit mask means we can pack 5 of such 32-bit patterns in a mask, then multiply by 5 the chances to see a "GET\n" from a single pattern. The client will then build a single frame composed of 5 times the same pattern, then incremented 65536 times. The server will check the input stream, looking for the bytes "G" and "E". If those bytes do not appear, it will terminate the connection because it means this connection will require too many blocks to get the correct values. The 160-bit mask offers us the ability to find the required pattern a lot faster, because in each connections, this fixed mask can in fact be seen as 5 indepedant 32-bit masks. The net effect it that it divides by 5 the number of required connections to get the expected bytes (in practice, it is possible to achieve the same optimization with a smaller mask, it just requires the client to send multiple different patterns). On average, 65536/5 = 13107 connections are required to get a candidate connection. If the server finds that the XOR mask will make "G" and "E" appear, then it reads the stream so that the client emits all possible combinations of 3rd and 4th chars, which means that at most 20*65536 = 1.3 Megabytes are required once a candidate connection is found. The ws-attack program contains both the client and the server code. For the sake of simplicity, it does not do any networking, but it is designed with clearly distinct parts which communicate via a sequentially accessed buffer, so that the roles are more easily identifiable and both could be split if required. Results : The program can be downloaded at http://1wt.eu/websocket/ws-attack.c willy@pcw:~/c$ time ./ws-attack Found pattern 'GET\n' at block 172226 after 6615 connections and 1469504 bytes sent real 0m0.030s user 0m0.032s sys 0m0.000s willy@pcw:~/c$ time ./ws-attack Found pattern 'GET\n' at block 207343 after 16071 connections and 1696448 bytes sent real 0m0.069s user 0m0.068s sys 0m0.000s willy@pcw:~/c$ time ./ws-attack Found pattern 'GET\n' at block 150470 after 95 connections and 1313024 bytes sent real 0m0.003s user 0m0.000s sys 0m0.004s willy@pcw:~/c$ time ./ws-attack Found pattern 'GET\n' at block 139582 after 28577 connections and 1996592 bytes sent real 0m0.119s user 0m0.116s sys 0m0.008s Conclusion : Between 1.3 and 1.9 MB of framing data were required to get the expected request the masking method was supposed to prevent from appearing. A sliding self-regenerating mask would only make it slightly harder for the server to decide upon accepting or rejecting the connection, because once it gets the seed, it can locally simulate the emitted stream to find whether the pattern will appear or not, but the improvement is not significant. All in all, we see that we still need the client to send megabytes of data to make a short request pop up. It is extremely unlikely that any caching intermediary would skip over that amount of data to spot a valid request, and it is contrary to the principle of lazyness because implementing such one is a lot harder than making it do the right thing. BTW, no such intermediary has yet been detected nor identified. All the issues always converge to the same point : avoiding the LF character (and possibly the CR) in the WS stream. But that's not easy or it requires more expensive escaping or encoding (eg: base64). Proposals : 1) keep the XOR-based masking with a simpler key generation algorithm to keep the per-frame masking cost low. An improvement might also consist in avoiding the LF character in the key. 2) use a more expensive LF-less masking such as base64, but this one must be optional. 3) escape the LF character and define an escape character which must also be escaped itself. It is cheaper network-wise, but more expensive on the client side where the stream must be read once to count the LFs before being encoded and emitted. 4) use Dave Cridland's idea of inserting an invalid HTTP request before the beginning of the stream. The request should remain simple and short with the goal to quickly fail. My personal suggestion would be stay in line with the progress that was done and to go for #1. Regards, Willy From andy.warmcat.com@googlemail.com Sun Jan 9 10:41:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54DF3A682F for ; Sun, 9 Jan 2011 10:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0hfJhZaZnMY for ; Sun, 9 Jan 2011 10:41:00 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 362B83A67DF for ; Sun, 9 Jan 2011 10:40:59 -0800 (PST) Received: by wyf23 with SMTP id 23so19824467wyf.31 for ; Sun, 09 Jan 2011 10:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yGiUbtecK4b/lbra89jYhwoRFJmn44davY2Kqn3nqsY=; b=ldIajXPYGx+htkzlDH6wvb8Nw9fIa5MuRQRggvMtOz6SXf3SXv7x3fJnN1P94H4tX0 Tm0aFr/s3wogo0rBEOZeV51haUiS8nB8oy120rYZ2sFYW3Q7LfKlnLTZLcf44yt3MPIj Xq2RbhAJZoheywv2ll5RtOhgFN4C8TXRKj1LE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=n7iZ3S2KbwmpNbCAOCwYMpzPHTAfugUqjwPgmS0QIfJV1OYyTeDknQ7lYQ7F44Vlyw nfJFPWyeUB4JuEpWrS0JyU62h1h2NUY3LsN+H6XC4Po5BYqb8pKbOni9Ibze0HD6m9vi MrWGMIrbwFcXTWCwftlZ67rcndS0vJt2kcPQo= Received: by 10.227.132.143 with SMTP id b15mr1754307wbt.9.1294598508823; Sun, 09 Jan 2011 10:41:48 -0800 (PST) Received: from [10.8.0.6] (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id f35sm19438090wbf.14.2011.01.09.10.41.47 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 10:41:48 -0800 (PST) Sender: Andy Green Message-ID: <4D2A016A.1080500@warmcat.com> Date: Sun, 09 Jan 2011 18:41:46 +0000 From: Andy Green User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101217 Fedora/3.1.7-0.39.b3pre.fc15 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <20110109175118.GP5743@1wt.eu> In-Reply-To: <20110109175118.GP5743@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andy@warmcat.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 18:41:01 -0000 On 01/09/11 17:51, Somebody in the thread at some point said: > 1) keep the XOR-based masking with a simpler key generation algorithm to > keep the per-frame masking cost low. An improvement might also consist > in avoiding the LF character in the key. > > 2) use a more expensive LF-less masking such as base64, but this one must be > optional. > > 3) escape the LF character and define an escape character which must also be > escaped itself. It is cheaper network-wise, but more expensive on the > client side where the stream must be read once to count the LFs before > being encoded and emitted. > > 4) use Dave Cridland's idea of inserting an invalid HTTP request before the > beginning of the stream. The request should remain simple and short with > the goal to quickly fail. > > My personal suggestion would be stay in line with the progress that was done > and to go for #1. Congratulations dude for doing that work, making it repeatable by providing code and identifying the tools used. Although there's still no broken intermediary identified as you pointed out twice, otherwise this poured out a lot more facts and logic than heretofore. Options 1 - 3 kill or reduce the chance of zerocopy, 4 leaves that open. For that reason 4 sounds like the best guy to me. Is the attack that it defeats is enough for the browser guys? Is there anything otherwise wrong with Dave's idea, it's really simple and lightweight and leaves the rest of the current draft intact. -Andy From salvatore.loreto@ericsson.com Sun Jan 9 11:29:55 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069DA3A67FB for ; Sun, 9 Jan 2011 11:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJtsRYSyHppd for ; Sun, 9 Jan 2011 11:29:53 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7D2A23A67D4 for ; Sun, 9 Jan 2011 11:29:52 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-a8-4d2a0d330d36 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AA.CC.23694.33D0A2D4; Sun, 9 Jan 2011 20:32:03 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Sun, 9 Jan 2011 20:32:02 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B7265251F for ; Sun, 9 Jan 2011 21:32:02 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7E9A5504FE for ; Sun, 9 Jan 2011 21:32:02 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0B6DF4FCB2 for ; Sun, 9 Jan 2011 21:32:01 +0200 (EET) Message-ID: <4D2A0D31.1070703@ericsson.com> Date: Sun, 9 Jan 2011 20:32:01 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110109175118.GP5743@1wt.eu> <4D2A016A.1080500@warmcat.com> In-Reply-To: <4D2A016A.1080500@warmcat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 19:29:55 -0000 On 1/9/11 7:41 PM, Andy Green wrote: > On 01/09/11 17:51, Somebody in the thread at some point said: > >> 1) keep the XOR-based masking with a simpler key generation algorithm to >> keep the per-frame masking cost low. An improvement might also consist >> in avoiding the LF character in the key. >> >> 2) use a more expensive LF-less masking such as base64, but this one must be >> optional. >> >> 3) escape the LF character and define an escape character which must also be >> escaped itself. It is cheaper network-wise, but more expensive on the >> client side where the stream must be read once to count the LFs before >> being encoded and emitted. >> >> 4) use Dave Cridland's idea of inserting an invalid HTTP request before the >> beginning of the stream. The request should remain simple and short with >> the goal to quickly fail. >> >> My personal suggestion would be stay in line with the progress that was done >> and to go for #1. > Congratulations dude for doing that work, making it repeatable by > providing code and identifying the tools used. > > Although there's still no broken intermediary identified as you pointed > out twice, otherwise this poured out a lot more facts and logic than > heretofore. > > Options 1 - 3 kill or reduce the chance of zerocopy, 4 leaves that open. > For that reason 4 sounds like the best guy to me. > > Is the attack that it defeats is enough for the browser guys? > > Is there anything otherwise wrong with Dave's idea, it's really simple > and lightweight and leaves the rest of the current draft intact. > > -Andy Hi Andy, as officially announced yesterday (http://www.ietf.org/mail-archive/web/hybi/current/msg05677.html) the consensus expressed (a strong consensus I would say) by the strawpoll was for adopt an handshake based on GET+Upgrade+masking. so please, just accept the fact the consensus is to go for masking! /Sal --- Salvatore Loreto www.sloreto.com From mjs@apple.com Sun Jan 9 11:42:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE323A6833 for ; Sun, 9 Jan 2011 11:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFjh+PPVZT2k for ; Sun, 9 Jan 2011 11:42:34 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id C5F413A6830 for ; Sun, 9 Jan 2011 11:42:34 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 7FD64C5E62B6 for ; Sun, 9 Jan 2011 11:44:46 -0800 (PST) X-AuditID: 11807136-b7bf8ae00000244a-14-4d2a102e196d Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay15.apple.com (Apple SCV relay) with SMTP id A8.C3.09290.E201A2D4; Sun, 9 Jan 2011 11:44:46 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.14] ([24.6.209.6]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LER00LXCTIL6230@et.apple.com> for hybi@ietf.org; Sun, 09 Jan 2011 11:44:46 -0800 (PST) From: Maciej Stachowiak In-reply-to: <20110109143423.GM5743@1wt.eu> Date: Sun, 09 Jan 2011 11:44:45 -0800 Message-id: References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 19:42:35 -0000 On Jan 9, 2011, at 6:34 AM, Willy Tarreau wrote: > Hi Maciej, > > On Sun, Jan 09, 2011 at 06:13:03AM -0800, Maciej Stachowiak wrote: >> >> Hi Pat, including XOR seems like a great idea. I coded up my own XORing version, and I decided to also test HMAC with cached state as suggested by Eric, and AES-CTR instead of XOR. >> >> Here is a summary of my results on two-way parallel runs: >> >> Plain XOR: ~5.1 million msg/sec >> HMAC+XOR: ~370 thousand msg/sec >> cached state HMAC+XOR: 1.2 million msg/sec >> AES-CTR: 2.6 million msg/sec > > Those are indeed better results. > >> == Conclusions == >> >> - HMAC is much faster if you do the state caching thing. >> - AES-CTR is even faster than that. >> - We should use AES-CTR for masking. > > From what was previously said, AES cannot be used due to export > regulations, so this can be quite a showstopper for broader adoption. I remember that being said, but I am skeptical. My understanding of US crypto export regulations is that merely using existing crypto facilities from the operating system or from separate components is not subject to export limitations. AES-CTR is in libcrypto which is widely available all over the world. I'm skeptical that there is any place in the world where you can easily use SHA1 HMAC but not AES-CTR. So if anyone wants to claim that use of AES-CTR would cause problems with export regulations, I would ask them to substantiate that claim. Even if the export considerations do turn out to be real, AES-CTR has better security properties and considerably better performance than HMAC. I don't think we should let the legal regime around crypto limit the quality of the protocol. Regards, Maciej From w@1wt.eu Sun Jan 9 12:01:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520523A683D for ; Sun, 9 Jan 2011 12:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHyiTSGs+XdV for ; Sun, 9 Jan 2011 12:01:46 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id F33E63A6811 for ; Sun, 9 Jan 2011 12:01:45 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09K3kcH009608; Sun, 9 Jan 2011 21:03:46 +0100 Date: Sun, 9 Jan 2011 21:03:46 +0100 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20110109200346.GR5743@1wt.eu> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:01:47 -0000 On Sun, Jan 09, 2011 at 11:44:45AM -0800, Maciej Stachowiak wrote: > > From what was previously said, AES cannot be used due to export > > regulations, so this can be quite a showstopper for broader adoption. > > I remember that being said, but I am skeptical. My understanding of US crypto export regulations is that merely using existing crypto facilities from the operating system or from separate components is not subject to export limitations. AES-CTR is in libcrypto which is widely available all over the world. I'm skeptical that there is any place in the world where you can easily use SHA1 HMAC but not AES-CTR. So if anyone wants to claim that use of AES-CTR would cause problems with export regulations, I would ask them to substantiate that claim. > > Even if the export considerations do turn out to be real, AES-CTR has better security properties and considerably better performance than HMAC. I don't think we should let the legal regime around crypto limit the quality of the protocol. Well, I understand your point, but it could be seen from a different angle : some will think that it's not worth risking to limit WS adoption just because we're trying to cover an issue that has been speculated might exist. For instance, most low-level network equipment would not require any form of encryption at all. If a NAT router requires support for AES in order to be able to NAT addresses presented in the stream, it's very well possible that the firm will need a license to address some countries. Also, you may be interested in the other experiment I have posted. In short, we could make such a supposedly existing intermediary emit a request after feeding it with several megs of data and a few tens of thousands of connection attempts. In this context, AES-CTR will only require more bytes to be sent (at most 16 GB). But there is no reason to think that an intermediary that is broken enough to be able to spot a request after several megs of data is not able anymore after several gigs. So in the end, despite the better crypto properties for AES-CTR than HMAC, whether they're basic XOR, HMAC or AES, they're addressing the same issues and risks, at different costs to exploit the supposed issues and at different implementation costs. Regards, Willy From metajack@gmail.com Sun Jan 9 12:03:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401FC3A682F for ; Sun, 9 Jan 2011 12:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV8tPyI+McOc for ; Sun, 9 Jan 2011 12:03:41 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C88013A6811 for ; Sun, 9 Jan 2011 12:03:40 -0800 (PST) Received: by bwz12 with SMTP id 12so18552414bwz.31 for ; Sun, 09 Jan 2011 12:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=oyAF+TzYhkZwuAgpVzHOJtyualGHUqciba8Zd1yZpnM=; b=q4q7W0WYPJzlgMoHu1tbNel6onV7r3qTK0P+SmgsAxxlESkURa2NZLIors3tGCMn+8 WqBdTiab3a7nD4VH9BElqqEqATu954YvErrwyNEIII8OARKT56/2LdXnkuiJIv0XoLmf 89/p5cje1CtHGKYG91WQGuFdyiY0YrJ5Z23hI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=DdqV7QRmd4lxjnca/dRbeGlkuu5HtIIY9q5HWyVWMwzxoVnRFXEIEPn8ptb66WCyUu /wzzprIP8oaXygsKDk3vR6NIG/yZdRGsRgto8a2nqdXJt295oD1dizhxNg0RPlyBtIZF KCc6eXe/NT1gfyRJ6OjWB09P1x+12lVQh/9t0= MIME-Version: 1.0 Received: by 10.204.81.72 with SMTP id w8mr13855717bkk.205.1294603550513; Sun, 09 Jan 2011 12:05:50 -0800 (PST) Sender: metajack@gmail.com Received: by 10.204.119.211 with HTTP; Sun, 9 Jan 2011 12:05:50 -0800 (PST) In-Reply-To: References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> Date: Sun, 9 Jan 2011 13:05:50 -0700 X-Google-Sender-Auth: GfH6wRxlERF4MehPnYj7al-SeuU Message-ID: From: Jack Moffitt To: Maciej Stachowiak Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:03:42 -0000 > I remember that being said, but I am skeptical. My understanding of US cr= ypto export regulations is that merely using existing crypto facilities fro= m the operating system or from separate components is not subject to export= limitations. AES-CTR is in libcrypto which is widely available all over th= e world. I'm skeptical that there is any place in the world where you can e= asily use SHA1 HMAC but not AES-CTR. So if anyone wants to claim that use o= f AES-CTR would cause problems with export regulations, I would ask them to= substantiate that claim. This does not seem to be the case: http://stackoverflow.com/questions/2135081/does-my-application-contain-encr= yption It appears not to matter if you use something that is part of the system, even for uses as benign as using a system library to access an https URL. Of course, it's possible Apple is overly conservative. I don't think it's terribly difficult to get the required permission, but I imagine that TLS adoption in iOS apps is quite low because of this problem. Given that the App Store seems to enforce these regulations, I think we can expect it to also apply to a WebSocket with AES-CTR. It appears that this may be improving: http://www.federalregister.gov/articles/2011/01/07/2010-32803/publicly-avai= lable-mass-market-encryption-software-and-other-specified-publicly-availabl= e-encryption jack. From mjs@apple.com Sun Jan 9 12:14:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4243A67D4 for ; Sun, 9 Jan 2011 12:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sllzzE3z4Mja for ; Sun, 9 Jan 2011 12:14:21 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 081193A6833 for ; Sun, 9 Jan 2011 12:14:21 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id A6F17C5E72BA for ; Sun, 9 Jan 2011 12:16:32 -0800 (PST) X-AuditID: 1180711d-b7c30ae0000055b4-f7-4d2a17a06251 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay13.apple.com (Apple SCV relay) with SMTP id 0B.50.21940.0A71A2D4; Sun, 9 Jan 2011 12:16:32 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.103.151] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LER00LO6UZJ6240@et.apple.com> for hybi@ietf.org; Sun, 09 Jan 2011 12:16:32 -0800 (PST) From: Maciej Stachowiak In-reply-to: Date: Sun, 09 Jan 2011 12:16:31 -0800 Message-id: <24A9239F-68B2-4AA2-8B37-0AF5A2879DBC@apple.com> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> To: Jack Moffitt X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:14:22 -0000 On Jan 9, 2011, at 12:05 PM, Jack Moffitt wrote: >> I remember that being said, but I am skeptical. My understanding of US crypto export regulations is that merely using existing crypto facilities from the operating system or from separate components is not subject to export limitations. AES-CTR is in libcrypto which is widely available all over the world. I'm skeptical that there is any place in the world where you can easily use SHA1 HMAC but not AES-CTR. So if anyone wants to claim that use of AES-CTR would cause problems with export regulations, I would ask them to substantiate that claim. > > This does not seem to be the case: > > http://stackoverflow.com/questions/2135081/does-my-application-contain-encryption > > It appears not to matter if you use something that is part of the > system, even for uses as benign as using a system library to access an > https URL. Of course, it's possible Apple is overly conservative. I work for Apple, and the answer there doesn't seem to match what I've heard about export compliance from our legal department. However, since it's a complicated issue, I won't claim there is a definitive answer to this question, and I am certainly not qualified to give legal advice on the matter. > > I don't think it's terribly difficult to get the required permission, > but I imagine that TLS adoption in iOS apps is quite low because of > this problem. Given that the App Store seems to enforce these > regulations, I think we can expect it to also apply to a WebSocket > with AES-CTR. > > It appears that this may be improving: > > http://www.federalregister.gov/articles/2011/01/07/2010-32803/publicly-available-mass-market-encryption-software-and-other-specified-publicly-available-encryption If the legal regime is being liberalized, then we definitely shouldn't cripple the protocol. Regards, Maciej From mjs@apple.com Sun Jan 9 12:20:14 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177023A6810 for ; Sun, 9 Jan 2011 12:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blEwrd8MU-Bi for ; Sun, 9 Jan 2011 12:20:13 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 2C6D03A67D4 for ; Sun, 9 Jan 2011 12:20:12 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id DB576CA6C898 for ; Sun, 9 Jan 2011 12:22:23 -0800 (PST) X-AuditID: 11807136-b7bf8ae00000244a-aa-4d2a18ff58cf Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id 04.28.09290.FF81A2D4; Sun, 9 Jan 2011 12:22:23 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.103.151] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LER00KYXV9AC200@elliott.apple.com> for hybi@ietf.org; Sun, 09 Jan 2011 12:22:23 -0800 (PST) From: Maciej Stachowiak In-reply-to: <20110109200346.GR5743@1wt.eu> Date: Sun, 09 Jan 2011 12:22:22 -0800 Message-id: References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> <20110109200346.GR5743@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:20:14 -0000 On Jan 9, 2011, at 12:03 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 11:44:45AM -0800, Maciej Stachowiak wrote: >>> From what was previously said, AES cannot be used due to export >>> regulations, so this can be quite a showstopper for broader adoption. >> >> I remember that being said, but I am skeptical. My understanding of US crypto export regulations is that merely using existing crypto facilities from the operating system or from separate components is not subject to export limitations. AES-CTR is in libcrypto which is widely available all over the world. I'm skeptical that there is any place in the world where you can easily use SHA1 HMAC but not AES-CTR. So if anyone wants to claim that use of AES-CTR would cause problems with export regulations, I would ask them to substantiate that claim. >> >> Even if the export considerations do turn out to be real, AES-CTR has better security properties and considerably better performance than HMAC. I don't think we should let the legal regime around crypto limit the quality of the protocol. > > Well, I understand your point, but it could be seen from a different angle : > some will think that it's not worth risking to limit WS adoption just because > we're trying to cover an issue that has been speculated might exist. For > instance, most low-level network equipment would not require any form of > encryption at all. If a NAT router requires support for AES in order to > be able to NAT addresses presented in the stream, it's very well possible > that the firm will need a license to address some countries. > > Also, you may be interested in the other experiment I have posted. In short, > we could make such a supposedly existing intermediary emit a request after > feeding it with several megs of data and a few tens of thousands of connection > attempts. In this context, AES-CTR will only require more bytes to be sent > (at most 16 GB). But there is no reason to think that an intermediary that is > broken enough to be able to spot a request after several megs of data is not > able anymore after several gigs. I think your conclusion here is wrong. AES-CTR does not repeat the key schedule on any fixed cycle, as I understand it. It generates a psuedorandom non-repeating keystream. Your analysis was for a repeating 160-bit mask. I'm not sure I am convinced by the rest of your analysis, but it doesn't apply to AES-CTR. > > So in the end, despite the better crypto properties for AES-CTR than HMAC, > whether they're basic XOR, HMAC or AES, they're addressing the same issues > and risks, at different costs to exploit the supposed issues and at different > implementation costs. Keep in mind that we're trying to address multiple threat models, and also to be robust against attacks we haven't thought of yet. It's definitely not the case that these different approaches are equivalent in all ways, even if it were true that they are equivalent for the "send a giant blow" attack. Regards, Maciej From metajack@gmail.com Sun Jan 9 12:22:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3643A67D4 for ; Sun, 9 Jan 2011 12:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejQ3Q22dDbjM for ; Sun, 9 Jan 2011 12:21:57 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8A7C73A6842 for ; Sun, 9 Jan 2011 12:21:57 -0800 (PST) Received: by bwz12 with SMTP id 12so18559808bwz.31 for ; Sun, 09 Jan 2011 12:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=TfpF7BNsxqnlmiuHyfBYoCJ3T9zZjiyDIbaxmCHiwjo=; b=QJQQJNjUD7OctJc5xwsO82+uECqrq4Uq3tFdTB1wMqxT6FRTze3HJ/CxoV0o/rruX0 9bNGHMqLh+xtA+kzqJKpjQTgtapvltbhHUxbXA0qEJdGt0o5KBjeYgWcHKp2qIP8k7ME KNNZSnprsG4cz/0IjhMIqPG1dGbP6nAz6Hzqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=NQNNhNDrTzLxDQ/wisGoZrJnxb8lbFWEmTNV6uh4i+bGdOAVrgqcZ5QYlszbTi/0Ad lcx0GB0j32urFblGW+nXRM/N1j1B+uF+hb85ETfw8YCvhh6KAl11VvGVqkvATilIWUcf Gnlzv3DCoF1JAp5R/ra+lB5YT2y/hsBsrwHik= MIME-Version: 1.0 Received: by 10.204.140.208 with SMTP id j16mr2642963bku.151.1294604648341; Sun, 09 Jan 2011 12:24:08 -0800 (PST) Sender: metajack@gmail.com Received: by 10.204.119.211 with HTTP; Sun, 9 Jan 2011 12:24:08 -0800 (PST) In-Reply-To: <24A9239F-68B2-4AA2-8B37-0AF5A2879DBC@apple.com> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> <24A9239F-68B2-4AA2-8B37-0AF5A2879DBC@apple.com> Date: Sun, 9 Jan 2011 13:24:08 -0700 X-Google-Sender-Auth: OXG-iy7K77buWZ1_-qzWUXD_MfE Message-ID: From: Jack Moffitt To: Maciej Stachowiak Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:22:04 -0000 > If the legal regime is being liberalized, then we definitely shouldn't cripple the protocol. I should have said before, but I agree with this point. The problem already exists for TLS and other protocols that are pretty critical, and I see no reason why WebSocket should make concessions for legal reasons in that context. jack. From w@1wt.eu Sun Jan 9 12:26:21 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7933A683D for ; Sun, 9 Jan 2011 12:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBA4Ud1G1tVy for ; Sun, 9 Jan 2011 12:26:19 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 4CD4B3A67D4 for ; Sun, 9 Jan 2011 12:26:19 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09KSR2C009675; Sun, 9 Jan 2011 21:28:27 +0100 Date: Sun, 9 Jan 2011 21:28:27 +0100 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20110109202827.GS5743@1wt.eu> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> <20110109200346.GR5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:26:21 -0000 On Sun, Jan 09, 2011 at 12:22:22PM -0800, Maciej Stachowiak wrote: > I think your conclusion here is wrong. AES-CTR does not repeat the key > schedule on any fixed cycle, as I understand it. I've never said that. The fact that it *does not* repeat the key precisely is what makes it harder to get the expected pattern. > It generates a psuedorandom non-repeating keystream. Exactly. And in a pseudorandom keystream, a given 32-bit pattern will appear once in 16GB, and could appear once in a cleaverly built 4GB stream too. > Your analysis was for a repeating 160-bit mask. I'm not sure I > am convinced by the rest of your analysis, but it doesn't apply > to AES-CTR. The program does not appear to AES-CTR, but the base of the analysis definitely does : we can get a parsable HTTP request that at least one known intermediary is able to process in 2^32 32-bit patterns. Regards, Willy From mjs@apple.com Sun Jan 9 12:32:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9F63A684B for ; Sun, 9 Jan 2011 12:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBox9n4f4eZG for ; Sun, 9 Jan 2011 12:32:27 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 88F493A684A for ; Sun, 9 Jan 2011 12:32:27 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 79D02C5E7BA2 for ; Sun, 9 Jan 2011 12:34:39 -0800 (PST) X-AuditID: 11807134-b7cfdae000001831-df-4d2a1bdf7c93 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id 6F.6A.06193.FDB1A2D4; Sun, 9 Jan 2011 12:34:39 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.153.103.151] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LER00L49VTP6250@et.apple.com> for hybi@ietf.org; Sun, 09 Jan 2011 12:34:39 -0800 (PST) From: Maciej Stachowiak In-reply-to: <20110109202827.GS5743@1wt.eu> Date: Sun, 09 Jan 2011 12:34:37 -0800 Message-id: References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> <20110109200346.GR5743@1wt.eu> <20110109202827.GS5743@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:32:28 -0000 On Jan 9, 2011, at 12:28 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 12:22:22PM -0800, Maciej Stachowiak wrote: >> I think your conclusion here is wrong. AES-CTR does not repeat the key >> schedule on any fixed cycle, as I understand it. > > I've never said that. The fact that it *does not* repeat the key > precisely is what makes it harder to get the expected pattern. > >> It generates a psuedorandom non-repeating keystream. > > Exactly. And in a pseudorandom keystream, a given 32-bit pattern > will appear once in 16GB, and could appear once in a cleaverly > built 4GB stream too. There's no way to guarantee that a chosen 32-bit pattern will appear anywhere in AES-CTR output for an attacker-controlled input. It could appear 0 times, no matter what the input is. So your claim is false. Regards, Maciej From w@1wt.eu Sun Jan 9 12:49:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924713A6845 for ; Sun, 9 Jan 2011 12:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6AtiV81-m2s for ; Sun, 9 Jan 2011 12:49:55 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 73E1C3A6814 for ; Sun, 9 Jan 2011 12:49:54 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09Kq2QH009718; Sun, 9 Jan 2011 21:52:02 +0100 Date: Sun, 9 Jan 2011 21:52:02 +0100 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20110109205202.GT5743@1wt.eu> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> <20110109200346.GR5743@1wt.eu> <20110109202827.GS5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:49:56 -0000 On Sun, Jan 09, 2011 at 12:34:37PM -0800, Maciej Stachowiak wrote: > > On Jan 9, 2011, at 12:28 PM, Willy Tarreau wrote: > > > On Sun, Jan 09, 2011 at 12:22:22PM -0800, Maciej Stachowiak wrote: > >> I think your conclusion here is wrong. AES-CTR does not repeat the key > >> schedule on any fixed cycle, as I understand it. > > > > I've never said that. The fact that it *does not* repeat the key > > precisely is what makes it harder to get the expected pattern. > > > >> It generates a psuedorandom non-repeating keystream. > > > > Exactly. And in a pseudorandom keystream, a given 32-bit pattern > > will appear once in 16GB, and could appear once in a cleaverly > > built 4GB stream too. > > There's no way to guarantee that a chosen 32-bit pattern will appear anywhere in AES-CTR output for an attacker-controlled input. It could appear 0 times, no matter what the input is. So your claim is false. That's the principle of randomness. A typical pseudo-random should make any pattern appear. Of course it is possible that it does not appear, but the probability to see the pattern at least once in a perfectly random series of 2^32 patterns is of 1-(1-1/(2^32))^(2^32) = 1-1/e = 63%. It's already 39% in half the patterns and becomes 86% in the double of the patterns. Regards, Willy From bruce@callenish.com Sun Jan 9 13:14:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6D928C0D8 for ; Sun, 9 Jan 2011 13:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MX6Sq4TE67D for ; Sun, 9 Jan 2011 13:14:07 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 581B128C0D0 for ; Sun, 9 Jan 2011 13:14:07 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pc2cc-0007F3-8e for hybi@ietf.org; Sun, 09 Jan 2011 13:16:18 -0800 Message-ID: <4D2A25A1.7010909@callenish.com> Date: Sun, 09 Jan 2011 13:16:17 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <4D28AE05.4070500@callenish.com> <4D28BD89.70704@warmcat.com> <4D28FD92.60803@callenish.com> <4D29A145.1080003@warmcat.com> In-Reply-To: <4D29A145.1080003@warmcat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 21:14:08 -0000 On 09/01/2011 3:51 AM, Andy Green wrote: > > Bruce, you are the guy who handwaved about "known vulnerability" on > the list so it is you I replied to on the list. > I did say that this is a known vulnerability. I did not say that it is a valid vulnerability to worry about. Whether it is or it isn't, I don't know and I don't care because what I think doesn't matter in this instance. I see a lot of people get frustrated on this list because they think that the point of the discussion is to present the best technical argument. It isn't. The point is to persuade other people about the best technical argument. And the people who ship web browsers have all said that they are not persuaded by the types of arguments you have presented. Andy, I can understand your frustration, but it isn't helping anything. The decision has been made via the straw poll to use masking in the protocol. Let's put this to rest now, please. From bruce@callenish.com Sun Jan 9 14:00:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E2A3A6850 for ; Sun, 9 Jan 2011 14:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbH1742ojK+E for ; Sun, 9 Jan 2011 14:00:26 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 960D73A67D4 for ; Sun, 9 Jan 2011 14:00:26 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pc3LR-0006dK-D1 for hybi@ietf.org; Sun, 09 Jan 2011 14:02:37 -0800 Message-ID: <4D2A307C.3080109@callenish.com> Date: Sun, 09 Jan 2011 14:02:36 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <4D28DF6E.4080003@callenish.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 22:00:28 -0000 Thanks for the correction, but I still don't understand. If you are suggesting your mask for the wss: scheme in order to provide for a stream of apparent random bits on the wire, then that makes perfect sense. But for the purposely less-secure unencrypted ws: scheme I don't understand why it would be necessary. On 08/01/2011 4:00 PM, Eric Rescorla wrote: > On Sat, Jan 8, 2011 at 2:04 PM, Bruce Atherton wrote: >> On 07/01/2011 1:19 PM, Eric Rescorla wrote: >>> My objective is to make the bits that appear on the wire indistinguishable >>> from random >>> from the attacker's perspective. I think it's clear that this is the >>> strongest form of masking >>> available, and the method I proposed does that. >> It is true that your goal is clear, but I don't understand why you think >> this goal is necessary. >> >> The specification already allows for two forms of Websocket, a simple one >> denoted by the scheme "ws:" and a secure one denoted with "wss:". The latter >> one will have the random byte stream characteristics you are interested in. >> If you are uncomfortable with any other kind of stream, make sure your >> client only supports secure Websockets. > Regrettably, this is not the case except for certain specific ciphers > (in particular > block cipher in CBC mode.) It's not at all the case for RC4 and only > the case for > some CTR mode implementations. > > Best, > -Ekr From ekr@rtfm.com Sun Jan 9 14:14:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9EC3A6835 for ; Sun, 9 Jan 2011 14:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy9LgZD1Iwh5 for ; Sun, 9 Jan 2011 14:14:43 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 91F0F3A67D4 for ; Sun, 9 Jan 2011 14:14:43 -0800 (PST) Received: by gyd12 with SMTP id 12so8049621gyd.31 for ; Sun, 09 Jan 2011 14:16:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.67.10 with SMTP id u10mr5414017agk.187.1294611413266; Sun, 09 Jan 2011 14:16:53 -0800 (PST) Received: by 10.90.154.19 with HTTP; Sun, 9 Jan 2011 14:16:53 -0800 (PST) In-Reply-To: <4D2A307C.3080109@callenish.com> References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <4D28DF6E.4080003@callenish.com> <4D2A307C.3080109@callenish.com> Date: Sun, 9 Jan 2011 14:16:53 -0800 Message-ID: From: Eric Rescorla To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 22:14:44 -0000 On Sun, Jan 9, 2011 at 2:02 PM, Bruce Atherton wrote: > Thanks for the correction, but I still don't understand. > > If you are suggesting your mask for the wss: scheme in order to provide f= or > a stream of apparent random bits on the wire, then that makes perfect sen= se. > But for the purposely less-secure unencrypted ws: scheme I don't understa= nd > why it would be necessary. It's not a matter of random versus non-random. RC4 and AES-CTR without rand= om IV (which is not a requirement of the standard) provide the attacker with complete control over the payload bits on the wire, beause he can predict the keystream. -Ekr > On 08/01/2011 4:00 PM, Eric Rescorla wrote: >> >> On Sat, Jan 8, 2011 at 2:04 PM, Bruce Atherton >> =A0wrote: >>> >>> On 07/01/2011 1:19 PM, Eric Rescorla wrote: >>>> >>>> My objective is to make the bits that appear on the wire >>>> indistinguishable >>>> from random >>>> from the attacker's perspective. I think it's clear that this is the >>>> strongest form of masking >>>> available, and the method I proposed does that. >>> >>> It is true that your goal is clear, but I don't understand why you thin= k >>> this goal is necessary. >>> >>> The specification already allows for two forms of Websocket, a simple o= ne >>> denoted by the scheme "ws:" and a secure one denoted with "wss:". The >>> latter >>> one will have the random byte stream characteristics you are interested >>> in. >>> If you are uncomfortable with any other kind of stream, make sure your >>> client only supports secure Websockets. >> >> Regrettably, this is not the case except for certain specific ciphers >> (in particular >> block cipher in CBC mode.) It's not at all the case for RC4 and only >> the case for >> some CTR mode implementations. >> >> Best, >> -Ekr > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From ietf@adambarth.com Sun Jan 9 14:20:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A94E3A6857 for ; Sun, 9 Jan 2011 14:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.943 X-Spam-Level: X-Spam-Status: No, score=-3.943 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrt8+PPS4hum for ; Sun, 9 Jan 2011 14:20:07 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id E88A93A6835 for ; Sun, 9 Jan 2011 14:20:06 -0800 (PST) Received: by yxt33 with SMTP id 33so8274612yxt.31 for ; Sun, 09 Jan 2011 14:22:18 -0800 (PST) Received: by 10.150.57.14 with SMTP id f14mr2735010yba.45.1294611737503; Sun, 09 Jan 2011 14:22:17 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id v8sm16720689yhg.40.2011.01.09.14.22.15 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 14:22:15 -0800 (PST) Received: by iyi42 with SMTP id 42so18850239iyi.31 for ; Sun, 09 Jan 2011 14:22:14 -0800 (PST) Received: by 10.231.156.1 with SMTP id u1mr11739045ibw.52.1294611734538; Sun, 09 Jan 2011 14:22:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 14:21:44 -0800 (PST) From: Adam Barth Date: Sun, 9 Jan 2011 14:21:44 -0800 Message-ID: To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 22:20:08 -0000 Gentle people of hybi, There's been a lot of good discussion in this working group gathering consensus around the data framing and the handshake. At some point we need to declare victory and ship the protocol, otherwise proprietary solutions will continue to eat our lunch. I've written up a more formal version of Pat's proposal based on the recent straw poll and subsequent discussion. This protocol is by no means perfect, but it's good enough: http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt As a working group, it's time to ship. Kind regards, Adam From w@1wt.eu Sun Jan 9 14:40:25 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C26C3A6835 for ; Sun, 9 Jan 2011 14:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leg0XeIQtwt4 for ; Sun, 9 Jan 2011 14:40:23 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id DC0A23A67D4 for ; Sun, 9 Jan 2011 14:40:22 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09MgSZP010131; Sun, 9 Jan 2011 23:42:28 +0100 Date: Sun, 9 Jan 2011 23:42:28 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20110109224228.GU5743@1wt.eu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 22:40:25 -0000 Hello Adam, On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth wrote: > Gentle people of hybi, > > There's been a lot of good discussion in this working group gathering > consensus around the data framing and the handshake. At some point we > need to declare victory and ship the protocol, otherwise proprietary > solutions will continue to eat our lunch. > > I've written up a more formal version of Pat's proposal based on the > recent straw poll and subsequent discussion. This protocol is by no > means perfect, but it's good enough: > > http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt It would help a lot other WG participants if you could present suggestions, ideas and changes instead of a full proposal. It's hard to spot the proposed changes. At first glance, I'm noticing a few things : - you're using the OPTIONS method. The WG's consensus was voted as using GET. While technically working, OPTIONS limits some possibilities since no path is sent to the server. - your proposal involves AES-128-CTR. As was discussed here, it seems there are still export regulations for certain countries eventhough they're apparently fading out. It could still be a problem for companies who want to export products to some countries and which never had to put crypto in them. - several people on the list asked for the ability to be able to disable the masking in some well-controlled environments (eg: server-to-server communications). I see no provisions for this. - it has not yet been stated whether only the payload or also the framing should be masked. Your proposal masks both, which means that it definitely blocks any possibility of performing multiplexing later. There does not appear to have been a consensus in this area yet. - is was suggested that some (all ?) of the nonces could go away if masking is used. Surely this is something that needs to be rechecked. - Greg proposed to replace the MORE bit with a FIN bit so that the first hello frame from the server starts with a high bit set, thus ensuring that we can break the connection on non-HTTP compliant intermediaries which would expect a second response after the 101. Those are just a few notes, it's really not easy to changes :-/ Thanks for this work, Willy > > As a working group, it's time to ship. > > Kind regards, > Adam > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From ietf@adambarth.com Sun Jan 9 14:47:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57753A6842 for ; Sun, 9 Jan 2011 14:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.936 X-Spam-Level: X-Spam-Status: No, score=-3.936 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOnhL5EVgzq8 for ; Sun, 9 Jan 2011 14:47:32 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id CF5A53A67D4 for ; Sun, 9 Jan 2011 14:47:31 -0800 (PST) Received: by yie19 with SMTP id 19so6001271yie.31 for ; Sun, 09 Jan 2011 14:49:43 -0800 (PST) Received: by 10.236.108.41 with SMTP id p29mr5850522yhg.54.1294613383075; Sun, 09 Jan 2011 14:49:43 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id x62sm3488129yhc.30.2011.01.09.14.49.41 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 14:49:41 -0800 (PST) Received: by iwn40 with SMTP id 40so19932580iwn.31 for ; Sun, 09 Jan 2011 14:49:40 -0800 (PST) Received: by 10.231.199.12 with SMTP id eq12mr28120350ibb.2.1294613380638; Sun, 09 Jan 2011 14:49:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 14:49:10 -0800 (PST) In-Reply-To: <20110109224228.GU5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> From: Adam Barth Date: Sun, 9 Jan 2011 14:49:10 -0800 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 22:47:32 -0000 On Sun, Jan 9, 2011 at 2:42 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth wrote: >> Gentle people of hybi, >> >> There's been a lot of good discussion in this working group gathering >> consensus around the data framing and the handshake. =A0At some point we >> need to declare victory and ship the protocol, otherwise proprietary >> solutions will continue to eat our lunch. >> >> I've written up a more formal version of Pat's proposal based on the >> recent straw poll and subsequent discussion. =A0This protocol is by no >> means perfect, but it's good enough: >> >> http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt > > It would help a lot other WG participants if you could present suggestion= s, > ideas and changes instead of a full proposal. It's hard to spot the propo= sed > changes. We've had plenty of suggestions, ideas, and changes. It's time to ship. > At first glance, I'm noticing a few things : > > =A0- you're using the OPTIONS method. The WG's consensus was voted as usi= ng > =A0 =A0GET. While technically working, OPTIONS limits some possibilities = since > =A0 =A0no path is sent to the server. Be that as it may. OPTIONS is good enough. > =A0- your proposal involves AES-128-CTR. As was discussed here, it seems = there > =A0 =A0are still export regulations for certain countries eventhough they= 're > =A0 =A0apparently fading out. It could still be a problem for companies w= ho want > =A0 =A0to export products to some countries and which never had to put cr= ypto in > =A0 =A0them. Frankly, the export restriction issue is a bunch of BS. AES-128-CTR is good enough. > =A0- several people on the list asked for the ability to be able to disab= le > =A0 =A0the masking in some well-controlled environments (eg: server-to-se= rver > =A0 =A0communications). I see no provisions for this. The protocol is good enough without this added flexibility. If we find this is really important, we can add this ability in a future version of the protocol. > =A0- it has not yet been stated whether only the payload or also the fram= ing > =A0 =A0should be masked. Your proposal masks both, which means that it de= finitely > =A0 =A0blocks any possibility of performing multiplexing later. There doe= s not > =A0 =A0appear to have been a consensus in this area yet. The protocol is good enough without this added flexibility. If we find this is really important, we can add this ability in a future version of the protocol. > =A0- is was suggested that some (all ?) of the nonces could go away if ma= sking > =A0 =A0is used. Surely this is something that needs to be rechecked. I have checked this issue. Each nonce in the protocol serves a specific purpose and is valuable. > =A0- Greg proposed to replace the MORE bit with a FIN bit so that the fir= st > =A0 =A0hello frame from the server starts with a high bit set, thus ensur= ing > =A0 =A0that we can break the connection on non-HTTP compliant intermediar= ies > =A0 =A0which would expect a second response after the 101. The protocol is good enough without this change. The masking has us covered here. >> As a working group, it's time to ship. Kind regards, Adam From w@1wt.eu Sun Jan 9 15:00:20 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810253A6835 for ; Sun, 9 Jan 2011 15:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCvLVGudHlNE for ; Sun, 9 Jan 2011 15:00:19 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 91E8D3A67D4 for ; Sun, 9 Jan 2011 15:00:18 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09N2TMf010193; Mon, 10 Jan 2011 00:02:29 +0100 Date: Mon, 10 Jan 2011 00:02:29 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20110109230229.GX5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:00:20 -0000 On Sun, Jan 09, 2011 at 02:49:10PM -0800, Adam Barth wrote: > On Sun, Jan 9, 2011 at 2:42 PM, Willy Tarreau wrote: > > On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth wrote: > >> Gentle people of hybi, > >> > >> There's been a lot of good discussion in this working group gathering > >> consensus around the data framing and the handshake.  At some point we > >> need to declare victory and ship the protocol, otherwise proprietary > >> solutions will continue to eat our lunch. > >> > >> I've written up a more formal version of Pat's proposal based on the > >> recent straw poll and subsequent discussion.  This protocol is by no > >> means perfect, but it's good enough: > >> > >> http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt > > > > It would help a lot other WG participants if you could present suggestions, > > ideas and changes instead of a full proposal. It's hard to spot the proposed > > changes. > > We've had plenty of suggestions, ideas, and changes. It's time to ship. Yesterday, Sal said that there were a number of points to discuss yet, why this sudden hurry ? > > At first glance, I'm noticing a few things : > > > >  - you're using the OPTIONS method. The WG's consensus was voted as using > >    GET. While technically working, OPTIONS limits some possibilities since > >    no path is sent to the server. > > Be that as it may. OPTIONS is good enough. But on what basis are you trying to change what was adopted as a consensus ? I mean, I *know* that OPTIONS can evict more broken intermediaries than GET, but the participants here have been working on the GET hypothesis with its capabilities. Noone has had the opportunity to talk about their expectations and the implications such a change would have for them. > >  - your proposal involves AES-128-CTR. As was discussed here, it seems there > >    are still export regulations for certain countries eventhough they're > >    apparently fading out. It could still be a problem for companies who want > >    to export products to some countries and which never had to put crypto in > >    them. > > Frankly, the export restriction issue is a bunch of BS. AES-128-CTR > is good enough. Good enough for what purpose precisely ? HTTP Upgrade is good enough for Websocket without even any form of masking. Masking was added to address specific issues that aren't precisely quantified. > >  - several people on the list asked for the ability to be able to disable > >    the masking in some well-controlled environments (eg: server-to-server > >    communications). I see no provisions for this. > > The protocol is good enough without this added flexibility. If we > find this is really important, we can add this ability in a future > version of the protocol. No, it will be too late because it will never be possible to mix masked and non-masked frames later since there will be no way to distinguish them. > >  - it has not yet been stated whether only the payload or also the framing > >    should be masked. Your proposal masks both, which means that it definitely > >    blocks any possibility of performing multiplexing later. There does not > >    appear to have been a consensus in this area yet. > > The protocol is good enough without this added flexibility. If we > find this is really important, we can add this ability in a future > version of the protocol. Adam, please I can understand that you're in a hurry, but you have copy-pasted exactly the same response as to the question above. I would have found it more polite to respond later when you have more time. > >  - is was suggested that some (all ?) of the nonces could go away if masking > >    is used. Surely this is something that needs to be rechecked. > > I have checked this issue. Each nonce in the protocol serves a > specific purpose and is valuable. Then would you please take care of explaining them to us in this context when you have more time ? > >  - Greg proposed to replace the MORE bit with a FIN bit so that the first > >    hello frame from the server starts with a high bit set, thus ensuring > >    that we can break the connection on non-HTTP compliant intermediaries > >    which would expect a second response after the 101. > > The protocol is good enough without this change. The masking has us > covered here. No, I'm talking about the ability to ensure that a non-compliant intermediary will fail early instead of remaining stuck waiting for the server to talk. That once one of Hixie's major concerns and one of the reasons for the Hello frames suggestion. Regards, Willy From mjs@apple.com Sun Jan 9 15:04:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705A63A6807 for ; Sun, 9 Jan 2011 15:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6ubwYetJVVm for ; Sun, 9 Jan 2011 15:04:01 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 77C5A3A67D4 for ; Sun, 9 Jan 2011 15:04:01 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id A3FB0C5EC7BE for ; Sun, 9 Jan 2011 15:06:13 -0800 (PST) X-AuditID: 11807136-b7bf8ae00000244a-01-4d2a3f650d11 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay15.apple.com (Apple SCV relay) with SMTP id 98.DA.09290.56F3A2D4; Sun, 9 Jan 2011 15:06:13 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_f8Aurbcq16zgdca0xP/+aQ)" Received: from [10.0.1.14] ([24.6.209.6]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LES003MZ2UC1T00@et.apple.com> for hybi@ietf.org; Sun, 09 Jan 2011 15:06:13 -0800 (PST) From: Maciej Stachowiak In-reply-to: <20110109230229.GX5743@1wt.eu> Date: Sun, 09 Jan 2011 15:06:12 -0800 Message-id: <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: Hybi Subject: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:04:02 -0000 --Boundary_(ID_f8Aurbcq16zgdca0xP/+aQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT On Jan 9, 2011, at 3:02 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 02:49:10PM -0800, Adam Barth wrote: >> On Sun, Jan 9, 2011 at 2:42 PM, Willy Tarreau wrote: >>> On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth wrote: >>>> > >>> At first glance, I'm noticing a few things : >>> >>> - you're using the OPTIONS method. The WG's consensus was voted as using >>> GET. While technically working, OPTIONS limits some possibilities since >>> no path is sent to the server. >> >> Be that as it may. OPTIONS is good enough. > > But on what basis are you trying to change what was adopted as a consensus ? > I mean, I *know* that OPTIONS can evict more broken intermediaries than GET, > but the participants here have been working on the GET hypothesis with its > capabilities. Noone has had the opportunity to talk about their expectations > and the implications such a change would have for them. Now seems like a fine time to discuss OPTIONS. What are the pros and cons? It seems to avoid the HTTP compliance issues that CONNECT had, at least. Regards, Maciej --Boundary_(ID_f8Aurbcq16zgdca0xP/+aQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable
On Sun, Jan 09, 2011 at 02:49:10PM -0800, Adam Barth = wrote:
On Sun, Jan 9, 2011 at 2:42 PM, = Willy Tarreau <w@1wt.eu> = wrote:
On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth = wrote:


At first = glance, I'm noticing a few things = :

 - you're using the OPTIONS = method. The WG's consensus was voted as = using
   GET. While technically working, OPTIONS = limits some possibilities since
   no path is sent to = the server.

Be that as it = may.  OPTIONS is good enough.

But on what basis = are you trying to change what was adopted as a consensus ?
I mean, I = *know* that OPTIONS can evict more broken intermediaries than = GET,
but the participants here have been working on the GET = hypothesis with its
capabilities. Noone has had the opportunity to = talk about their expectations
and the implications such a change = would have for them.

Now seems = like a fine time to discuss OPTIONS. What are the pros and cons? It = seems to avoid the HTTP compliance issues that CONNECT had, at = least.

Regards,
Maciej

= --Boundary_(ID_f8Aurbcq16zgdca0xP/+aQ)-- From ietf@adambarth.com Sun Jan 9 15:07:49 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076CC3A6853 for ; Sun, 9 Jan 2011 15:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.93 X-Spam-Level: X-Spam-Status: No, score=-3.93 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwdYjvjcAEna for ; Sun, 9 Jan 2011 15:07:48 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 199D93A6835 for ; Sun, 9 Jan 2011 15:07:47 -0800 (PST) Received: by qyj19 with SMTP id 19so20374254qyj.10 for ; Sun, 09 Jan 2011 15:09:59 -0800 (PST) Received: by 10.224.36.202 with SMTP id u10mr16770444qad.316.1294614599633; Sun, 09 Jan 2011 15:09:59 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id q12sm16962346qcu.6.2011.01.09.15.09.57 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 15:09:58 -0800 (PST) Received: by iwn40 with SMTP id 40so19940906iwn.31 for ; Sun, 09 Jan 2011 15:09:57 -0800 (PST) Received: by 10.231.12.132 with SMTP id x4mr3604117ibx.177.1294614596936; Sun, 09 Jan 2011 15:09:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 15:09:26 -0800 (PST) In-Reply-To: <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> From: Adam Barth Date: Sun, 9 Jan 2011 15:09:26 -0800 Message-ID: To: Maciej Stachowiak Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:07:49 -0000 On Sun, Jan 9, 2011 at 3:06 PM, Maciej Stachowiak wrote: > > On Jan 9, 2011, at 3:02 PM, Willy Tarreau wrote: > > On Sun, Jan 09, 2011 at 02:49:10PM -0800, Adam Barth wrote: > > On Sun, Jan 9, 2011 at 2:42 PM, Willy Tarreau wrote: > > On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth wrote: > > > At first glance, I'm noticing a few things : > > =A0- you're using the OPTIONS method. The WG's consensus was voted as usi= ng > > =A0 =A0GET. While technically working, OPTIONS limits some possibilities = since > > =A0 =A0no path is sent to the server. > > Be that as it may. =A0OPTIONS is good enough. > > But on what basis are you trying to change what was adopted as a consensu= s ? > I mean, I *know* that OPTIONS can evict more broken intermediaries than G= ET, > but the participants here have been working on the GET hypothesis with it= s > capabilities. Noone has had the opportunity to talk about their expectati= ons > and the implications such a change would have for them. > > Now seems like a fine time to discuss OPTIONS. What are the pros and cons= ? > It seems to avoid the HTTP compliance issues that CONNECT had, at least. Whether we use OPTIONS or GET is much less than 1% of the value proposition of the WebSockets protocol. Rather than optimizing that part of the protocol, it's more important to pick something and go with it. Honestly, I picked OPTIONS because it was the example given in http://www.ietf.org/rfc/rfc2817.txt. Adam From mjs@apple.com Sun Jan 9 15:07:59 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A562A28C0D7 for ; Sun, 9 Jan 2011 15:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOIJjRVY0qvD for ; Sun, 9 Jan 2011 15:07:58 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 501BC3A6835 for ; Sun, 9 Jan 2011 15:07:58 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 8C6C1C5EC9FF for ; Sun, 9 Jan 2011 15:10:10 -0800 (PST) X-AuditID: 1180711d-b7c30ae0000055b4-00-4d2a4052b439 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id 25.D3.21940.2504A2D4; Sun, 9 Jan 2011 15:10:10 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3eE6kIbJB8Q1pmJQvMOI2Q)" Received: from [10.0.1.14] ([24.6.209.6]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LES00KUO30XC240@elliott.apple.com> for hybi@ietf.org; Sun, 09 Jan 2011 15:10:10 -0800 (PST) From: Maciej Stachowiak In-reply-to: <20110109230229.GX5743@1wt.eu> Date: Sun, 09 Jan 2011 15:10:09 -0800 Message-id: <6F2780F7-D603-46D6-B737-8B085AF32B2C@apple.com> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: Hybi Subject: [hybi] HELLO frames (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:07:59 -0000 --Boundary_(ID_3eE6kIbJB8Q1pmJQvMOI2Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT On Jan 9, 2011, at 3:02 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 02:49:10PM -0800, Adam Barth wrote: > >>> - Greg proposed to replace the MORE bit with a FIN bit so that the first >>> hello frame from the server starts with a high bit set, thus ensuring >>> that we can break the connection on non-HTTP compliant intermediaries >>> which would expect a second response after the 101. >> >> The protocol is good enough without this change. The masking has us >> covered here. > > No, I'm talking about the ability to ensure that a non-compliant intermediary > will fail early instead of remaining stuck waiting for the server to talk. > That once one of Hixie's major concerns and one of the reasons for the Hello > frames suggestion. Is there any evidence that either client-->server or sever-->client HELLO frames would reduce the rate of apparent successful connections that later fail in real-world deployment? If so, we can consider adding them on their own merits. Regards, Maciej --Boundary_(ID_3eE6kIbJB8Q1pmJQvMOI2Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable
On Sun, Jan 09, 2011 at 02:49:10PM -0800, Adam Barth = wrote:

 - Greg proposed to replace the MORE bit with a FIN = bit so that the first
   hello frame from = the server starts with a high bit set, thus = ensuring
   that we can break = the connection on non-HTTP compliant = intermediaries
   which would expect = a second response after the = 101.

The protocol is = good enough without this change.  The masking has = us
covered = here.

No, I'm talking about the ability to ensure = that a non-compliant intermediary
will fail early instead of = remaining stuck waiting for the server to talk.
That once one of = Hixie's major concerns and one of the reasons for the Hello
frames = suggestion.

Is there any evidence = that either client-->server or sever-->client HELLO frames would = reduce the rate of apparent successful connections that later fail in = real-world deployment? If so, we can consider adding them on their own = merits.

Regards,
Maciej
= --Boundary_(ID_3eE6kIbJB8Q1pmJQvMOI2Q)-- From ietf@adambarth.com Sun Jan 9 15:10:14 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3959328C0D7 for ; Sun, 9 Jan 2011 15:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.923 X-Spam-Level: X-Spam-Status: No, score=-3.923 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 310Qf+dKt1Qm for ; Sun, 9 Jan 2011 15:10:13 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 4B7013A6853 for ; Sun, 9 Jan 2011 15:10:13 -0800 (PST) Received: by qyj19 with SMTP id 19so20375267qyj.10 for ; Sun, 09 Jan 2011 15:12:25 -0800 (PST) Received: by 10.229.94.143 with SMTP id z15mr24041176qcm.282.1294614745068; Sun, 09 Jan 2011 15:12:25 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id t7sm15819499qcs.28.2011.01.09.15.12.23 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 15:12:23 -0800 (PST) Received: by iyi42 with SMTP id 42so18871669iyi.31 for ; Sun, 09 Jan 2011 15:12:22 -0800 (PST) Received: by 10.231.192.7 with SMTP id do7mr5852513ibb.102.1294614742619; Sun, 09 Jan 2011 15:12:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 15:11:52 -0800 (PST) In-Reply-To: <20110109230229.GX5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> From: Adam Barth Date: Sun, 9 Jan 2011 15:11:52 -0800 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:10:14 -0000 On Sun, Jan 9, 2011 at 3:02 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 02:49:10PM -0800, Adam Barth wrote: >> We've had plenty of suggestions, ideas, and changes. =A0It's time to shi= p. > > Yesterday, Sal said that there were a number of points to discuss yet, wh= y > this sudden hurry ? There is no sudden hurry. WebSockets have already been delayed far too long. It's time to ship. Adam From mjs@apple.com Sun Jan 9 15:10:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C77128C0E1 for ; Sun, 9 Jan 2011 15:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpkj9rnup7Jq for ; Sun, 9 Jan 2011 15:10:35 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 9D45A3A6853 for ; Sun, 9 Jan 2011 15:10:33 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id C97F5C5EDCF6 for ; Sun, 9 Jan 2011 15:12:45 -0800 (PST) X-AuditID: 1180711d-b7c30ae0000055b4-ca-4d2a40ed2ccf Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay13.apple.com (Apple SCV relay) with SMTP id 7B.05.21940.DE04A2D4; Sun, 9 Jan 2011 15:12:45 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.0.1.14] ([24.6.209.6]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LES00KWX358C240@elliott.apple.com> for hybi@ietf.org; Sun, 09 Jan 2011 15:12:45 -0800 (PST) From: Maciej Stachowiak In-reply-to: Date: Sun, 09 Jan 2011 15:12:44 -0800 Message-id: References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> To: Adam Barth X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:10:36 -0000 On Jan 9, 2011, at 3:09 PM, Adam Barth wrote: > Whether we use OPTIONS or GET is much less than 1% of the value > proposition of the WebSockets protocol. Rather than optimizing that > part of the protocol, it's more important to pick something and go > with it. > > Honestly, I picked OPTIONS because it was the example given in > http://www.ietf.org/rfc/rfc2817.txt. I personally have no objections to OPTIONS. The reason for this side thread is so that anyone who has a concrete problem with OPTIONS can raise it now. I'm not aware of any such problems, but Willy said there might be some. I'm definitely into shipping soon, but it can't hurt to be informed. Regards, Maciej From w@1wt.eu Sun Jan 9 15:16:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030F23A6853 for ; Sun, 9 Jan 2011 15:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYfmMatqkHSi for ; Sun, 9 Jan 2011 15:16:08 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 16FCA3A6835 for ; Sun, 9 Jan 2011 15:16:02 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09NI8TT010275; Mon, 10 Jan 2011 00:18:08 +0100 Date: Mon, 10 Jan 2011 00:18:08 +0100 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20110109231808.GY5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:16:09 -0000 On Sun, Jan 09, 2011 at 03:06:12PM -0800, Maciej Stachowiak wrote: > > On Jan 9, 2011, at 3:02 PM, Willy Tarreau wrote: > > > On Sun, Jan 09, 2011 at 02:49:10PM -0800, Adam Barth wrote: > >> On Sun, Jan 9, 2011 at 2:42 PM, Willy Tarreau wrote: > >>> On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth wrote: > >>>> > > > >>> At first glance, I'm noticing a few things : > >>> > >>> - you're using the OPTIONS method. The WG's consensus was voted as using > >>> GET. While technically working, OPTIONS limits some possibilities since > >>> no path is sent to the server. > >> > >> Be that as it may. OPTIONS is good enough. > > > > But on what basis are you trying to change what was adopted as a consensus ? > > I mean, I *know* that OPTIONS can evict more broken intermediaries than GET, > > but the participants here have been working on the GET hypothesis with its > > capabilities. Noone has had the opportunity to talk about their expectations > > and the implications such a change would have for them. > > Now seems like a fine time to discuss OPTIONS. What are the pros and cons? It seems to avoid the HTTP compliance issues that CONNECT had, at least. Yes, OPTIONS+101 is equivalent for servers to what CONNECT is for proxies. It has been evocated a bit in the past, but the discussion quickly ended and nobody gave his opinion. The pros is that some intermediaries unaware of the Upgrade mechanism will respond themselves with 405, 501 or 200 depending on whether they support it or not, which will cause a cleaner failure. The cons is that it removes the ability to use any form of path in the request, so you can only rely on the server name. Sure that's a lot better than relying on its IP address, but it might not fit everyone's use. I can live with it if required, as I've said several times in the last few months. However, you once expressed concerns on this point about the ability to forge OPTIONS requests using XMLHttpRequest (which I did not know were possible). The point is that it was said yesterday to one guy that once a consensus is achieved, it must not be revisited, and now we're doing exactly that :-/ Willy From w@1wt.eu Sun Jan 9 15:22:16 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169C53A6835 for ; Sun, 9 Jan 2011 15:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToKSimEaPKWd for ; Sun, 9 Jan 2011 15:22:14 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id ABC513A67D4 for ; Sun, 9 Jan 2011 15:22:13 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09NOMpX010289; Mon, 10 Jan 2011 00:24:22 +0100 Date: Mon, 10 Jan 2011 00:24:22 +0100 From: Willy Tarreau To: Maciej Stachowiak Message-ID: <20110109232422.GZ5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <6F2780F7-D603-46D6-B737-8B085AF32B2C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F2780F7-D603-46D6-B737-8B085AF32B2C@apple.com> User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] HELLO frames (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:22:16 -0000 On Sun, Jan 09, 2011 at 03:10:09PM -0800, Maciej Stachowiak wrote: > Is there any evidence that either client-->server or sever-->client HELLO frames would reduce the rate of apparent successful connections that later fail in real-world deployment? If so, we can consider adding them on their own merits. Yes, we had several examples in the past of intermediaries which don't know about the specifics of the 101 status code and which process it as 100, as the HTTP spec says that if you don't know how to handle code XYZ, you can handle it as X00. The problem is that 100 is an intermediate response, which indicates that another one will come after it. So the intermediary sends the headers to the client and waits for the server to talk, doing nothing else. Older versions of haproxy used to do that because I implemented the RFC as I had read it. It was only after joining the WG that I discovered the magics of 101. Apache does that too. But Apache takes OPTIONS requests for itself, so a GET+101 on apache will require a hello frame while an OPTIONS will immediately be rejected, so for this one it's irrelevant. In fact I'd be more worried about load balancers and content switches in general. They have to support 100 because of the very common "Expect: 100-Continue" that is present in many POST requests, and it's highly likely that they'll process 101 as a 100 just as haproxy did, because 101 was part of RFC2817 and not 2616. So yes, for this matter, the hello frames will really help quickly terminate connections through failed intermediaries instead of leaving them hanging. Regards, Willy From julian.reschke@gmx.de Sun Jan 9 15:37:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D6A3A6859 for ; Sun, 9 Jan 2011 15:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.442 X-Spam-Level: X-Spam-Status: No, score=-104.442 tagged_above=-999 required=5 tests=[AWL=-1.843, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAKEfv2Dg9BT for ; Sun, 9 Jan 2011 15:37:27 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 284103A6853 for ; Sun, 9 Jan 2011 15:37:26 -0800 (PST) Received: (qmail invoked by alias); 09 Jan 2011 23:39:36 -0000 Received: from p508FD146.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.209.70] by mail.gmx.net (mp018) with SMTP; 10 Jan 2011 00:39:36 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+N6Dkgd6KNCNbTwpOSuIgIJZo+g4fucfCZv65QkJ Rwj9K+sN0DSfXp Message-ID: <4D2A4738.2000500@gmx.de> Date: Mon, 10 Jan 2011 00:39:36 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adam Barth References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:37:28 -0000 On 10.01.2011 00:09, Adam Barth wrote: > ... > Whether we use OPTIONS or GET is much less than 1% of the value > proposition of the WebSockets protocol. Rather than optimizing that > part of the protocol, it's more important to pick something and go > with it. > > Honestly, I picked OPTIONS because it was the example given in > http://www.ietf.org/rfc/rfc2817.txt. > ... OPTIONS isn't special with respect to Upgrade. (*) My understanding is that the authors picked this example in order to avoid to let the server ignore the Upgrade request in GET, and then return the contents over an non-secured channel. Unless there's a specific reason why people think OPTIONS is better than GET here, we should stick with what was discussed before. Best regards, Julian (*) I may be wrong, in which case we should clarify this in HTTPbis. From julian.reschke@gmx.de Sun Jan 9 15:38:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78DD43A6853 for ; Sun, 9 Jan 2011 15:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.426 X-Spam-Level: X-Spam-Status: No, score=-104.426 tagged_above=-999 required=5 tests=[AWL=-1.827, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq2pbz2WeY3Q for ; Sun, 9 Jan 2011 15:38:34 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 50A8F3A6858 for ; Sun, 9 Jan 2011 15:38:34 -0800 (PST) Received: (qmail invoked by alias); 09 Jan 2011 23:40:45 -0000 Received: from p508FD146.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.209.70] by mail.gmx.net (mp071) with SMTP; 10 Jan 2011 00:40:45 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19xOmFHQH9xqoT0y8yZ9mjTRAa+c1Ni5fBV1yETM3 n9yHY46eQ2WAaG Message-ID: <4D2A477D.80406@gmx.de> Date: Mon, 10 Jan 2011 00:40:45 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> <20110109231808.GY5743@1wt.eu> In-Reply-To: <20110109231808.GY5743@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:38:35 -0000 On 10.01.2011 00:18, Willy Tarreau wrote: > ... > The cons is that it removes the ability to use any form of path in the > request, so you can only rely on the server name. Sure that's a lot better > than relying on its IP address, but it might not fit everyone's use. I can > live with it if required, as I've said several times in the last few months. > ... Hmmm? OPTIONS can have a path just like any other method. Best regards, Julian From julian.reschke@gmx.de Sun Jan 9 15:40:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21EB53A6853 for ; Sun, 9 Jan 2011 15:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.411 X-Spam-Level: X-Spam-Status: No, score=-104.411 tagged_above=-999 required=5 tests=[AWL=-1.812, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRmRnRrutW1R for ; Sun, 9 Jan 2011 15:40:22 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 3EFFE3A6858 for ; Sun, 9 Jan 2011 15:40:21 -0800 (PST) Received: (qmail invoked by alias); 09 Jan 2011 23:42:33 -0000 Received: from p508FD146.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.209.70] by mail.gmx.net (mp043) with SMTP; 10 Jan 2011 00:42:33 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX199n/NBnBt93wBWZ4SxlAwVBxGUxdepL3vDgZOo4B Dk2EiXWyqMifyb Message-ID: <4D2A47E9.3050604@gmx.de> Date: Mon, 10 Jan 2011 00:42:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <6F2780F7-D603-46D6-B737-8B085AF32B2C@apple.com> <20110109232422.GZ5743@1wt.eu> In-Reply-To: <20110109232422.GZ5743@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Hybi Subject: Re: [hybi] HELLO frames (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:40:24 -0000 On 10.01.2011 00:24, Willy Tarreau wrote: > ... > In fact I'd be more worried about load balancers and content switches > in general. They have to support 100 because of the very common > "Expect: 100-Continue" that is present in many POST requests, and it's > highly likely that they'll process 101 as a 100 just as haproxy did, > because 101 was part of RFC2817 and not 2616. > ... This is incorrect, see . Best regards, Julian From w@1wt.eu Sun Jan 9 15:42:06 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4DC28C0E9 for ; Sun, 9 Jan 2011 15:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MExsw3VAgJVV for ; Sun, 9 Jan 2011 15:42:05 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id E60A43A6853 for ; Sun, 9 Jan 2011 15:42:04 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09NiDIB010348; Mon, 10 Jan 2011 00:44:13 +0100 Date: Mon, 10 Jan 2011 00:44:13 +0100 From: Willy Tarreau To: Julian Reschke Message-ID: <20110109234413.GA5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> <20110109231808.GY5743@1wt.eu> <4D2A477D.80406@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D2A477D.80406@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:42:06 -0000 On Mon, Jan 10, 2011 at 12:40:45AM +0100, Julian Reschke wrote: > On 10.01.2011 00:18, Willy Tarreau wrote: > >... > >The cons is that it removes the ability to use any form of path in the > >request, so you can only rely on the server name. Sure that's a lot better > >than relying on its IP address, but it might not fit everyone's use. I can > >live with it if required, as I've said several times in the last few > >months. > > ... > > Hmmm? OPTIONS can have a path just like any other method. Oh yes Julian, you're making a good point, in fact I got fooled by the "OPTIONS *" request. Yes indeed, with a path OPTIONS becomes equivalent to GET and is forwarded. Regards, Willy From bruce@callenish.com Sun Jan 9 15:43:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBCE83A6859 for ; Sun, 9 Jan 2011 15:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af0PVZ6dyE39 for ; Sun, 9 Jan 2011 15:43:53 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 0FAB83A6853 for ; Sun, 9 Jan 2011 15:43:53 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pc4xY-0006vG-5l for hybi@ietf.org; Sun, 09 Jan 2011 15:46:04 -0800 Message-ID: <4D2A48BB.5020400@callenish.com> Date: Sun, 09 Jan 2011 15:46:03 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <4D28DF6E.4080003@callenish.com> <4D2A307C.3080109@callenish.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:43:54 -0000 I apologize if I am being thick, but I still don't understand. It is my understanding that the masking algorithms which have been previously suggested prevent the attacker from controlling the payload bits on the wire from within a browser using Websockets without the added burden of being cryptographically secure. I had thought that you were arguing that the attacker could still control patterns in the bits, but not the bits themselves. That seemed like a reasonable thing for the ws: scheme to allow, to me, since by design it is a lighter weight, less secure form of Websockets and there have never been any exploits that relied on that characteristic that anyone has mentioned so far. Now it sounds like you are arguing that an attacker can completely control the bits no matter what unless it is cryptographically secure. I'm sure I'm missing something, but I haven't a clue what it is. On 09/01/2011 2:16 PM, Eric Rescorla wrote: > It's not a matter of random versus non-random. RC4 and AES-CTR without random IV > (which is not a requirement of the standard) provide the attacker with > complete control over > the payload bits on the wire, beause he can predict the keystream. From w@1wt.eu Sun Jan 9 15:44:31 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422D83A6859 for ; Sun, 9 Jan 2011 15:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLCskKLFhxLW for ; Sun, 9 Jan 2011 15:44:30 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id DD57C3A6853 for ; Sun, 9 Jan 2011 15:44:29 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09NkcvB010382; Mon, 10 Jan 2011 00:46:38 +0100 Date: Mon, 10 Jan 2011 00:46:38 +0100 From: Willy Tarreau To: Julian Reschke Message-ID: <20110109234638.GB5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <6F2780F7-D603-46D6-B737-8B085AF32B2C@apple.com> <20110109232422.GZ5743@1wt.eu> <4D2A47E9.3050604@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D2A47E9.3050604@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] HELLO frames (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:44:31 -0000 On Mon, Jan 10, 2011 at 12:42:33AM +0100, Julian Reschke wrote: > On 10.01.2011 00:24, Willy Tarreau wrote: > >... > >In fact I'd be more worried about load balancers and content switches > >in general. They have to support 100 because of the very common > >"Expect: 100-Continue" that is present in many POST requests, and it's > >highly likely that they'll process 101 as a 100 just as haproxy did, > >because 101 was part of RFC2817 and not 2616. > >... > > This is incorrect, see > . OK, but that's not what I'd call a definition. It's just as little verbose as CONNECT, it lets one imagine it's just to use a new HTTP version. Both were given an example for the first time in 2817 in my opinion. Thanks for the reminder anyway ;-) Willy From julian.reschke@gmx.de Sun Jan 9 15:48:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E193C3A685A for ; Sun, 9 Jan 2011 15:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.396 X-Spam-Level: X-Spam-Status: No, score=-104.396 tagged_above=-999 required=5 tests=[AWL=-1.797, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIOs7TBrGuMo for ; Sun, 9 Jan 2011 15:48:01 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 665E73A6853 for ; Sun, 9 Jan 2011 15:48:00 -0800 (PST) Received: (qmail invoked by alias); 09 Jan 2011 23:50:12 -0000 Received: from p508FD146.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.209.70] by mail.gmx.net (mp040) with SMTP; 10 Jan 2011 00:50:12 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/uyOkqI3TuQFxvFm+i73BMCWRnI6AxqBos82cdgM g+eKYkWVPbKysb Message-ID: <4D2A49B4.8030809@gmx.de> Date: Mon, 10 Jan 2011 00:50:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <6F2780F7-D603-46D6-B737-8B085AF32B2C@apple.com> <20110109232422.GZ5743@1wt.eu> <4D2A47E9.3050604@gmx.de> <20110109234638.GB5743@1wt.eu> In-Reply-To: <20110109234638.GB5743@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Hybi Subject: Re: [hybi] HELLO frames (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:48:03 -0000 On 10.01.2011 00:46, Willy Tarreau wrote: > On Mon, Jan 10, 2011 at 12:42:33AM +0100, Julian Reschke wrote: >> On 10.01.2011 00:24, Willy Tarreau wrote: >>> ... >>> In fact I'd be more worried about load balancers and content switches >>> in general. They have to support 100 because of the very common >>> "Expect: 100-Continue" that is present in many POST requests, and it's >>> highly likely that they'll process 101 as a 100 just as haproxy did, >>> because 101 was part of RFC2817 and not 2616. >>> ... >> >> This is incorrect, see >> . > > OK, but that's not what I'd call a definition. It's just as little verbose > as CONNECT, it lets one imagine it's just to use a new HTTP version. Both > were given an example for the first time in 2817 in my opinion. Well, there's also the text in . So... we recently adopted language from 2817 into HTTPbis; could you please check that, and provide feedback to the WG if you feel we need to improve what we have? Best regards, Julian From w@1wt.eu Sun Jan 9 15:53:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811483A6859 for ; Sun, 9 Jan 2011 15:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74MtDm1H1NRq for ; Sun, 9 Jan 2011 15:53:38 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id AB9623A6853 for ; Sun, 9 Jan 2011 15:53:37 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p09NtjlG010437; Mon, 10 Jan 2011 00:55:45 +0100 Date: Mon, 10 Jan 2011 00:55:45 +0100 From: Willy Tarreau To: Julian Reschke Message-ID: <20110109235545.GC5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <6F2780F7-D603-46D6-B737-8B085AF32B2C@apple.com> <20110109232422.GZ5743@1wt.eu> <4D2A47E9.3050604@gmx.de> <20110109234638.GB5743@1wt.eu> <4D2A49B4.8030809@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D2A49B4.8030809@gmx.de> User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] HELLO frames (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 23:53:39 -0000 On Mon, Jan 10, 2011 at 12:50:12AM +0100, Julian Reschke wrote: > On 10.01.2011 00:46, Willy Tarreau wrote: > >On Mon, Jan 10, 2011 at 12:42:33AM +0100, Julian Reschke wrote: > >>On 10.01.2011 00:24, Willy Tarreau wrote: > >>>... > >>>In fact I'd be more worried about load balancers and content switches > >>>in general. They have to support 100 because of the very common > >>>"Expect: 100-Continue" that is present in many POST requests, and it's > >>>highly likely that they'll process 101 as a 100 just as haproxy did, > >>>because 101 was part of RFC2817 and not 2616. > >>>... > >> > >>This is incorrect, see > >>. > > > >OK, but that's not what I'd call a definition. It's just as little verbose > >as CONNECT, it lets one imagine it's just to use a new HTTP version. Both > >were given an example for the first time in 2817 in my opinion. > > Well, there's also the text in > . Yes I know, but the connection between 101 and Upgrade was not easy to establish. I discovered that particularity here with websocket for the first time after 10 years of everyday use of HTTP. > So... we recently adopted language from 2817 into HTTPbis; could you > please check that, and provide feedback to the WG if you feel we need to > improve what we have? I remember having checked that part in http-bis, as I was one of those asking for the merging of CONNECT and 101 into http-bis, and found it to be OK. I could recheck though. But it's always harder to spot things that are difficult to understand once you know them. I'd better ask someone else to indicate me if he understands how to use it. Cheers, Willy From w@1wt.eu Sun Jan 9 16:06:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C1D3A685A for ; Sun, 9 Jan 2011 16:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPlBteDzNpGY for ; Sun, 9 Jan 2011 16:06:57 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id B042A3A6853 for ; Sun, 9 Jan 2011 16:06:56 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A098DQ010460 for hybi@ietf.org; Mon, 10 Jan 2011 01:09:08 +0100 Date: Mon, 10 Jan 2011 01:09:08 +0100 From: Willy Tarreau To: Hybi Message-ID: <20110110000908.GD5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:06:58 -0000 I have reused Maciej's code for AES-128-CTR to make it emit a constant stream and look there for a supposedly processable request (which is valid since Apache processes it and transcodes it if it finds it at the beginning of the stream). willy@pcw:~/c$ time ./aes-128-ctr-get Found the 'GET\n' pattern on the wire after 1608425803 bytes real 0m20.761s user 0m20.761s sys 0m0.000s It requires the client to send more data, but here we're only at 1.6 GB, roughly just 1000 times more than with the basic XOR method. However, it's limited to 640 Mbps only. It means that using this as a mandatory masking method will not even allow me to use a memcache at gigabit speeds on my local network :-( Once again, I'm not saying that I'd believe that any intermediary would seek a request that far. Neither do I believe it would seek one after one megabyte nor after any non CRLF byte BTW. But we're proposing this method because other ones are not deemed sure enough. However, it does not either cover the issues which caused the other methods to be proposed. So now either we should conclude that using AES to prevent a request from popping up is acceptable because the risks are low, so it must be possible to disable it for some use cases, or we conclude that it's not usable and the only masking solution consists in never putting a CR/LF on the wire. But we have to make choices. We can't disable the protocol that way to fix a problem we finally don't fix. Regards, Willy From bruce@callenish.com Sun Jan 9 16:14:52 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96873A6853 for ; Sun, 9 Jan 2011 16:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VRiesJw4hW4 for ; Sun, 9 Jan 2011 16:14:51 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id E8BEA3A6833 for ; Sun, 9 Jan 2011 16:14:51 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pc5RW-0001Pl-Qz for hybi@ietf.org; Sun, 09 Jan 2011 16:17:03 -0800 Message-ID: <4D2A4FFE.6000503@callenish.com> Date: Sun, 09 Jan 2011 16:17:02 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: [hybi] Summary of issues concerning the default masking algorithm X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:14:52 -0000 Now that masking is officially going to be part of the protocol, I for one would find it useful to have all the concerns of the masking algorithm in one place to make it easier to reason about. I realize that much of this has already been discussed in various threads in all kinds of messages and that some (though I do not think all) consider the decisions on the algorithm pretty much made, but I think it would be easier to reason about and be certain we have consensus on them if the information could be gathered in a single thread. Here is my understanding of the current state of issues around the masking algorithm. Please feel free to correct me or add more information. The problems masking is intended to address are: 1) to prevent an attacker from using a browser to initiate a Websocket connection to a vulnerable intermediary or non-Websocket server that can be exploited by sending apparent HTTP or elements of other protocols in a Websocket frame and more controversially: 2) to prevent an attacker from using a browser to open a cross-site scripting HTTP connection that emulates a Websocket connection 3) to prevent potential unknown future attacks using a browser with a Websocket connection that can be avoided by disallowing an attacker's control of bits on the wire If there are other problems masking is seen as a solution for, please add them. Those are the ones I am aware of. The most basic masking suggestion I have seen is to provide a per-frame random mask that is sent with the frame and XORed with the contents. The features which have been suggested to enhance this scheme that I know of are: a) The client nonce should influence the mask b) The server nonce should influence the mask c) The mask should be kept off the wire by generating the mask using a shared secret - This means replacing the per-frame mask with a per-frame key used in generating the mask - the shared secret that has been suggested is a connection key generated from the client and server nonce, thus including features a and b d) The attacker should not only be prevented from controlling the bits, but also the pattern of bits Again there may be other features that have been suggested but those are the ones I am aware of. I'll leave it to the advocates of each of these features to summarize the benefits of them that justify their costs, as I don't think I could do justice to them. I can make a stab at the costs, though. For feature a, the only cost I can see is in the increase in complexity in generating the mask. For feature b, there is the increase in complexity in generating the mask as well as the fact that you can not send a payload with the initial handshake from the client because you do not yet have the server nonce. The principal cost of feature c that I can see is that it stops tools like wireshark from being able to decode streams. The cost of feature d is increased complexity in implementation and added computational cost. Feel free to add to or argue with any of these points. I've tried to state things as neutrally as I can. From ietf@adambarth.com Sun Jan 9 16:18:47 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207F23A6853 for ; Sun, 9 Jan 2011 16:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.916 X-Spam-Level: X-Spam-Status: No, score=-3.916 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCScN-Pp36L8 for ; Sun, 9 Jan 2011 16:18:46 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 34E5D3A6833 for ; Sun, 9 Jan 2011 16:18:46 -0800 (PST) Received: by gyd12 with SMTP id 12so8071823gyd.31 for ; Sun, 09 Jan 2011 16:20:58 -0800 (PST) Received: by 10.90.120.12 with SMTP id s12mr5565720agc.21.1294618857975; Sun, 09 Jan 2011 16:20:57 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id e44sm6829430yha.34.2011.01.09.16.20.56 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 16:20:57 -0800 (PST) Received: by iwn40 with SMTP id 40so19970843iwn.31 for ; Sun, 09 Jan 2011 16:20:55 -0800 (PST) Received: by 10.231.156.1 with SMTP id u1mr11822930ibw.52.1294618855778; Sun, 09 Jan 2011 16:20:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 16:20:25 -0800 (PST) In-Reply-To: <20110110000908.GD5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> From: Adam Barth Date: Sun, 9 Jan 2011 16:20:25 -0800 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:18:47 -0000 On Sun, Jan 9, 2011 at 4:09 PM, Willy Tarreau wrote: > I have reused Maciej's code for AES-128-CTR to make it emit a constant > stream and look there for a supposedly processable request (which is > valid since Apache processes it and transcodes it if it finds it at > the beginning of the stream). > > willy@pcw:~/c$ time ./aes-128-ctr-get > Found the 'GET\n' pattern on the wire after 1608425803 bytes > > real =A0 =A00m20.761s > user =A0 =A00m20.761s > sys =A0 =A0 0m0.000s > > It requires the client to send more data, but here we're only > at 1.6 GB, roughly just 1000 times more than with the basic XOR > method. > > However, it's limited to 640 Mbps only. It means that using this > as a mandatory masking method will not even allow me to use a > memcache at gigabit speeds on my local network :-( Then you shouldn't use WebSockets to talk to memcache on your local network. WebSockets is not the solution to every problem. For the important uses cases, 640 Mbps with today's CPUs is vastly more than enough. > Once again, I'm not saying that I'd believe that any intermediary > would seek a request that far. Neither do I believe it would seek > one after one megabyte nor after any non CRLF byte BTW. > > But we're proposing this method because other ones are not deemed > sure enough. However, it does not either cover the issues which > caused the other methods to be proposed. > > So now either we should conclude that using AES to prevent a request > from popping up is acceptable because the risks are low, so it must > be possible to disable it for some use cases, or we conclude that > it's not usable and the only masking solution consists in never > putting a CR/LF on the wire. The masking is not optional. If your use case doesn't work with masking, please a different protocol. Kind regards, Adam From gregw@intalio.com Sun Jan 9 16:21:55 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFDF3A6853 for ; Sun, 9 Jan 2011 16:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrphjqmE70gQ for ; Sun, 9 Jan 2011 16:21:54 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 123823A6833 for ; Sun, 9 Jan 2011 16:21:53 -0800 (PST) Received: by vws7 with SMTP id 7so7754484vws.31 for ; Sun, 09 Jan 2011 16:24:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.187.132 with SMTP id cw4mr5866880vcb.25.1294619045849; Sun, 09 Jan 2011 16:24:05 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 16:24:05 -0800 (PST) In-Reply-To: <4D2A4FFE.6000503@callenish.com> References: <4D2A4FFE.6000503@callenish.com> Date: Mon, 10 Jan 2011 01:24:05 +0100 X-Google-Sender-Auth: bgx5kQnJONX7PdB0dlLOmjz0EGY Message-ID: From: Greg Wilkins To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Summary of issues concerning the default masking algorithm X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:21:55 -0000 Bruce, there are also proposed features of: e) masking the framing as well as the payload. f) making masking use the current frame extension mechanism g) make masking be a negotiated extension (either to turn it on or off) From w@1wt.eu Sun Jan 9 16:23:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 036AA3A685A for ; Sun, 9 Jan 2011 16:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqj2xlv-is52 for ; Sun, 9 Jan 2011 16:23:26 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 567863A6833 for ; Sun, 9 Jan 2011 16:23:26 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A0PYuT010531; Mon, 10 Jan 2011 01:25:34 +0100 Date: Mon, 10 Jan 2011 01:25:33 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20110110002533.GE5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:23:28 -0000 On Sun, Jan 09, 2011 at 04:20:25PM -0800, Adam Barth wrote: > On Sun, Jan 9, 2011 at 4:09 PM, Willy Tarreau wrote: > > I have reused Maciej's code for AES-128-CTR to make it emit a constant > > stream and look there for a supposedly processable request (which is > > valid since Apache processes it and transcodes it if it finds it at > > the beginning of the stream). > > > > willy@pcw:~/c$ time ./aes-128-ctr-get > > Found the 'GET\n' pattern on the wire after 1608425803 bytes > > > > real    0m20.761s > > user    0m20.761s > > sys     0m0.000s > > > > It requires the client to send more data, but here we're only > > at 1.6 GB, roughly just 1000 times more than with the basic XOR > > method. > > > > However, it's limited to 640 Mbps only. It means that using this > > as a mandatory masking method will not even allow me to use a > > memcache at gigabit speeds on my local network :-( > > Then you shouldn't use WebSockets to talk to memcache on your local > network. WebSockets is not the solution to every problem. For the > important uses cases, 640 Mbps with today's CPUs is vastly more than > enough. But a frontal switch which has to process the frames in an internet infrastructure will require a crypto card to handle the non-secure version of websocket. Clearly that does not make much sense ! The same machine has no problem handling 10 Gbps of HTTP traffic. 640 Mbps of WS traffic for multi-megabytes frames is a very low performance in my opinion for a 3 GHz processor ! Any server is able to cope with that bandwidth for large frames. Regards, Willy From ietf@adambarth.com Sun Jan 9 16:29:55 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B613A6862 for ; Sun, 9 Jan 2011 16:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsMzdeGYk-95 for ; Sun, 9 Jan 2011 16:29:54 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 4FDF53A6855 for ; Sun, 9 Jan 2011 16:29:54 -0800 (PST) Received: by qyk34 with SMTP id 34so982856qyk.10 for ; Sun, 09 Jan 2011 16:32:06 -0800 (PST) Received: by 10.229.91.10 with SMTP id k10mr24084613qcm.141.1294619526189; Sun, 09 Jan 2011 16:32:06 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id s10sm15534847qco.11.2011.01.09.16.32.04 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 16:32:05 -0800 (PST) Received: by iwn40 with SMTP id 40so19975488iwn.31 for ; Sun, 09 Jan 2011 16:32:04 -0800 (PST) Received: by 10.231.85.137 with SMTP id o9mr12048244ibl.27.1294619523971; Sun, 09 Jan 2011 16:32:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 16:31:33 -0800 (PST) In-Reply-To: <20110110002533.GE5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <20110110002533.GE5743@1wt.eu> From: Adam Barth Date: Sun, 9 Jan 2011 16:31:33 -0800 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:29:55 -0000 On Sun, Jan 9, 2011 at 4:25 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 04:20:25PM -0800, Adam Barth wrote: >> On Sun, Jan 9, 2011 at 4:09 PM, Willy Tarreau wrote: >> > I have reused Maciej's code for AES-128-CTR to make it emit a constant >> > stream and look there for a supposedly processable request (which is >> > valid since Apache processes it and transcodes it if it finds it at >> > the beginning of the stream). >> > >> > willy@pcw:~/c$ time ./aes-128-ctr-get >> > Found the 'GET\n' pattern on the wire after 1608425803 bytes >> > >> > real =A0 =A00m20.761s >> > user =A0 =A00m20.761s >> > sys =A0 =A0 0m0.000s >> > >> > It requires the client to send more data, but here we're only >> > at 1.6 GB, roughly just 1000 times more than with the basic XOR >> > method. >> > >> > However, it's limited to 640 Mbps only. It means that using this >> > as a mandatory masking method will not even allow me to use a >> > memcache at gigabit speeds on my local network :-( >> >> Then you shouldn't use WebSockets to talk to memcache on your local >> network. =A0WebSockets is not the solution to every problem. =A0For the >> important uses cases, 640 Mbps with today's CPUs is vastly more than >> enough. > > But a frontal switch which has to process the frames in an internet > infrastructure will require a crypto card to handle the non-secure > version of websocket. Clearly that does not make much sense ! > > The same machine has no problem handling 10 Gbps of HTTP traffic. > 640 Mbps of WS traffic for multi-megabytes frames is a very low > performance in my opinion for a 3 GHz processor ! Any server is > able to cope with that bandwidth for large frames. Somehow, we will survive. Kind regards, Adam From gregw@intalio.com Sun Jan 9 16:37:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216A03A6855 for ; Sun, 9 Jan 2011 16:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdP24tPRxgff for ; Sun, 9 Jan 2011 16:37:33 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0BB0D3A6833 for ; Sun, 9 Jan 2011 16:37:32 -0800 (PST) Received: by qwi2 with SMTP id 2so3561486qwi.31 for ; Sun, 09 Jan 2011 16:39:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.87.13 with SMTP id u13mr23837401qcl.55.1294619984931; Sun, 09 Jan 2011 16:39:44 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 16:39:44 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Jan 2011 01:39:44 +0100 X-Google-Sender-Auth: BYR6GexxIQvDk5kepPcmrpqvJb0 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:37:34 -0000 On 9 January 2011 23:21, Adam Barth wrote: > Gentle people of hybi, > > There's been a lot of good discussion in this working group gathering > consensus around the data framing and the handshake. =A0At some point we > need to declare victory and ship the protocol, otherwise proprietary > solutions will continue to eat our lunch. > > I've written up a more formal version of Pat's proposal based on the > recent straw poll and subsequent discussion. =A0This protocol is by no > means perfect, but it's good enough: > > http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt > I cannot agree this proposal. I would only accept a cryptographic masking algorithm if it is applied as an extension (mandatory for browsers) that can be replaced by other algorithms I would only accept stream based masking if it does not apply to framing. If we were to follow John Tamplins prior proposal, then I'd accept AES-128-CTR (or similar) if that was the consensus, but my preference is still for something simpler. regards From fielding@gbiv.com Sun Jan 9 16:40:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34DFB3A6855 for ; Sun, 9 Jan 2011 16:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.168 X-Spam-Level: X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZX+3Gl6mpuK for ; Sun, 9 Jan 2011 16:40:07 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 3FC333A6833 for ; Sun, 9 Jan 2011 16:40:07 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 7BC8A10062; Sun, 9 Jan 2011 16:42:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=qHjq3vW92AqsrBUJ nZx74XhYsZFpwvlpJeHOfjAQmIfoMRciInAiEb7dzdFhXm/hJn0aRAIFYOZyI1WX CEPcckmp3zXWVy9co3vlFTe9w0zOrOeZZGHlA834DQ2wmAa93kDsN6oE9A4PNXTW gso9Gy1ifF7gNAq/fck1qWO+/tI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=bXXhbY43lkCnShyodRhZN/apJis=; b=wZ0zVQqGPgnlR7vvEsOZ6sOqV9W0 g4cqv+OBW6MLlyrGHOsCAEEZxIWdI8aEvNXZ25tr7SItHjFye/5JKM8IpqP/Disr IokLJKa1vQC2FxzZA8glPr2yq4EdTd5JfSl1ucw+jVOgT9jz3CKqJf173shy5cT5 pyz4haAIgvt3f0g= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (Authenticated sender: fielding@gbiv.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 3215C1005D; Sun, 9 Jan 2011 16:42:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <4D2A4738.2000500@gmx.de> Date: Sun, 9 Jan 2011 16:42:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> <4D2A4738.2000500@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1082) Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:40:08 -0000 On Jan 9, 2011, at 3:39 PM, Julian Reschke wrote: > On 10.01.2011 00:09, Adam Barth wrote: >> ... >> Whether we use OPTIONS or GET is much less than 1% of the value >> proposition of the WebSockets protocol. Rather than optimizing that >> part of the protocol, it's more important to pick something and go >> with it. >>=20 >> Honestly, I picked OPTIONS because it was the example given in >> http://www.ietf.org/rfc/rfc2817.txt. >> ... >=20 > OPTIONS isn't special with respect to Upgrade. (*) >=20 > My understanding is that the authors picked this example in order to = avoid to let the server ignore the Upgrade request in GET, and then = return the contents over an non-secured channel. >=20 > Unless there's a specific reason why people think OPTIONS is better = than GET here, we should stick with what was discussed before. OPTIONS is the appropriate method to use when the client does not want the action taken to be retrieval of a representation, especially when the resource might be subject to hit counting (like an advertisement). OPTIONS is preferred when you don't want the server to provide an old-version response during an Upgrade, since it has no negative implications for a compliant server. Websocket should use OPTIONS for HTTP if it is not going to mint a new method of its own. ....Roy From w@1wt.eu Sun Jan 9 16:41:35 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8399B3A6860 for ; Sun, 9 Jan 2011 16:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPiIXXu2+Ar1 for ; Sun, 9 Jan 2011 16:41:34 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 41EED3A6833 for ; Sun, 9 Jan 2011 16:41:34 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A0hhVl010576; Mon, 10 Jan 2011 01:43:43 +0100 Date: Mon, 10 Jan 2011 01:43:43 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20110110004343.GF5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <20110110002533.GE5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:41:35 -0000 On Sun, Jan 09, 2011 at 04:31:33PM -0800, Adam Barth wrote: > On Sun, Jan 9, 2011 at 4:25 PM, Willy Tarreau wrote: > > On Sun, Jan 09, 2011 at 04:20:25PM -0800, Adam Barth wrote: > >> On Sun, Jan 9, 2011 at 4:09 PM, Willy Tarreau wrote: > >> > I have reused Maciej's code for AES-128-CTR to make it emit a constant > >> > stream and look there for a supposedly processable request (which is > >> > valid since Apache processes it and transcodes it if it finds it at > >> > the beginning of the stream). > >> > > >> > willy@pcw:~/c$ time ./aes-128-ctr-get > >> > Found the 'GET\n' pattern on the wire after 1608425803 bytes > >> > > >> > real    0m20.761s > >> > user    0m20.761s > >> > sys     0m0.000s > >> > > >> > It requires the client to send more data, but here we're only > >> > at 1.6 GB, roughly just 1000 times more than with the basic XOR > >> > method. > >> > > >> > However, it's limited to 640 Mbps only. It means that using this > >> > as a mandatory masking method will not even allow me to use a > >> > memcache at gigabit speeds on my local network :-( > >> > >> Then you shouldn't use WebSockets to talk to memcache on your local > >> network.  WebSockets is not the solution to every problem.  For the > >> important uses cases, 640 Mbps with today's CPUs is vastly more than > >> enough. > > > > But a frontal switch which has to process the frames in an internet > > infrastructure will require a crypto card to handle the non-secure > > version of websocket. Clearly that does not make much sense ! > > > > The same machine has no problem handling 10 Gbps of HTTP traffic. > > 640 Mbps of WS traffic for multi-megabytes frames is a very low > > performance in my opinion for a 3 GHz processor ! Any server is > > able to cope with that bandwidth for large frames. > > Somehow, we will survive. Adam, it's not a matter of surviving or not, it's a matter of spending *all* the CPU cycles of a machine for something which is proven inefficient against the use case it was introduced for in the first place. The reason it is inefficient is not because of they crypto part, but precisely because the use case is wrong ("a caching intermediary might seek a request anywhere in the stream and for as long as possible"). It is possible that you planned to cover other vulnerabilities with this, but since you posted a complete paper without any argument for each new point, it's very hard to spot the reasons. We can just discover something is here, there is no *why* to that. Under these conditions, you can certainly expect that some people will bother why we'd suddenly decide that the protocol will work that way despite the costs when there is no explanation at all. Regards, Willy From ietf@adambarth.com Sun Jan 9 16:44:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074153A6860 for ; Sun, 9 Jan 2011 16:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.904 X-Spam-Level: X-Spam-Status: No, score=-3.904 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLzZhsnNSWpe for ; Sun, 9 Jan 2011 16:44:40 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0088C3A685A for ; Sun, 9 Jan 2011 16:44:39 -0800 (PST) Received: by qwi2 with SMTP id 2so3564057qwi.31 for ; Sun, 09 Jan 2011 16:46:52 -0800 (PST) Received: by 10.229.43.72 with SMTP id v8mr2968104qce.290.1294620410186; Sun, 09 Jan 2011 16:46:50 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id y17sm17035171qci.21.2011.01.09.16.46.48 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 16:46:49 -0800 (PST) Received: by iyi42 with SMTP id 42so18912323iyi.31 for ; Sun, 09 Jan 2011 16:46:48 -0800 (PST) Received: by 10.231.192.7 with SMTP id do7mr5919144ibb.102.1294620407988; Sun, 09 Jan 2011 16:46:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 16:46:17 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Sun, 9 Jan 2011 16:46:17 -0800 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:44:41 -0000 On Sun, Jan 9, 2011 at 4:39 PM, Greg Wilkins wrote: > On 9 January 2011 23:21, Adam Barth wrote: >> Gentle people of hybi, >> >> There's been a lot of good discussion in this working group gathering >> consensus around the data framing and the handshake. =A0At some point we >> need to declare victory and ship the protocol, otherwise proprietary >> solutions will continue to eat our lunch. >> >> I've written up a more formal version of Pat's proposal based on the >> recent straw poll and subsequent discussion. =A0This protocol is by no >> means perfect, but it's good enough: >> >> http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt > > I cannot agree this proposal. Thanks for your feedback. I'd encourage you not to implement this protocol then. Kind regards, Adam From w@1wt.eu Sun Jan 9 16:44:57 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4923A6860 for ; Sun, 9 Jan 2011 16:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXfyJwF++IAr for ; Sun, 9 Jan 2011 16:44:56 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 8217E3A685A for ; Sun, 9 Jan 2011 16:44:56 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A0l1aa010599; Mon, 10 Jan 2011 01:47:01 +0100 Date: Mon, 10 Jan 2011 01:47:01 +0100 From: Willy Tarreau To: "Roy T. Fielding" Message-ID: <20110110004701.GG5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> <4D2A4738.2000500@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:44:57 -0000 On Sun, Jan 09, 2011 at 04:42:28PM -0800, Roy T. Fielding wrote: > OPTIONS is the appropriate method to use when the client > does not want the action taken to be retrieval of a > representation, especially when the resource might be > subject to hit counting (like an advertisement). > > OPTIONS is preferred when you don't want the server to > provide an old-version response during an Upgrade, since > it has no negative implications for a compliant server. > Websocket should use OPTIONS for HTTP if it is not going > to mint a new method of its own. Thanks for this precision Roy. However, my initial remark was more for the "*" than OPTIONS itself (eventhough I mentally associated them both). "*" undoubtly has pros but it has cons too. A consensus was reached on GET yesterday afer something like one month of poll. It's a bit hard that a counter proposal is made the day after the consensus that way. Regards, Willy From w@1wt.eu Sun Jan 9 16:49:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899213A6860 for ; Sun, 9 Jan 2011 16:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2yIKM7aqIhX for ; Sun, 9 Jan 2011 16:49:25 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 9FFC43A685A for ; Sun, 9 Jan 2011 16:49:24 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A0pZqs010620; Mon, 10 Jan 2011 01:51:35 +0100 Date: Mon, 10 Jan 2011 01:51:35 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20110110005135.GH5743@1wt.eu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:49:26 -0000 On Sun, Jan 09, 2011 at 04:46:17PM -0800, Adam Barth wrote: > On Sun, Jan 9, 2011 at 4:39 PM, Greg Wilkins wrote: > > On 9 January 2011 23:21, Adam Barth wrote: > >> Gentle people of hybi, > >> > >> There's been a lot of good discussion in this working group gathering > >> consensus around the data framing and the handshake.  At some point we > >> need to declare victory and ship the protocol, otherwise proprietary > >> solutions will continue to eat our lunch. > >> > >> I've written up a more formal version of Pat's proposal based on the > >> recent straw poll and subsequent discussion.  This protocol is by no > >> means perfect, but it's good enough: > >> > >> http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt > > > > I cannot agree this proposal. > > Thanks for your feedback. I'd encourage you not to implement this > protocol then. Adam, excuse me, but you remained silent for the last days during discussions where you could have brought many strong points, and you suddenly come here acting as if you were the only one to decide what will be in the final draft, and deliberately deciding to ignore the WG's pariticipants' concerns. I can understand that you had some work, I can understand that you're fed up with things that are constantly delayed, but one reason it takes so much time to move on here is that from time to time all that was agreed upon is suddenly put upside down. It's really not easy to work that way. You really sound like you have a big hurry or you are afraid of something imminent related to the protocol (you were talking about proprietary designs in your first mail). If you have more info to put here, surely will help people understand better your motives. Thanks, Willy From julian.reschke@gmx.de Sun Jan 9 16:54:02 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7423A685C for ; Sun, 9 Jan 2011 16:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.381 X-Spam-Level: X-Spam-Status: No, score=-104.381 tagged_above=-999 required=5 tests=[AWL=-1.782, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqj-i8lcgjw2 for ; Sun, 9 Jan 2011 16:54:01 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 77B003A685A for ; Sun, 9 Jan 2011 16:53:59 -0800 (PST) Received: (qmail invoked by alias); 10 Jan 2011 00:56:11 -0000 Received: from p508FD146.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.209.70] by mail.gmx.net (mp043) with SMTP; 10 Jan 2011 01:56:11 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19vUVxHRsdvWd5jkWyuDNLLpF60BtE9nH7AosPJMn TTtBDzRuLLbwTR Message-ID: <4D2A592B.3000404@gmx.de> Date: Mon, 10 Jan 2011 01:56:11 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Roy T. Fielding" References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> <4D2A4738.2000500@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 00:54:02 -0000 On 10.01.2011 01:42, Roy T. Fielding wrote: > ... >> OPTIONS isn't special with respect to Upgrade. (*) >> >> My understanding is that the authors picked this example in order to avoid to let the server ignore the Upgrade request in GET, and then return the contents over an non-secured channel. >> >> Unless there's a specific reason why people think OPTIONS is better than GET here, we should stick with what was discussed before. > > OPTIONS is the appropriate method to use when the client > does not want the action taken to be retrieval of a > representation, especially when the resource might be > subject to hit counting (like an advertisement). Which would be relevant if the URI used for websockets *also* functions as something people could do a GET on and receive something useful (other than an error message explaining what's going on) -- I think that would be simple to avoid. > OPTIONS is preferred when you don't want the server to > provide an old-version response during an Upgrade, since > it has no negative implications for a compliant server. > Websocket should use OPTIONS for HTTP if it is not going > to mint a new method of its own. Ack. I have no problem with that as long as it's understood why the spec makes that choice. For simplicity, the best *server* side choice IMHO is to treat Upgrade the same way for a given URI, no matter what what request method was. Best regards, Julian From brofield@gmail.com Sun Jan 9 17:00:25 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF3E3A6866 for ; Sun, 9 Jan 2011 17:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-x0yHdLwpbV for ; Sun, 9 Jan 2011 17:00:22 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 0F4363A6862 for ; Sun, 9 Jan 2011 17:00:21 -0800 (PST) Received: by qyj19 with SMTP id 19so20417466qyj.10 for ; Sun, 09 Jan 2011 17:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=a3Ly9wHChUGzObZDYgMue8XHfG2Wu9rjpP3lgmqcza8=; b=MiwGn7O5Rd6KGTD32oTskOShEskdhninvzAe5vk+jnxq9TS5mrSORE3p1pca79Ymla 5PJe1kGMZh+rBfHtnvXWQ+FcAfCdmahrImdJ+b1NSUuc9xBWxyQbcgCu3shUkhE+DkTm jXxdpMtWOsb4U0jcWL9fjeYF7Aw7SlY8ROErs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=JzaTxS80CH3P1M5Xsa/5dy41fhljDBQSSXJP6+OCdr1ruxvBgWnIeA97cJYiHe3hqn qxjeNR4uw9HuM+YaTNnUfaDYW1KBpqqa5t5jTCXTvDISfHq5kZ2wJ3tZfvsbVBb+tsOA CY2AL0+0od7psC3S/XstbxO0ljW9JlpdNBq+w= MIME-Version: 1.0 Received: by 10.229.212.6 with SMTP id gq6mr24607470qcb.150.1294621353943; Sun, 09 Jan 2011 17:02:33 -0800 (PST) Sender: brofield@gmail.com Received: by 10.229.84.66 with HTTP; Sun, 9 Jan 2011 17:02:33 -0800 (PST) In-Reply-To: <4D26DE2D.5040901@ericsson.com> References: <4D26605B.1090409@callenish.com> <4D26DE2D.5040901@ericsson.com> Date: Mon, 10 Jan 2011 11:02:33 +1000 X-Google-Sender-Auth: g86CffozRLpk_Ny_tM56p9GQDLQ Message-ID: From: Brodie Thiesfield To: Salvatore Loreto Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 01:00:25 -0000 I understand that this can be addressed later, however supporting peer to peer in the protocol appears to only require a client to also support the optional masking of the server responses. In the case of a browser acting as the server, it will need to implement the server side of things like handshake and unmasking client messages. However, given that it is really also a client (with the same unknown intermediataries, etc), I assume that it would be desirable to have the same security protections as a simple client, and so it would also want to send messages using masking. As long as simple clients can also receive messages from a server with masking enabled, then there appears to be no reason that peer to peer wouldn't work with the same security guarantees (for the protocol) that client->server does. i.e. client -> server = masked server -> client = cleartext | masked How the server notifies the client that it is going to send masked responses remains unspecified. Regards, Brodie On Fri, Jan 7, 2011 at 7:34 PM, Salvatore Loreto wrote: > On 1/7/11 2:23 AM, John Tamplin wrote: > > On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton wrote: >> >> So far it appears that Greg, Brodie, Jerod, and I favour including >> peer-to-peer design considerations in the spec. I am not sure, but it sounds >> like John considers it out of scope and Scott considers it in scope. What >> about the rest of you? > > I am not opposed to it exactly, but given how long everything has taken I am > keen to keep the base protocol minimal so we can actually get something out > the door. > > I agree with John, > lets keep the base protocol minimal at moment. > Once we have reached consensus on the minimal base protocol we can > start to add other stuff on top of the minimal base. > > If there is consensus in doing something in the future we can track it in > the issue tracker > so we won't forget. > > > cheers > /Sal > > -- > Salvatore Loreto > www.sloreto.com > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > From fielding@gbiv.com Sun Jan 9 17:15:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33DB23A686D for ; Sun, 9 Jan 2011 17:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.128 X-Spam-Level: X-Spam-Status: No, score=-103.128 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcWCLA6O7Z+C for ; Sun, 9 Jan 2011 17:15:38 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 788F23A6868 for ; Sun, 9 Jan 2011 17:15:38 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 98AA5350078; Sun, 9 Jan 2011 17:17:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=TObTURDFsYr3XjLG HtGiPLVpbvHvdiwLb/gY2+zmC2US3rzvnPGB5MUHP0rPRvWTGsRTxv0W295B5HMT 2yRSt6o/lHQCkOrWwoTkkjD90FlL7MxbLZXaQYuyUxN/1TXr/+eOJevJ6uudA2oj PsNGsoRpn/xmyFA5KUD7aM0dszY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=VauROHMRKSYMvBZn1B4OxuDM8WQ=; b=c7ibLIthG3qzZvrCqZxb0zuzzR++ ptLlPQ2my1asXWpOo4GuvJuD70/OFAdJHQqrqxflIJ8mu8gAlO34RXtsbijIpfFB B0CQk6S5l9hta6vKVqTbgYaC2Ar9vA87RC4L9z0y5IIZR9GN6clxEvW2wPqMpWlh zB6lbTfgv+9ou9o= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (Authenticated sender: fielding@gbiv.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 76BFF350072; Sun, 9 Jan 2011 17:17:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <4D2A592B.3000404@gmx.de> Date: Sun, 9 Jan 2011 17:17:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <02F6DC8B-7BFE-4EAA-B91A-7DBB3CD73A7E@gbiv.com> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> <4D2A4738.2000500@gmx.de> <4D2A592B.3000404@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1082) Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 01:15:39 -0000 On Jan 9, 2011, at 4:56 PM, Julian Reschke wrote: > For simplicity, the best *server* side choice IMHO is to treat Upgrade = the same way for a given URI, no matter what what request method was. No, the value of upgrade is similar to conditional GETs: asking for an optional improvement to the protocol without costing an extra round trip. The common case is a normal GET request, and the server responds to that GET request as its first message after the protocol is upgraded, without any further bits needed from the client. IOW, waka (or some future HTTP/2.0) can be bootstrapped at near-zero cost with Upgrade because waka knows how to respond to the semantics of GET. The same applies to any other valid HTTP method -- the server must provide a valid answer to that request, in the syntax of the new protocol, after the 101 is sent (see 2616 sec 14.42). ....Roy From fielding@gbiv.com Sun Jan 9 17:31:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665B228C0E7 for ; Sun, 9 Jan 2011 17:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.092 X-Spam-Level: X-Spam-Status: No, score=-103.092 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3KiVs-9MzEV for ; Sun, 9 Jan 2011 17:31:39 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (jankymail-mx1.g.dreamhost.com [208.97.132.126]) by core3.amsl.com (Postfix) with ESMTP id 5969728C0E5 for ; Sun, 9 Jan 2011 17:31:39 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id B93D82F4065; Sun, 9 Jan 2011 17:33:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=d4kOjG2y+A+ZzEF9 D6TVVn0OlqK6guBY0xfTauElLe8aDZaZ/VAg7ZmBz4tZjmNIvrkMbOCLV3m21BEy XrOnzeSoiYTZJXSwfImj8k/M72VtSGlKgZWDC4taXNh5WQKa/a8dIFsg8Uq0aXK0 eGqtvf2G1t8UpIQCR6LK1z51JJ4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=W+H02DfuMCGJyc9Yj0OwBkJZm54=; b=15rLzQuWFP3wZDGRpOFnpt3klpOn owfFF6/oWMFnVAWit3YbyS9xgDNe0GRNuKLXENK1F/C5VYJ0FoXMlZyagtZ+J5KA zlF3t7V4HKidTVUfi6IBLQx07s3mfgWwQiv1kV5jHkN85iHlviFWW5wESDwdKrnS H6pQEF0cEMpBTwo= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (Authenticated sender: fielding@gbiv.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id A33ED2F4060; Sun, 9 Jan 2011 17:33:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <20110110004701.GG5743@1wt.eu> Date: Sun, 9 Jan 2011 17:33:59 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> <4D2A4738.2000500@gmx.de> <20110110004701.GG5743@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1082) Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 01:31:40 -0000 On Jan 9, 2011, at 4:47 PM, Willy Tarreau wrote: > "*" undoubtly has pros but it has cons too. A consensus was reached > on GET yesterday afer something like one month of poll. It's a bit > hard that a counter proposal is made the day after the consensus > that way. Yes, it's a bit hard. OTOH, the poll was nonsense because it conflated multiple undesirable options, and I ignored it as such. In any case, the IETF does not make decisions by polling. What we are looking for is rough consensus and running code, and it is quite clear that we don't have either one at the moment. We should not be making any decisions -- we should be in bake-off mode. ....Roy From ietf@adambarth.com Sun Jan 9 17:40:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9B128C0E3 for ; Sun, 9 Jan 2011 17:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.897 X-Spam-Level: X-Spam-Status: No, score=-3.897 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT7ih0b8pd1L for ; Sun, 9 Jan 2011 17:40:14 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B345C28C0DB for ; Sun, 9 Jan 2011 17:40:14 -0800 (PST) Received: by qwi2 with SMTP id 2so3588350qwi.31 for ; Sun, 09 Jan 2011 17:42:26 -0800 (PST) Received: by 10.229.95.11 with SMTP id b11mr2054126qcn.28.1294623746792; Sun, 09 Jan 2011 17:42:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id q12sm17073550qcu.30.2011.01.09.17.42.25 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 17:42:25 -0800 (PST) Received: by iyi42 with SMTP id 42so18938406iyi.31 for ; Sun, 09 Jan 2011 17:42:24 -0800 (PST) Received: by 10.231.147.149 with SMTP id l21mr11954095ibv.152.1294623744415; Sun, 09 Jan 2011 17:42:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 17:41:54 -0800 (PST) In-Reply-To: References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> <4D2A4738.2000500@gmx.de> <20110110004701.GG5743@1wt.eu> From: Adam Barth Date: Sun, 9 Jan 2011 17:41:54 -0800 Message-ID: To: "Roy T. Fielding" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 01:40:15 -0000 On Sun, Jan 9, 2011 at 5:33 PM, Roy T. Fielding wrote: > On Jan 9, 2011, at 4:47 PM, Willy Tarreau wrote: >> "*" undoubtly has pros but it has cons too. A consensus was reached >> on GET yesterday afer something like one month of poll. It's a bit >> hard that a counter proposal is made the day after the consensus >> that way. > > Yes, it's a bit hard. =A0OTOH, the poll was nonsense because it > conflated multiple undesirable options, and I ignored it as such. > > In any case, the IETF does not make decisions by polling. > > What we are looking for is rough consensus and running code, > and it is quite clear that we don't have either one at the moment. > We should not be making any decisions -- we should be in bake-off > mode. Perhaps I should have titled my message "it's time to bake." :) Adam From bruce@callenish.com Sun Jan 9 17:45:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EF028C0EB for ; Sun, 9 Jan 2011 17:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBfJoi3UQMZ6 for ; Sun, 9 Jan 2011 17:45:08 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id EF6AB28C0E3 for ; Sun, 9 Jan 2011 17:45:07 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pc6qt-00023v-2J for hybi@ietf.org; Sun, 09 Jan 2011 17:47:19 -0800 Message-ID: <4D2A6526.5050800@callenish.com> Date: Sun, 09 Jan 2011 17:47:18 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" References: <4D2A4FFE.6000503@callenish.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] Summary of issues concerning the default masking algorithm X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 01:45:08 -0000 Hi, Greg. These seem to be questions about where to apply masking rather than issues with the masking algorithm itself. I was thinking they deserve their own thread, but if you think they are better discussed here then let us consider the costs and benefits of each, and where people think the right trade-off can be found. On 09/01/2011 4:24 PM, Greg Wilkins wrote: > Bruce, > > there are also proposed features of: > > e) masking the framing as well as the payload. > > f) making masking use the current frame extension mechanism > > g) make masking be a negotiated extension (either to turn it on or off) From Martin.Thomson@andrew.com Sun Jan 9 18:19:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B110628C0E3 for ; Sun, 9 Jan 2011 18:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFbewgyzRlc7 for ; Sun, 9 Jan 2011 18:19:08 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id C3B0828C0E8 for ; Sun, 9 Jan 2011 18:19:08 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:57363 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S41081441Ab1AJCVU (ORCPT ); Sun, 9 Jan 2011 20:21:20 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 9 Jan 2011 20:21:20 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 10 Jan 2011 10:21:17 +0800 From: "Thomson, Martin" To: Willy Tarreau , Hybi Date: Mon, 10 Jan 2011 10:21:16 +0800 Thread-Topic: [hybi] AES-128-CTR not much safer, but not fast either Thread-Index: AcuwWp3tCD+5RqxfRIy4nMoyQjMGjgAEgOWQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> References: <20110110000908.GD5743@1wt.eu> In-Reply-To: <20110110000908.GD5743@1wt.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 02:19:09 -0000 T24gMjAxMS0wMS0xMCBhdCAxMTowOTowOCwgV2lsbHkgVGFycmVhdSB3cm90ZToNCj4gd2lsbHlA cGN3On4vYyQgdGltZSAuL2Flcy0xMjgtY3RyLWdldA0KPiBGb3VuZCB0aGUgJ0dFVFxuJyBwYXR0 ZXJuIG9uIHRoZSB3aXJlIGFmdGVyIDE2MDg0MjU4MDMgYnl0ZXMNCg0KWW91IG1pZ2h0IGFsc28g ZmluZCB0aGUgY29sbGVjdGVkIHdvcmtzIG9mIFNoYWtlc3BlYXJlIGluIHRoZSBieXRlIHN0cmVh bSBoYWQgeW91IHdhaXRlZCBhIGxpdHRsZSBsb25nZXIuICBJJ20gbm90IHN1cmUgd2hhdCB5b3Ug YXJlIGhvcGluZyB0byBwcm92ZSBieSBzZWFyY2hpbmcuDQo= From bruce@callenish.com Sun Jan 9 18:30:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E3128C0E3 for ; Sun, 9 Jan 2011 18:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc6kVu32WTlK for ; Sun, 9 Jan 2011 18:30:14 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 266C628C0D9 for ; Sun, 9 Jan 2011 18:30:14 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Pc7YX-0003eU-9r for hybi@ietf.org; Sun, 09 Jan 2011 18:32:25 -0800 Message-ID: <4D2A6FB9.1030005@callenish.com> Date: Sun, 09 Jan 2011 18:32:25 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4D2A4FFE.6000503@callenish.com> In-Reply-To: <4D2A4FFE.6000503@callenish.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] Summary of issues concerning the default masking algorithm X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 02:30:15 -0000 Here is where I currently stand on the trade-offs in costs versus benefits from the 4 features I've listed. This is absent an actual list of the benefits being provided by anyone else nor of any feedback on the costs, so it is perhaps premature. This is my current perspective, though. > For feature a, the only cost I can see is in the increase in > complexity in generating the mask. I don't understand the benefit, but the cost seems so minimal I can't see why it would be a problem. > > For feature b, there is the increase in complexity in generating the > mask as well as the fact that you can not send a payload with the > initial handshake from the client because you do not yet have the > server nonce. The benefit I can see to this is that it prevents an attacker from faking a websocket connection by laying down what looks like perfectly valid websocket frames. Without the server nonce, this won't be possible because the masks generated by the attacker will not show the influence of the server nonce on them. The cost seems pretty minimal to me in order to get that guarantee. > > The principal cost of feature c that I can see is that it stops tools > like wireshark from being able to decode streams. The benefit that I can see with this feature is that it will force the server to pay attention to whether the server nonce was used to generate the mask, since the server will need to generate the mask itself by using the nonce. The cost of losing the ability to decode streams is, to me, extremely high. It is beyond that, it is painful. When I have to debug a network issue in a customer's environment, a problem that would take me a few hours with a decoded stream jumps to days or even weeks. What is worse is that it is often difficult if not impossible to demonstrate to the customer when the issue is not with my application. Although I can create multitudes of logs that show all the bits my application receives and sends, the customer has no way of knowing whether there are bits that are not logged because they are dealt with via another code path. Also, without having a decoded stream it can be very difficult to pinpoint where in a customer's network the actual problem is arising. This is another case of "not my fault, still my problem". If my application doesn't work in the customer's environment then I lose the customer. Whenever I have to deal with an encrypted stream I groan in agony. So the benefits would have to be pretty high for me to consider this a good trade-off to make. The benefit I listed above doesn't make it. > > The cost of feature d is increased complexity in implementation and > added computational cost. I have no idea what the benefit to this is, but I trust that the people arguing about it have a reason for believing there is one and I hope they describe it here in simple words I can understand. I find it interesting how we have gone from requiring the simplest of possible Websocket servers to ones that require teasing out highly optimized versions of HMAC from other libraries. I think that keeping things as simple to implement as possible is the sensible thing to do, but I am uncertain about what definition to give "possible". I don't have the expertise to properly evaluate the computational cost. Willy seems to know a lot about the subject, though, so he has my proxy. If Willy is convinced it is worth it then so am I. From ekr@rtfm.com Sun Jan 9 18:36:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8F028C0E4 for ; Sun, 9 Jan 2011 18:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.652 X-Spam-Level: X-Spam-Status: No, score=-101.652 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpiVQcSh1o88 for ; Sun, 9 Jan 2011 18:36:08 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 36B1828C0D9 for ; Sun, 9 Jan 2011 18:36:07 -0800 (PST) Received: by gyd12 with SMTP id 12so8098717gyd.31 for ; Sun, 09 Jan 2011 18:38:19 -0800 (PST) Received: by 10.91.196.17 with SMTP id y17mr5944626agp.207.1294627099142; Sun, 09 Jan 2011 18:38:19 -0800 (PST) Received: from [10.58.83.125] ([166.205.138.101]) by mx.google.com with ESMTPS id b27sm36949604ana.8.2011.01.09.18.38.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 18:38:18 -0800 (PST) References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <670C37A1-B413-49C0-8C47-E2E06DB447ED@apple.com> <20110107185801.GB32612@1wt.eu> <20110107203958.GC32612@1wt.eu> <4D28DF6E.4080003@callenish.com> <4D2A307C.3080109@callenish.com> <4D2A48BB.5020400@callenish.com> In-Reply-To: <4D2A48BB.5020400@callenish.com> Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <54845921-0C87-41B2-A2FC-6D1F3F6B7815@rtfm.com> X-Mailer: iPhone Mail (8C148a) From: Eric Rescorla Date: Sun, 9 Jan 2011 18:38:05 -0800 To: Bruce Atherton Cc: "hybi@ietf.org" Subject: Re: [hybi] A bit of pragmatism X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 02:36:09 -0000 What I am saying is that the crypto in tls generally doesn't provide any pro= tection here because absent masking the attacker can produce predictable cip= hertext. Maybe that is orthogonal to your point but I thought it was worth n= oting Ekr On Jan 9, 2011, at 15:46, Bruce Atherton wrote: > I apologize if I am being thick, but I still don't understand. >=20 > It is my understanding that the masking algorithms which have been previou= sly suggested prevent the attacker from controlling the payload bits on the w= ire from within a browser using Websockets without the added burden of being= cryptographically secure. I had thought that you were arguing that the atta= cker could still control patterns in the bits, but not the bits themselves. T= hat seemed like a reasonable thing for the ws: scheme to allow, to me, since= by design it is a lighter weight, less secure form of Websockets and there h= ave never been any exploits that relied on that characteristic that anyone h= as mentioned so far. Now it sounds like you are arguing that an attacker can= completely control the bits no matter what unless it is cryptographically s= ecure. >=20 > I'm sure I'm missing something, but I haven't a clue what it is. >=20 > On 09/01/2011 2:16 PM, Eric Rescorla wrote: >> It's not a matter of random versus non-random. RC4 and AES-CTR without ra= ndom IV >> (which is not a requirement of the standard) provide the attacker with >> complete control over >> the payload bits on the wire, beause he can predict the keystream. >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From ekr@rtfm.com Sun Jan 9 18:37:01 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96BE628C0E8 for ; Sun, 9 Jan 2011 18:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.836 X-Spam-Level: X-Spam-Status: No, score=-101.836 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQY6i7fl+bBs for ; Sun, 9 Jan 2011 18:37:00 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E4B4D28C0D9 for ; Sun, 9 Jan 2011 18:36:59 -0800 (PST) Received: by gwj17 with SMTP id 17so10030268gwj.31 for ; Sun, 09 Jan 2011 18:39:12 -0800 (PST) Received: by 10.100.172.7 with SMTP id u7mr9662482ane.176.1294627151992; Sun, 09 Jan 2011 18:39:11 -0800 (PST) Received: from [10.58.83.125] ([166.205.138.101]) by mx.google.com with ESMTPS id b27sm36949604ana.8.2011.01.09.18.39.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 18:39:11 -0800 (PST) References: <4D26605B.1090409@callenish.com> <4D26DE2D.5040901@ericsson.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148a) From: Eric Rescorla Date: Sun, 9 Jan 2011 18:39:01 -0800 To: Brodie Thiesfield Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 02:37:01 -0000 Not really. Meaningful p2p operation requires nat traversal Ekr On Jan 9, 2011, at 17:02, Brodie Thiesfield wrote: > I understand that this can be addressed later, however supporting peer > to peer in the protocol appears to only require a client to also > support the optional masking of the server responses. >=20 > In the case of a browser acting as the server, it will need to > implement the server side of things like handshake and unmasking > client messages. However, given that it is really also a client (with > the same unknown intermediataries, etc), I assume that it would be > desirable to have the same security protections as a simple client, > and so it would also want to send messages using masking. >=20 > As long as simple clients can also receive messages from a server with > masking enabled, then there appears to be no reason that peer to peer > wouldn't work with the same security guarantees (for the protocol) > that client->server does. >=20 > i.e. > client -> server =3D masked > server -> client =3D cleartext | masked >=20 > How the server notifies the client that it is going to send masked > responses remains unspecified. >=20 > Regards, > Brodie >=20 >=20 > On Fri, Jan 7, 2011 at 7:34 PM, Salvatore Loreto > wrote: >> On 1/7/11 2:23 AM, John Tamplin wrote: >>=20 >> On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton wrot= e: >>>=20 >>> So far it appears that Greg, Brodie, Jerod, and I favour including >>> peer-to-peer design considerations in the spec. I am not sure, but it so= unds >>> like John considers it out of scope and Scott considers it in scope. Wha= t >>> about the rest of you? >>=20 >> I am not opposed to it exactly, but given how long everything has taken I= am >> keen to keep the base protocol minimal so we can actually get something o= ut >> the door. >>=20 >> I agree with John, >> lets keep the base protocol minimal at moment. >> Once we have reached consensus on the minimal base protocol we can >> start to add other stuff on top of the minimal base. >>=20 >> If there is consensus in doing something in the future we can track it in= >> the issue tracker >> so we won't forget. >>=20 >>=20 >> cheers >> /Sal >>=20 >> -- >> Salvatore Loreto >> www.sloreto.com >>=20 >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >>=20 >>=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From brofield@gmail.com Sun Jan 9 18:58:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC8028C0E8 for ; Sun, 9 Jan 2011 18:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yrtW02dm9VD for ; Sun, 9 Jan 2011 18:58:02 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 91F3128C0D9 for ; Sun, 9 Jan 2011 18:58:02 -0800 (PST) Received: by qwi2 with SMTP id 2so3623578qwi.31 for ; Sun, 09 Jan 2011 19:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=uYl7t/OJQ8npf4D7fDYBKRPPYSp9s5OzeVgFVJRLlmY=; b=iF9uAcBkj+gnvW9279Ma/+2TlOyhOEESMhbqX8D6T71xRUYFQ/dAjhhsa39Fkw+uYG Ra9sFl6REN9RHCOo+iemq5lVVy9xlholenG8FzxZreLwZ/VcjL/Y4VETf3w0NYziEqxK CDK2ZqukZ7wkUOc2N3UDQgdPDJ+x7zgqPhnq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=uvkNZfMK6z4mDVlZ+6RBbh1eYS/AVDx6FX90RSk4UZrUPOTRuaqVu7jVt2QeHF5xOM Dr26Fc5ZMjAG2NSHj6aNo0Ryy/iqSTQOT4ILxLikfpd+loUKpW1nBe+IOcGdSbao1x8x QKFdLvr4/yL/WTGVat+An+va6Oml0BoVlnhUs= MIME-Version: 1.0 Received: by 10.229.229.200 with SMTP id jj8mr14739746qcb.74.1294628414865; Sun, 09 Jan 2011 19:00:14 -0800 (PST) Sender: brofield@gmail.com Received: by 10.229.84.66 with HTTP; Sun, 9 Jan 2011 19:00:14 -0800 (PST) In-Reply-To: References: <4D26605B.1090409@callenish.com> <4D26DE2D.5040901@ericsson.com> Date: Mon, 10 Jan 2011 12:00:14 +0900 X-Google-Sender-Auth: nQCRGmbCyqI_x62-SOIeTfhfPe0 Message-ID: From: Brodie Thiesfield To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 02:58:04 -0000 Where clients aren't behind NAT a direct connection can be used, when they are then a central hub relay. More complex schemes could be added later, however simply trying for a direct connection and falling back to a central relay is possible with the existing protocol. However this problem is solved though, we will still have a client is acting as a server and (I am assuming) that client will still want to send masked data too. In the case of direct connection, where no central server can modify the data stream, the client on the other end must unmask the data coming from the server. So the most basic support for p2p with the current protocol maintaining security guarantees would only require a client to be able to accept either masked or unmasked responses from the server. The security paranoid could then also optionally configure a server to send masked responses (if supported). Regards, Brodie On Mon, Jan 10, 2011 at 11:39 AM, Eric Rescorla wrote: > Not really. Meaningful p2p operation requires nat traversal > > Ekr > > On Jan 9, 2011, at 17:02, Brodie Thiesfield wrote: > >> I understand that this can be addressed later, however supporting peer >> to peer in the protocol appears to only require a client to also >> support the optional masking of the server responses. >> >> In the case of a browser acting as the server, it will need to >> implement the server side of things like handshake and unmasking >> client messages. However, given that it is really also a client (with >> the same unknown intermediataries, etc), I assume that it would be >> desirable to have the same security protections as a simple client, >> and so it would also want to send messages using masking. >> >> As long as simple clients can also receive messages from a server with >> masking enabled, then there appears to be no reason that peer to peer >> wouldn't work with the same security guarantees (for the protocol) >> that client->server does. >> >> i.e. >> client -> server = masked >> server -> client = cleartext | masked >> >> How the server notifies the client that it is going to send masked >> responses remains unspecified. >> >> Regards, >> Brodie >> >> >> On Fri, Jan 7, 2011 at 7:34 PM, Salvatore Loreto >> wrote: >>> On 1/7/11 2:23 AM, John Tamplin wrote: >>> >>> On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton wrote: >>>> >>>> So far it appears that Greg, Brodie, Jerod, and I favour including >>>> peer-to-peer design considerations in the spec. I am not sure, but it sounds >>>> like John considers it out of scope and Scott considers it in scope. What >>>> about the rest of you? >>> >>> I am not opposed to it exactly, but given how long everything has taken I am >>> keen to keep the base protocol minimal so we can actually get something out >>> the door. >>> >>> I agree with John, >>> lets keep the base protocol minimal at moment. >>> Once we have reached consensus on the minimal base protocol we can >>> start to add other stuff on top of the minimal base. >>> >>> If there is consensus in doing something in the future we can track it in >>> the issue tracker >>> so we won't forget. >>> >>> >>> cheers >>> /Sal >>> >>> -- >>> Salvatore Loreto >>> www.sloreto.com >>> >>> _______________________________________________ >>> hybi mailing list >>> hybi@ietf.org >>> https://www.ietf.org/mailman/listinfo/hybi >>> >>> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi > From ifette@google.com Sun Jan 9 22:06:07 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519443A6A06 for ; Sun, 9 Jan 2011 22:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.121 X-Spam-Level: X-Spam-Status: No, score=-104.121 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfON1crOI6xc for ; Sun, 9 Jan 2011 22:06:05 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id AEA283A6A03 for ; Sun, 9 Jan 2011 22:06:05 -0800 (PST) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p0A68HxA008263 for ; Sun, 9 Jan 2011 22:08:17 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294639698; bh=FviWSME5MySLv+E4kh/pyQZVlPE=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=sh01qf3yjFaHevucL0zFqkkKrvOnSzyEOsvAIuMKw6UB094pRmQNjxKfyYggPLYs9 whdTm0GyVIncspTIESVYg== Received: from qwa26 (qwa26.prod.google.com [10.241.193.26]) by kpbe20.cbf.corp.google.com with ESMTP id p0A68GpP027242 for ; Sun, 9 Jan 2011 22:08:16 -0800 Received: by qwa26 with SMTP id 26so19351173qwa.14 for ; Sun, 09 Jan 2011 22:08:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=IY1l8zFxKHfXfHFnclcoeJsQoiZly0/BugxxhaVwruk=; b=omSGboPZ0oosE7u2d11y2vguKFqy2SZHWi4X1roemJeiruv2oyOKTSmio9kz0OaA21 m3K+AwJwd7Lt6Rt0OEWA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=dNt1SJrJjeYfZsBpt0WJdS/tpf8L3m6YZudkVnBeElR9eJY6TNVnirAzH3J/kWCrr3 cldzCiEwnUQqrJqqo7Rw== MIME-Version: 1.0 Received: by 10.229.251.137 with SMTP id ms9mr1570qcb.188.1294639693623; Sun, 09 Jan 2011 22:08:13 -0800 (PST) Received: by 10.229.0.137 with HTTP; Sun, 9 Jan 2011 22:08:13 -0800 (PST) In-Reply-To: <20110109224228.GU5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> Date: Sun, 9 Jan 2011 22:08:13 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Willy Tarreau Content-Type: multipart/alternative; boundary=00163630feb30d29c3049977cb0d X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:06:07 -0000 --00163630feb30d29c3049977cb0d Content-Type: text/plain; charset=UTF-8 On Sun, Jan 9, 2011 at 2:42 PM, Willy Tarreau wrote: > Hello Adam, > > On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth wrote: > > Gentle people of hybi, > > > > There's been a lot of good discussion in this working group gathering > > consensus around the data framing and the handshake. At some point we > > need to declare victory and ship the protocol, otherwise proprietary > > solutions will continue to eat our lunch. > > > > I've written up a more formal version of Pat's proposal based on the > > recent straw poll and subsequent discussion. This protocol is by no > > means perfect, but it's good enough: > > > > http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt > > It would help a lot other WG participants if you could present suggestions, > ideas and changes instead of a full proposal. It's hard to spot the > proposed > changes. > > At first glance, I'm noticing a few things : > > - you're using the OPTIONS method. The WG's consensus was voted as using > GET. While technically working, OPTIONS limits some possibilities since > no path is sent to the server. > > I agree it is important to be able to identify between various resources on a server. E.g. for our use, we will have multiple different websocket endpoints, and we want our frontend to be able to dispatch to the appropriate backend based on the information in the handshake. That said, I think the draft allows for that (Sec-WebSocket-URL), or as pointed out on another thread, it appears OPTIONS does allow for a path component. So, I think we should be able to resolve that point. > - your proposal involves AES-128-CTR. As was discussed here, it seems > there > are still export regulations for certain countries eventhough they're > apparently fading out. It could still be a problem for companies who > want > to export products to some countries and which never had to put crypto > in > them. > It would be nice to understand if this is actually a hard constraint. AES-128-CTR has the benefit of being well understood, as well as fast, as demonstrated by Maciej in another thread. That said, I don't care strongly one way or another here. > > - several people on the list asked for the ability to be able to disable > the masking in some well-controlled environments (eg: server-to-server > communications). I see no provisions for this. > > There's nothing that would prevent you from writing an extension that would disable the masking, from my understanding. > - it has not yet been stated whether only the payload or also the framing > should be masked. Your proposal masks both, which means that it > definitely > blocks any possibility of performing multiplexing later. There does not > appear to have been a consensus in this area yet. > > I'm not sure why this would block the possibility of multiplexing. I would agree that would be a problem if it were the case. However, a number of the early proposals for multiplexing included something like a stream-id in the frame. This could still be present. Though it would be masked, so would the length and other things that a meaningful intermediary would care about, so assuming the intermediary was capable of un-masking, is this an issue? > - is was suggested that some (all ?) of the nonces could go away if > masking > is used. Surely this is something that needs to be rechecked. > - Greg proposed to replace the MORE bit with a FIN bit so that the first > hello frame from the server starts with a high bit set, thus ensuring > that we can break the connection on non-HTTP compliant intermediaries > which would expect a second response after the 101. > > The draft Adam sent out is based on an intermediate version I had checked into SVN, back when it looked like we were gaining speed on CONNECT. I didn't yet get around to flipping MORE/FIN, but I don't have any ojbections to this. > Those are just a few notes, it's really not easy to changes :-/ > There's a tool on the IETF to diff drafts. I find it quite helpful, that said, a lot of text has changed because I had already started to make other requested changes (including trying to resolve the HTTP compliance issue, by stating the requirements of the handshake rather than stating send X bytes, send Y bytes, ...). This makes the diff a bit harder to interpret, for sure. That said, I do hope that this can spur some more targeted conversations and drive progress. > > Thanks for this work, > Willy > > > > > > > As a working group, it's time to ship. > > > > Kind regards, > > Adam > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --00163630feb30d29c3049977cb0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 9, 2011 at 2:42 PM, Willy Tarreau <w@1wt.eu> wro= te:
Hello Adam,

On Sun, Jan 09, 2011 at 02:21:44PM -0800, Adam Barth wrote:
> Gentle people of hybi,
>
> There's been a lot of good discussion in this working group gather= ing
> consensus around the data framing and the handshake. =C2=A0At some poi= nt we
> need to declare victory and ship the protocol, otherwise proprietary > solutions will continue to eat our lunch.
>
> I've written up a more formal version of Pat's proposal based = on the
> recent straw poll and subsequent discussion. =C2=A0This protocol is by= no
> means perfect, but it's good enough:
>
> http://www.ietf.org/id/draft-abarth-thewebsocketpro= tocol-01.txt

It would help a lot other WG participants if you could present sugges= tions,
ideas and changes instead of a full proposal. It's hard to spot the pro= posed
changes.

At first glance, I'm noticing a few things :

=C2=A0- you're using the OPTIONS method. The WG's consensus was vo= ted as using
=C2=A0 =C2=A0GET. While technically working, OPTIONS limits some possibili= ties since
=C2=A0 =C2=A0no path is sent to the server.


I agree it is important to be able to = identify between various resources on a server. E.g. for our use, we will h= ave multiple different websocket endpoints, and we want our frontend to be = able to dispatch to the appropriate backend based on the information in the= handshake. That said, I think the draft allows for that (Sec-WebSocket-URL= ), or as pointed out on another thread, it appears OPTIONS does allow for a= path component. So, I think we should be able to resolve that point.
=C2=A0
=C2=A0- your proposal involves AES-128-CTR. As was discussed here, it seem= s there
=C2=A0 =C2=A0are still export regulations for certain countries eventhough= they're
=C2=A0 =C2=A0apparently fading out. It could still be a problem for compan= ies who want
=C2=A0 =C2=A0to export products to some countries and which never had to p= ut crypto in
=C2=A0 =C2=A0them.

It would be nice to= understand if this is actually a hard constraint. AES-128-CTR has the bene= fit of being well understood, as well as fast, as demonstrated by Maciej in= another thread. That said, I don't care strongly one way or another he= re.
=C2=A0

=C2=A0- several people on the list asked for the ability to be able to dis= able
=C2=A0 =C2=A0the masking in some well-controlled environments (eg: server-= to-server
=C2=A0 =C2=A0communications). I see no provisions for this.


There's nothing that would prevent= you from writing an extension that would disable the masking, from my unde= rstanding.
=C2=A0
=C2=A0- it has not yet been stated whether only the payload or also the fr= aming
=C2=A0 =C2=A0should be masked. Your proposal masks both, which means that = it definitely
=C2=A0 =C2=A0blocks any possibility of performing multiplexing later. Ther= e does not
=C2=A0 =C2=A0appear to have been a consensus in this area yet.


I'm not sure why this would block = the possibility of multiplexing. I would agree that would be a problem if i= t were the case. However, a number of the early proposals for multiplexing = included something like a stream-id in the frame. This could still be prese= nt. Though it would be masked, so would the length and other things that a = meaningful intermediary would care about, so assuming the intermediary was = capable of un-masking, is this an issue?
=C2=A0
=C2=A0- is was suggested that some (all ?) of the nonces could go away if = masking
=C2=A0 =C2=A0is used. Surely this is something that needs to be rechecked.=
=C2=A0
=C2=A0- Greg proposed to replace the MORE bit with a FIN bit so that the f= irst
=C2=A0 =C2=A0hello frame from the server starts with a high bit set, thus = ensuring
=C2=A0 =C2=A0that we can break the connection on non-HTTP compliant interm= ediaries
=C2=A0 =C2=A0which would expect a second response after the 101.


The draft Adam sent out is based on an= intermediate version I had checked into SVN, back when it looked like we w= ere gaining speed on CONNECT. I didn't yet get around to flipping MORE/= FIN, but I don't have any ojbections to this.
=C2=A0
Those are just a few notes, it's really not easy to changes :-/

There's a tool on the IETF to diff drafts.= I find it quite helpful, that said, a lot of text has changed because I ha= d already started to make other requested changes (including trying to reso= lve the HTTP compliance issue, by stating the requirements of the handshake= rather than stating send X bytes, send Y bytes, ...). This makes the diff = a bit harder to interpret, for sure.

That said, I do hope that this can spur some more targe= ted conversations and drive progress.
=C2=A0

Thanks for this work,
Willy



>
> As a working group, it's time to ship.
>
> Kind regards,
> Adam
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--00163630feb30d29c3049977cb0d-- From gregw@intalio.com Sun Jan 9 22:20:18 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B113A6A83 for ; Sun, 9 Jan 2011 22:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfHIEFYXZSrS for ; Sun, 9 Jan 2011 22:20:17 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 38BC23A6A61 for ; Sun, 9 Jan 2011 22:18:54 -0800 (PST) Received: by qwi2 with SMTP id 2so3720831qwi.31 for ; Sun, 09 Jan 2011 22:20:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.235.143 with SMTP id kg15mr24083098qcb.17.1294640451073; Sun, 09 Jan 2011 22:20:51 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 22:20:51 -0800 (PST) In-Reply-To: <4D2A6526.5050800@callenish.com> References: <4D2A4FFE.6000503@callenish.com> <4D2A6526.5050800@callenish.com> Date: Mon, 10 Jan 2011 07:20:51 +0100 X-Google-Sender-Auth: HwdUp1sNgTZZCTNTWzB90Bw_ew4 Message-ID: From: Greg Wilkins To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Summary of issues concerning the default masking algorithm X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:20:18 -0000 On 10 January 2011 02:47, Bruce Atherton wrote: > Hi, Greg. > > These seem to be questions about where to apply masking rather than issues > with the masking algorithm itself. I was thinking they deserve their own > thread, but if you think they are better discussed here then let us consider > the costs and benefits of each, and where people think the right trade-off > can be found. > I think they are very closely bound. If masking uses a crypto algorithm, then having the flexibility of an extension to change the algorithm is more important. If masking is just XOR of a random mask, then perhaps it such agility is less important. If masking is stream based, then masking the framing becomes even more of a PITA that it would be otherwise. Multiplexing become very complex and Debugging tools would not even be able to identify frames without tracking the entire stream. regards From gregw@intalio.com Sun Jan 9 22:22:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992E83A6A4A for ; Sun, 9 Jan 2011 22:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvnWnKM0i1ac for ; Sun, 9 Jan 2011 22:22:18 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B52CC3A6A49 for ; Sun, 9 Jan 2011 22:22:18 -0800 (PST) Received: by qwi2 with SMTP id 2so3722782qwi.31 for ; Sun, 09 Jan 2011 22:24:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.53.213 with SMTP id n21mr26564349qag.399.1294640671478; Sun, 09 Jan 2011 22:24:31 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 22:24:31 -0800 (PST) In-Reply-To: References: <20110109224228.GU5743@1wt.eu> Date: Mon, 10 Jan 2011 07:24:31 +0100 X-Google-Sender-Auth: tFKVc6bjp9MN3oGuXAkfT_kmAm4 Message-ID: From: Greg Wilkins To: ifette@google.com Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:22:19 -0000 2011/1/10 Ian Fette ($B%$%"%s%U%'%C%F%#(B) : >> - several people on the list asked for the ability to be able to disable >> the masking in some well-controlled environments (eg: server-to-server >> communications). I see no provisions for this. >> > > There's nothing that would prevent you from writing an extension that would > disable the masking, from my understanding. By masking the framing, the masking inherently becomes part of the framing. Intermediaries will need to be written that understand the masking, just so that they can parse the framing. Thus you cannot turn masking off unless you modify every WS component in the chain with knowledge of the no-masking extension. The whole point of extensions was to allows opaque extension data to be associated with frames so that it is only handled by components that care about it. From gregw@intalio.com Sun Jan 9 22:26:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6808A3A6A5C for ; Sun, 9 Jan 2011 22:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 673bdwU3E6Gj for ; Sun, 9 Jan 2011 22:26:47 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 570E23A6A50 for ; Sun, 9 Jan 2011 22:26:47 -0800 (PST) Received: by qyj19 with SMTP id 19so20576668qyj.10 for ; Sun, 09 Jan 2011 22:29:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.87.13 with SMTP id u13mr24051358qcl.55.1294640939799; Sun, 09 Jan 2011 22:28:59 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 22:28:59 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Jan 2011 07:28:59 +0100 X-Google-Sender-Auth: 7DutHklO1eJ6RY9E4mywdB9sMTc Message-ID: From: Greg Wilkins To: Adam Barth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:26:48 -0000 On 10 January 2011 01:46, Adam Barth wrote: > Thanks for your feedback. =A0I'd encourage you not to implement this > protocol then. Check the attitude mate! From w@1wt.eu Sun Jan 9 22:34:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B293A6A64 for ; Sun, 9 Jan 2011 22:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZrJzsyy44jo for ; Sun, 9 Jan 2011 22:34:38 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id DDECD3A6A5D for ; Sun, 9 Jan 2011 22:34:36 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A6akSH011612; Mon, 10 Jan 2011 07:36:46 +0100 Date: Mon, 10 Jan 2011 07:36:46 +0100 From: Willy Tarreau To: "Thomson, Martin" Message-ID: <20110110063646.GJ5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:34:39 -0000 On Mon, Jan 10, 2011 at 10:21:16AM +0800, Thomson, Martin wrote: > On 2011-01-10 at 11:09:08, Willy Tarreau wrote: > > willy@pcw:~/c$ time ./aes-128-ctr-get > > Found the 'GET\n' pattern on the wire after 1608425803 bytes > > You might also find the collected works of Shakespeare in the byte stream had you waited a little longer. I know, that's just a matter of defining "a little longer", as none of us will live long enough for that. > I'm not sure what you are hoping to prove by searching. What I'm just showing is that we have the following points : 1) it was reported by an experiment that some caching intermediaries were waiting for an HTTP request after the HTTP handshake was over 2) it was speculated that some lazy intermediaries might possibly skip over whatever they did not understand to resync on an HTTP request they understand and execute it, hence the need for masking the stream or payload. Please note that no such intermediary has even been remotely detected, and that several people here who have already been involved with server code expressed that making them capable of doing so would be much more difficult than doing the right thing and would not even respect the principle of laziness. 3) it has been suggested that a simple 32-bit XOR was not enough and that stronger cryptography was needed, because after a certain number of attempts, the server might get the client to send a request that such an intermediary can parse. 4) it was reported that at least one intermediary (Apache) accepts an HTTP/0.9 request as simple as "GET\n". 5) it was shown that whatever algorithm we used to address the third point was not enough to cover the second point for the supposedly lazy intermediaries from #2 acting like Apache. So now, we have a choice : - either we agree that #2 above is not that much of a risk such that we don't need #3 to address it ; - or we agree that #2 is still much of a concern, but as #4 is real, then #3 is not a valid solution, as was proven with #5, and we must use another one. But right now we're just complicating the protocol and removing some possibilities of later extensions without addressing the reason why we did that in the first place. Thanks, Willy From gregw@intalio.com Sun Jan 9 22:36:48 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19E93A6A5C for ; Sun, 9 Jan 2011 22:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaAwr-zTQ3JN for ; Sun, 9 Jan 2011 22:36:46 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0FF453A6A53 for ; Sun, 9 Jan 2011 22:36:45 -0800 (PST) Received: by qwi2 with SMTP id 2so3731029qwi.31 for ; Sun, 09 Jan 2011 22:38:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.214.71 with SMTP id gz7mr13014164qab.349.1294641538734; Sun, 09 Jan 2011 22:38:58 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 22:38:58 -0800 (PST) In-Reply-To: <4D2A592B.3000404@gmx.de> References: <20110109224228.GU5743@1wt.eu> <20110109230229.GX5743@1wt.eu> <0311EE7A-4A32-4885-BC87-1541AA70A18B@apple.com> <4D2A4738.2000500@gmx.de> <4D2A592B.3000404@gmx.de> Date: Mon, 10 Jan 2011 07:38:58 +0100 X-Google-Sender-Auth: bQQXemEb5eIr8js3c00ocJbvwm4 Message-ID: From: Greg Wilkins To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: "Roy T. Fielding" , Hybi Subject: Re: [hybi] OPTIONS (was Re: It's time to ship) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:36:49 -0000 On 10 January 2011 01:56, Julian Reschke wrote: > > For simplicity, the best *server* side choice IMHO is to treat Upgrade the > same way for a given URI, no matter what what request method was. +1 The client should use another method (eg GET), only if it is prepared to accept a valid response to that method (or the consequences on the server of a PUT/POST/etc.) if the upgrade is not accepted (or is discarded by an intermediary). WS will be used in situations where fall back transports (eg long polling) will be used if ws is not supported. To avoid extra round trips it is desirable that a failed WS handshake be able to be used as part of the initiation of such a fallback prototocol. I fully understand that such a fallback would need support in the browser API, an that will not be coming any time soon, but that is no reason to deny this approach in the protocol for the future or for non browser clients. cheers From w@1wt.eu Sun Jan 9 22:37:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2BA33A6A53 for ; Sun, 9 Jan 2011 22:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ2CyhOz3Cq1 for ; Sun, 9 Jan 2011 22:37:22 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id BC9193A6A5C for ; Sun, 9 Jan 2011 22:37:21 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A6dU7o011637; Mon, 10 Jan 2011 07:39:30 +0100 Date: Mon, 10 Jan 2011 07:39:30 +0100 From: Willy Tarreau To: Bruce Atherton Message-ID: <20110110063930.GK5743@1wt.eu> References: <4D2A4FFE.6000503@callenish.com> <4D2A6FB9.1030005@callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D2A6FB9.1030005@callenish.com> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] Summary of issues concerning the default masking algorithm X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:37:24 -0000 On Sun, Jan 09, 2011 at 06:32:25PM -0800, Bruce Atherton wrote: > The cost of losing the ability to decode streams is, to me, extremely > high. It is beyond that, it is painful. When I have to debug a network > issue in a customer's environment, a problem that would take me a few > hours with a decoded stream jumps to days or even weeks. What is worse > is that it is often difficult if not impossible to demonstrate to the > customer when the issue is not with my application. Although I can > create multitudes of logs that show all the bits my application receives > and sends, the customer has no way of knowing whether there are bits > that are not logged because they are dealt with via another code path. +1, that's an experience I share all the day too the other way around, proving from network captures that the application is faulty, despite how expensive it was ! Willy From ietf@adambarth.com Sun Jan 9 22:42:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373063A6A5C for ; Sun, 9 Jan 2011 22:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.891 X-Spam-Level: X-Spam-Status: No, score=-3.891 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pfwhRx3maD2 for ; Sun, 9 Jan 2011 22:42:39 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id AD2CB3A6934 for ; Sun, 9 Jan 2011 22:42:39 -0800 (PST) Received: by gyd12 with SMTP id 12so8150196gyd.31 for ; Sun, 09 Jan 2011 22:44:52 -0800 (PST) Received: by 10.236.109.12 with SMTP id r12mr11979682yhg.32.1294641892351; Sun, 09 Jan 2011 22:44:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id i60sm16995307yhj.17.2011.01.09.22.44.50 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 22:44:51 -0800 (PST) Received: by iyi42 with SMTP id 42so19087511iyi.31 for ; Sun, 09 Jan 2011 22:44:50 -0800 (PST) Received: by 10.231.19.138 with SMTP id a10mr12132078ibb.127.1294641889990; Sun, 09 Jan 2011 22:44:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 22:44:19 -0800 (PST) In-Reply-To: <20110110063646.GJ5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> <20110110063646.GJ5743@1wt.eu> From: Adam Barth Date: Sun, 9 Jan 2011 22:44:19 -0800 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi , "Thomson, Martin" Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:42:44 -0000 Or we could just use AES-128-CTR like everyone else in the known universe and not worry about whether we've shaved exactly the right number of hairs off our home-brew pseudo crypto. Adam On Sun, Jan 9, 2011 at 10:36 PM, Willy Tarreau wrote: > On Mon, Jan 10, 2011 at 10:21:16AM +0800, Thomson, Martin wrote: >> On 2011-01-10 at 11:09:08, Willy Tarreau wrote: >> > willy@pcw:~/c$ time ./aes-128-ctr-get >> > Found the 'GET\n' pattern on the wire after 1608425803 bytes >> >> You might also find the collected works of Shakespeare in the byte strea= m had you waited a little longer. > > I know, that's just a matter of defining "a little longer", as none of us > will live long enough for that. > >> =A0I'm not sure what you are hoping to prove by searching. > > What I'm just showing is that we have the following points : > =A01) it was reported by an experiment that some caching intermediaries > =A0 =A0 were waiting for an HTTP request after the HTTP handshake was ove= r > > =A02) it was speculated that some lazy intermediaries might possibly skip > =A0 =A0 over whatever they did not understand to resync on an HTTP reques= t > =A0 =A0 they understand and execute it, hence the need for masking the > =A0 =A0 stream or payload. Please note that no such intermediary has even > =A0 =A0 been remotely detected, and that several people here who have > =A0 =A0 already been involved with server code expressed that making them > =A0 =A0 capable of doing so would be much more difficult than doing the > =A0 =A0 right thing and would not even respect the principle of laziness. > > =A03) it has been suggested that a simple 32-bit XOR was not enough and > =A0 =A0 that stronger cryptography was needed, because after a certain > =A0 =A0 number of attempts, the server might get the client to send a > =A0 =A0 request that such an intermediary can parse. > > =A04) it was reported that at least one intermediary (Apache) accepts > =A0 =A0 an HTTP/0.9 request as simple as "GET\n". > > =A05) it was shown that whatever algorithm we used to address the third > =A0 =A0 point was not enough to cover the second point for the supposedly > =A0 =A0 lazy intermediaries from #2 acting like Apache. > > So now, we have a choice : > =A0- either we agree that #2 above is not that much of a risk such that > =A0 =A0we don't need #3 to address it ; > > =A0- or we agree that #2 is still much of a concern, but as #4 is real, > =A0 =A0then #3 is not a valid solution, as was proven with #5, and we > =A0 =A0must use another one. > > But right now we're just complicating the protocol and removing some > possibilities of later extensions without addressing the reason why > we did that in the first place. > > Thanks, > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From gregw@intalio.com Sun Jan 9 22:48:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A463A693A for ; Sun, 9 Jan 2011 22:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opGRxnocAMCA for ; Sun, 9 Jan 2011 22:47:57 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0FF273A6934 for ; Sun, 9 Jan 2011 22:47:50 -0800 (PST) Received: by qwi2 with SMTP id 2so3737149qwi.31 for ; Sun, 09 Jan 2011 22:50:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.214.71 with SMTP id gz7mr13023484qab.349.1294642203588; Sun, 09 Jan 2011 22:50:03 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Sun, 9 Jan 2011 22:50:03 -0800 (PST) In-Reply-To: References: <20110109224228.GU5743@1wt.eu> Date: Mon, 10 Jan 2011 07:50:03 +0100 X-Google-Sender-Auth: TWJ4H_3qd3KY6SkR8Kf884IvG2Q Message-ID: From: Greg Wilkins To: ifette@google.com Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:48:15 -0000 2011/1/10 Ian Fette ($B%$%"%s%U%'%C%F%#(B) : >> - it has not yet been stated whether only the payload or also the framing >> should be masked. Your proposal masks both, which means that it >> definitely >> blocks any possibility of performing multiplexing later. There does not >> appear to have been a consensus in this area yet. >> > > I'm not sure why this would block the possibility of multiplexing. I would > agree that would be a problem if it were the case. However, a number of the > early proposals for multiplexing included something like a stream-id in the > frame. This could still be present. Though it would be masked, so would the > length and other things that a meaningful intermediary would care about, so > assuming the intermediary was capable of un-masking, is this an issue? I don't think it makes multiplexing impossible - just more difficult, more complex and more invasive. Multiplexing can no longer be just a channel label associated with each frame in a stream, because a frame stream will only be meaningful in the context of keys exchanged by a client and a server. Thus the key exchange will no longer be able to be end to end, and the multiplexer will need to be then end point of each connection from a client, so that it can initiate a new shared connection with a server with a new and different stream key applied to it. You then have to avoid the situation where the multiplexer has accepted a WS connection that the server does not want to accept - argh! all this for no actual benefit??? From w@1wt.eu Sun Jan 9 22:53:05 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4429A3A6A53 for ; Sun, 9 Jan 2011 22:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ0eD+QxAMKR for ; Sun, 9 Jan 2011 22:52:16 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 72DB73A6A5C for ; Sun, 9 Jan 2011 22:52:15 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A6s87M011718; Mon, 10 Jan 2011 07:54:08 +0100 Date: Mon, 10 Jan 2011 07:54:08 +0100 From: Willy Tarreau To: "Ian Fette (????????????????????????)" Message-ID: <20110110065408.GL5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:53:06 -0000 Hello Ian, On Sun, Jan 09, 2011 at 10:08:13PM -0800, Ian Fette (????????????????????????) wrote: > > - you're using the OPTIONS method. The WG's consensus was voted as using > > GET. While technically working, OPTIONS limits some possibilities since > > no path is sent to the server. > > > > > I agree it is important to be able to identify between various resources on > a server. E.g. for our use, we will have multiple different websocket > endpoints, and we want our frontend to be able to dispatch to the > appropriate backend based on the information in the handshake. That said, I > think the draft allows for that (Sec-WebSocket-URL), or as pointed out on > another thread, it appears OPTIONS does allow for a path component. So, I > think we should be able to resolve that point. Once again,I'm not opposed at all to this point. I'd even say that would it not have been accepted as a consensus in the last poll, I'd probably have voted for it. It's just that it's a change from what was planned till now and participants need to express their opinion on that point. > > - your proposal involves AES-128-CTR. As was discussed here, it seems > > there > > are still export regulations for certain countries eventhough they're > > apparently fading out. It could still be a problem for companies who > > want > > to export products to some countries and which never had to put crypto > > in > > them. > > > > It would be nice to understand if this is actually a hard constraint. > AES-128-CTR has the benefit of being well understood, as well as fast, as > demonstrated by Maciej in another thread. That said, I don't care strongly > one way or another here. One of my issue with it is that despite being fast, it's a lot slower than simpler masking. I design software components to be used at the border side of infrastructures to dispatch the traffic to multiple servers, and I'm very much concerned by the performance limitations. On a machine which has normally no issue processing 10 Gbps of HTTP, I could not even process 1 Gbps of WebSocket with large contents. This is much concerning because it implies that in order to build the stream analysers we've talked about in the past, it will become mandatory to install expensive crypto acceleration cards. This is not logical for a protocol which is supposed to be transferred in clear (ws:// as opposed to wss://). Checking for forbidden words, dangerous links or forbidden contents on campus sites will be much more expensive due to this masking algorithm alone. > > - several people on the list asked for the ability to be able to disable > > the masking in some well-controlled environments (eg: server-to-server > > communications). I see no provisions for this. > > > > > There's nothing that would prevent you from writing an extension that would > disable the masking, from my understanding. Adam did not seem favorable to that. > > - it has not yet been stated whether only the payload or also the framing > > should be masked. Your proposal masks both, which means that it > > definitely > > blocks any possibility of performing multiplexing later. There does not > > appear to have been a consensus in this area yet. > > > > > I'm not sure why this would block the possibility of multiplexing. I would > agree that would be a problem if it were the case. However, a number of the > early proposals for multiplexing included something like a stream-id in the > frame. This could still be present. Though it would be masked, so would the > length and other things that a meaningful intermediary would care about, so > assuming the intermediary was capable of un-masking, is this an issue? Yes, and you got the point : if the ID is masked, how to you know which stream it is in order to pick the right unmask key ? At least the stream ID will have to be unmasked. If we prepend it before the frame, it means a new framing format. Till not it was suggested to have it in the frame. > > - Greg proposed to replace the MORE bit with a FIN bit so that the first > > hello frame from the server starts with a high bit set, thus ensuring > > that we can break the connection on non-HTTP compliant intermediaries > > which would expect a second response after the 101. > > > > > The draft Adam sent out is based on an intermediate version I had checked > into SVN, back when it looked like we were gaining speed on CONNECT. I > didn't yet get around to flipping MORE/FIN, but I don't have any ojbections > to this. OK. > > Those are just a few notes, it's really not easy to changes :-/ > > > > There's a tool on the IETF to diff drafts. I find it quite helpful, that > said, a lot of text has changed because I had already started to make other > requested changes (including trying to resolve the HTTP compliance issue, by > stating the requirements of the handshake rather than stating send X bytes, > send Y bytes, ...). This makes the diff a bit harder to interpret, for sure. Ah, OK. Till now I'd only use the automated diffs between incremental drafts, I did not know that there were other tools. Regards, Willy From w@1wt.eu Sun Jan 9 22:56:14 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3DE3A693A for ; Sun, 9 Jan 2011 22:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyUKZ8d9alwo for ; Sun, 9 Jan 2011 22:56:13 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 3E7593A6935 for ; Sun, 9 Jan 2011 22:56:12 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A6wMXh011733; Mon, 10 Jan 2011 07:58:22 +0100 Date: Mon, 10 Jan 2011 07:58:22 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20110110065822.GM5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> <20110110063646.GJ5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi , "Thomson, Martin" Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:56:14 -0000 On Sun, Jan 09, 2011 at 10:44:19PM -0800, Adam Barth wrote: > Or we could just use AES-128-CTR like everyone else in the known > universe and not worry about whether we've shaved exactly the right > number of hairs off our home-brew pseudo crypto. Adam, I just explained that AES-128-CTR as you proposed it does not address the points that were raised which made it appear here. In fact the real problem we really want to solve is make the CR/LF bytes disappear from the stream. Those bytes are still present with AES-128-CTR. And if the risk suddenly becomes acceptable, then we can fallback to much simpler masking algorithm which share the same risks for that matter. > Adam Willy > > > On Sun, Jan 9, 2011 at 10:36 PM, Willy Tarreau wrote: > > On Mon, Jan 10, 2011 at 10:21:16AM +0800, Thomson, Martin wrote: > >> On 2011-01-10 at 11:09:08, Willy Tarreau wrote: > >> > willy@pcw:~/c$ time ./aes-128-ctr-get > >> > Found the 'GET\n' pattern on the wire after 1608425803 bytes > >> > >> You might also find the collected works of Shakespeare in the byte stream had you waited a little longer. > > > > I know, that's just a matter of defining "a little longer", as none of us > > will live long enough for that. > > > >>  I'm not sure what you are hoping to prove by searching. > > > > What I'm just showing is that we have the following points : > >  1) it was reported by an experiment that some caching intermediaries > >     were waiting for an HTTP request after the HTTP handshake was over > > > >  2) it was speculated that some lazy intermediaries might possibly skip > >     over whatever they did not understand to resync on an HTTP request > >     they understand and execute it, hence the need for masking the > >     stream or payload. Please note that no such intermediary has even > >     been remotely detected, and that several people here who have > >     already been involved with server code expressed that making them > >     capable of doing so would be much more difficult than doing the > >     right thing and would not even respect the principle of laziness. > > > >  3) it has been suggested that a simple 32-bit XOR was not enough and > >     that stronger cryptography was needed, because after a certain > >     number of attempts, the server might get the client to send a > >     request that such an intermediary can parse. > > > >  4) it was reported that at least one intermediary (Apache) accepts > >     an HTTP/0.9 request as simple as "GET\n". > > > >  5) it was shown that whatever algorithm we used to address the third > >     point was not enough to cover the second point for the supposedly > >     lazy intermediaries from #2 acting like Apache. > > > > So now, we have a choice : > >  - either we agree that #2 above is not that much of a risk such that > >    we don't need #3 to address it ; > > > >  - or we agree that #2 is still much of a concern, but as #4 is real, > >    then #3 is not a valid solution, as was proven with #5, and we > >    must use another one. > > > > But right now we're just complicating the protocol and removing some > > possibilities of later extensions without addressing the reason why > > we did that in the first place. > > > > Thanks, > > Willy > > > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi > > From ietf@adambarth.com Sun Jan 9 23:01:09 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7D73A6934 for ; Sun, 9 Jan 2011 23:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.885 X-Spam-Level: X-Spam-Status: No, score=-3.885 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obg1DocCFXD8 for ; Sun, 9 Jan 2011 23:01:07 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id ED70C3A6939 for ; Sun, 9 Jan 2011 23:01:06 -0800 (PST) Received: by gwj17 with SMTP id 17so10085916gwj.31 for ; Sun, 09 Jan 2011 23:03:19 -0800 (PST) Received: by 10.236.108.41 with SMTP id p29mr11171743yhg.68.1294642999317; Sun, 09 Jan 2011 23:03:19 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id 3sm16988458yhl.0.2011.01.09.23.03.17 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 23:03:18 -0800 (PST) Received: by iyi42 with SMTP id 42so19097403iyi.31 for ; Sun, 09 Jan 2011 23:03:17 -0800 (PST) Received: by 10.231.199.12 with SMTP id eq12mr28480723ibb.2.1294642997131; Sun, 09 Jan 2011 23:03:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 23:02:47 -0800 (PST) In-Reply-To: <20110110065822.GM5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> <20110110063646.GJ5743@1wt.eu> <20110110065822.GM5743@1wt.eu> From: Adam Barth Date: Sun, 9 Jan 2011 23:02:47 -0800 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi , "Thomson, Martin" Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 07:01:09 -0000 On Sun, Jan 9, 2011 at 10:58 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 10:44:19PM -0800, Adam Barth wrote: >> Or we could just use AES-128-CTR like everyone else in the known >> universe and not worry about whether we've shaved exactly the right >> number of hairs off our home-brew pseudo crypto. > > Adam, I just explained that AES-128-CTR as you proposed it does not > address the points that were raised which made it appear here. > > In fact the real problem we really want to solve is make the CR/LF > bytes disappear from the stream. Those bytes are still present with > AES-128-CTR. Fortunately, we don't need to make the CR/LF bytes disappear from the stream. What we need to do is prevent the attacker from choosing a string that can be used to attack an intermediary. Using AES-128-CTR makes it so the attacker is forced to choose a pseudo-random sequence of bytes. I claim that it is infeasible to attack an intermediary in this way using a pseudo-random sequence of bytes. Kind regards, Adam From w@1wt.eu Sun Jan 9 23:06:13 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16C23A693A for ; Sun, 9 Jan 2011 23:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju7YXWjVNx8X for ; Sun, 9 Jan 2011 23:06:11 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id E83EA3A6935 for ; Sun, 9 Jan 2011 23:06:10 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A78KVq011781; Mon, 10 Jan 2011 08:08:20 +0100 Date: Mon, 10 Jan 2011 08:08:20 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20110110070820.GN5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> <20110110063646.GJ5743@1wt.eu> <20110110065822.GM5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi , "Thomson, Martin" Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 07:06:13 -0000 On Sun, Jan 09, 2011 at 11:02:47PM -0800, Adam Barth wrote: > On Sun, Jan 9, 2011 at 10:58 PM, Willy Tarreau wrote: > > On Sun, Jan 09, 2011 at 10:44:19PM -0800, Adam Barth wrote: > >> Or we could just use AES-128-CTR like everyone else in the known > >> universe and not worry about whether we've shaved exactly the right > >> number of hairs off our home-brew pseudo crypto. > > > > Adam, I just explained that AES-128-CTR as you proposed it does not > > address the points that were raised which made it appear here. > > > > In fact the real problem we really want to solve is make the CR/LF > > bytes disappear from the stream. Those bytes are still present with > > AES-128-CTR. > > Fortunately, we don't need to make the CR/LF bytes disappear from the > stream. What we need to do is prevent the attacker from choosing a > string that can be used to attack an intermediary. Using AES-128-CTR > makes it so the attacker is forced to choose a pseudo-random sequence > of bytes. I claim that it is infeasible to attack an intermediary in > this way using a pseudo-random sequence of bytes. For short a string lengths accepted by Apache (4 bytes), it *is* feasible by making the client send an important amount of bytes as I have shown. If we agree that we don't need to protect against that very unlikely issue, then the simpler XOR masking is enough because the initial pseudo-random makes it equally hard for the attacker to guess what the stream will look like. Regards, Willy From ietf@adambarth.com Sun Jan 9 23:14:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0FAC3A6945 for ; Sun, 9 Jan 2011 23:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.879 X-Spam-Level: X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKmIPfkbYq7g for ; Sun, 9 Jan 2011 23:14:21 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9078E3A693A for ; Sun, 9 Jan 2011 23:14:21 -0800 (PST) Received: by gyd12 with SMTP id 12so8156968gyd.31 for ; Sun, 09 Jan 2011 23:16:34 -0800 (PST) Received: by 10.100.112.4 with SMTP id k4mr16830202anc.66.1294643794330; Sun, 09 Jan 2011 23:16:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id z12sm5855476anp.19.2011.01.09.23.16.32 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 23:16:33 -0800 (PST) Received: by iyi42 with SMTP id 42so19104694iyi.31 for ; Sun, 09 Jan 2011 23:16:32 -0800 (PST) Received: by 10.231.192.7 with SMTP id do7mr6209741ibb.102.1294643792127; Sun, 09 Jan 2011 23:16:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 23:16:01 -0800 (PST) In-Reply-To: <20110110070820.GN5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> <20110110063646.GJ5743@1wt.eu> <20110110065822.GM5743@1wt.eu> <20110110070820.GN5743@1wt.eu> From: Adam Barth Date: Sun, 9 Jan 2011 23:16:01 -0800 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi , "Thomson, Martin" Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 07:14:22 -0000 On Sun, Jan 9, 2011 at 11:08 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 11:02:47PM -0800, Adam Barth wrote: >> On Sun, Jan 9, 2011 at 10:58 PM, Willy Tarreau wrote: >> > On Sun, Jan 09, 2011 at 10:44:19PM -0800, Adam Barth wrote: >> >> Or we could just use AES-128-CTR like everyone else in the known >> >> universe and not worry about whether we've shaved exactly the right >> >> number of hairs off our home-brew pseudo crypto. >> > >> > Adam, I just explained that AES-128-CTR as you proposed it does not >> > address the points that were raised which made it appear here. >> > >> > In fact the real problem we really want to solve is make the CR/LF >> > bytes disappear from the stream. Those bytes are still present with >> > AES-128-CTR. >> >> Fortunately, we don't need to make the CR/LF bytes disappear from the >> stream. =A0What we need to do is prevent the attacker from choosing a >> string that can be used to attack an intermediary. =A0Using AES-128-CTR >> makes it so the attacker is forced to choose a pseudo-random sequence >> of bytes. =A0I claim that it is infeasible to attack an intermediary in >> this way using a pseudo-random sequence of bytes. > > For short a string lengths accepted by Apache (4 bytes), it *is* feasible > by making the client send an important amount of bytes as I have shown. > If we agree that we don't need to protect against that very unlikely issu= e, > then the simpler XOR masking is enough because the initial pseudo-random > makes it equally hard for the attacker to guess what the stream will look > like. I stand by my claim that it is infeasible to attack an intermediary in this way using a pseudo-random sequence of bytes. Your "attack" of finding the string "GET\n" after 1608425803 bytes (yes, that's 1.6 gigabytes) is meaningless. How many bytes do you think you'd have to examine before finding the string "Willy Tarreau" ? Kind regards, Adam From w@1wt.eu Sun Jan 9 23:50:07 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CCC28C0F2 for ; Sun, 9 Jan 2011 23:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBHU0vVdkkd7 for ; Sun, 9 Jan 2011 23:50:05 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id A382928C0E4 for ; Sun, 9 Jan 2011 23:50:02 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A7q8w0011903; Mon, 10 Jan 2011 08:52:08 +0100 Date: Mon, 10 Jan 2011 08:52:08 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20110110075208.GO5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> <20110110063646.GJ5743@1wt.eu> <20110110065822.GM5743@1wt.eu> <20110110070820.GN5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi , "Thomson, Martin" Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 07:50:07 -0000 On Sun, Jan 09, 2011 at 11:16:01PM -0800, Adam Barth wrote: > On Sun, Jan 9, 2011 at 11:08 PM, Willy Tarreau wrote: > > On Sun, Jan 09, 2011 at 11:02:47PM -0800, Adam Barth wrote: > >> On Sun, Jan 9, 2011 at 10:58 PM, Willy Tarreau wrote: > >> > On Sun, Jan 09, 2011 at 10:44:19PM -0800, Adam Barth wrote: > >> >> Or we could just use AES-128-CTR like everyone else in the known > >> >> universe and not worry about whether we've shaved exactly the right > >> >> number of hairs off our home-brew pseudo crypto. > >> > > >> > Adam, I just explained that AES-128-CTR as you proposed it does not > >> > address the points that were raised which made it appear here. > >> > > >> > In fact the real problem we really want to solve is make the CR/LF > >> > bytes disappear from the stream. Those bytes are still present with > >> > AES-128-CTR. > >> > >> Fortunately, we don't need to make the CR/LF bytes disappear from the > >> stream.  What we need to do is prevent the attacker from choosing a > >> string that can be used to attack an intermediary.  Using AES-128-CTR > >> makes it so the attacker is forced to choose a pseudo-random sequence > >> of bytes.  I claim that it is infeasible to attack an intermediary in > >> this way using a pseudo-random sequence of bytes. > > > > For short a string lengths accepted by Apache (4 bytes), it *is* feasible > > by making the client send an important amount of bytes as I have shown. > > If we agree that we don't need to protect against that very unlikely issue, > > then the simpler XOR masking is enough because the initial pseudo-random > > makes it equally hard for the attacker to guess what the stream will look > > like. > > I stand by my claim that it is infeasible to attack an intermediary in > this way using a pseudo-random sequence of bytes. > > Your "attack" of finding the string "GET\n" after 1608425803 bytes > (yes, that's 1.6 gigabytes) is meaningless. Precisely, and it is as much meaningless as finding it after the same amount of bytes using a simple XOR method with a 32-bit key. That was the point I wanted to make, because at one point it was speculated in the 32-bit vs HMAC that it was a concern. So now we can move on to simpler algorithms and stop cripling the protocol. Thanks, Willy From ietf@adambarth.com Sun Jan 9 23:54:11 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5B13A6A69 for ; Sun, 9 Jan 2011 23:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.873 X-Spam-Level: X-Spam-Status: No, score=-3.873 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW2kFBUr78Uq for ; Sun, 9 Jan 2011 23:54:10 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 936933A6A64 for ; Sun, 9 Jan 2011 23:54:10 -0800 (PST) Received: by yxt33 with SMTP id 33so8389216yxt.31 for ; Sun, 09 Jan 2011 23:56:23 -0800 (PST) Received: by 10.151.106.7 with SMTP id i7mr27308201ybm.421.1294646182972; Sun, 09 Jan 2011 23:56:22 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id v6sm1954945ybk.20.2011.01.09.23.56.21 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 23:56:22 -0800 (PST) Received: by iwn40 with SMTP id 40so20197535iwn.31 for ; Sun, 09 Jan 2011 23:56:20 -0800 (PST) Received: by 10.231.192.7 with SMTP id do7mr6239483ibb.102.1294646180674; Sun, 09 Jan 2011 23:56:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Sun, 9 Jan 2011 23:55:50 -0800 (PST) In-Reply-To: <20110110075208.GO5743@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> <20110110063646.GJ5743@1wt.eu> <20110110065822.GM5743@1wt.eu> <20110110070820.GN5743@1wt.eu> <20110110075208.GO5743@1wt.eu> From: Adam Barth Date: Sun, 9 Jan 2011 23:55:50 -0800 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi , "Thomson, Martin" Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 07:54:11 -0000 On Sun, Jan 9, 2011 at 11:52 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 11:16:01PM -0800, Adam Barth wrote: >> On Sun, Jan 9, 2011 at 11:08 PM, Willy Tarreau wrote: >> > On Sun, Jan 09, 2011 at 11:02:47PM -0800, Adam Barth wrote: >> >> On Sun, Jan 9, 2011 at 10:58 PM, Willy Tarreau wrote: >> >> > On Sun, Jan 09, 2011 at 10:44:19PM -0800, Adam Barth wrote: >> >> >> Or we could just use AES-128-CTR like everyone else in the known >> >> >> universe and not worry about whether we've shaved exactly the righ= t >> >> >> number of hairs off our home-brew pseudo crypto. >> >> > >> >> > Adam, I just explained that AES-128-CTR as you proposed it does not >> >> > address the points that were raised which made it appear here. >> >> > >> >> > In fact the real problem we really want to solve is make the CR/LF >> >> > bytes disappear from the stream. Those bytes are still present with >> >> > AES-128-CTR. >> >> >> >> Fortunately, we don't need to make the CR/LF bytes disappear from the >> >> stream. =A0What we need to do is prevent the attacker from choosing a >> >> string that can be used to attack an intermediary. =A0Using AES-128-C= TR >> >> makes it so the attacker is forced to choose a pseudo-random sequence >> >> of bytes. =A0I claim that it is infeasible to attack an intermediary = in >> >> this way using a pseudo-random sequence of bytes. >> > >> > For short a string lengths accepted by Apache (4 bytes), it *is* feasi= ble >> > by making the client send an important amount of bytes as I have shown= . >> > If we agree that we don't need to protect against that very unlikely i= ssue, >> > then the simpler XOR masking is enough because the initial pseudo-rand= om >> > makes it equally hard for the attacker to guess what the stream will l= ook >> > like. >> >> I stand by my claim that it is infeasible to attack an intermediary in >> this way using a pseudo-random sequence of bytes. >> >> Your "attack" of finding the string "GET\n" after 1608425803 bytes >> (yes, that's 1.6 gigabytes) is meaningless. > > Precisely, and it is as much meaningless as finding it after the same > amount of bytes using a simple XOR method with a 32-bit key. That was > the point I wanted to make, because at one point it was speculated > in the 32-bit vs HMAC that it was a concern. > > So now we can move on to simpler algorithms and stop cripling the > protocol. Or we could just use AES-128-CTR like everyone else in the known universe and not worry about whether we've shaved exactly the right number of hairs off our home-brew pseudo crypto. Adam From gregw@intalio.com Mon Jan 10 01:05:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3DF28C0F6 for ; Mon, 10 Jan 2011 01:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRKi9N0kDNDQ for ; Mon, 10 Jan 2011 01:05:53 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id E720528C0ED for ; Mon, 10 Jan 2011 01:05:52 -0800 (PST) Received: by qwi2 with SMTP id 2so3828668qwi.31 for ; Mon, 10 Jan 2011 01:08:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.36.208 with SMTP id u16mr26652569qad.299.1294650485674; Mon, 10 Jan 2011 01:08:05 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Mon, 10 Jan 2011 01:08:05 -0800 (PST) In-Reply-To: References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> Date: Mon, 10 Jan 2011 10:08:05 +0100 X-Google-Sender-Auth: lIIM6SCooT2je6TZiMBS5SMJM74 Message-ID: From: Greg Wilkins To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 09:05:53 -0000 On 9 January 2011 16:14, Eric Rescorla wrote: > On Sun, Jan 9, 2011 at 1:43 AM, Greg Wilkins wrote: >> > > Wow, I think you have this completely backwards: it's in systems that > do almost nothing > that the cost of adding a new, expensive operation is large. In > systems that are already > doing a lot of other processing, the marginal cost is comparaitvely > low even though it may > occasionally push you over some threshold; Amdahl's law and all that. Eric, I did not say system that are "already doing a lot of other processing", I said systems where parsing is around 5% of the CPU load. This may be for a high message rate on a large server or it may be for a low message rate on a constrained device. For such systems, multiplying the CPU work needed to parse a message several times will have significant impacts. Besides, it is self evident that adding cryptographic processing to a protocol puts additional loads on application servers - we need only look at SSL and the existence of SSL offload devices. regards From gregw@intalio.com Mon Jan 10 01:13:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CBAA28C11A for ; Mon, 10 Jan 2011 01:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-VD7NddSYUg for ; Mon, 10 Jan 2011 01:12:57 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 2BEBA28C0ED for ; Mon, 10 Jan 2011 01:12:56 -0800 (PST) Received: by qyj19 with SMTP id 19so20682975qyj.10 for ; Mon, 10 Jan 2011 01:15:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.53.213 with SMTP id n21mr26710032qag.399.1294650905892; Mon, 10 Jan 2011 01:15:05 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Mon, 10 Jan 2011 01:15:05 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Jan 2011 10:15:05 +0100 X-Google-Sender-Auth: y3kVSJHO1w93OK3eLDToTAR1T3s Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 09:13:28 -0000 On 10 January 2011 01:46, Adam Barth wrote: > Thanks for your feedback. =A0I'd encourage you not to implement this > protocol then. Note also that this discussion is not about implementation. If browsers implement some protocol, then the servers and intermediaries will do their best to support it as we have always done, no matter how ill conceived the ideas or how little the server side concerns have been considered. But implementation is entirely different to standardisation, which is the point of the discussions here. The get standardisation at the IETF, you need consensus from all the main constituencies and from the wider IETF community. If the browser vendors chose to ignore the concerns of the intermediaries and server side, that does not make those concerns go away - they remain and almost certainly means will be found to address them that will in all probability be proprietary and/or disparate, thus making the chances of WS becoming an IETF standard even less likely. From w@1wt.eu Mon Jan 10 02:48:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7138228C138 for ; Mon, 10 Jan 2011 02:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0VdUrCRfoL6 for ; Mon, 10 Jan 2011 02:48:38 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 678B628C137 for ; Mon, 10 Jan 2011 02:48:37 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0AAoiBj012431; Mon, 10 Jan 2011 11:50:44 +0100 Date: Mon, 10 Jan 2011 11:50:44 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20110110105044.GA12428@1wt.eu> References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> <20110110063646.GJ5743@1wt.eu> <20110110065822.GM5743@1wt.eu> <20110110070820.GN5743@1wt.eu> <20110110075208.GO5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi , "Thomson, Martin" Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 10:48:39 -0000 On Sun, Jan 09, 2011 at 11:55:50PM -0800, Adam Barth wrote: > Or we could just use AES-128-CTR like everyone else in the known > universe and not worry about whether we've shaved exactly the right > number of hairs off our home-brew pseudo crypto. To the best of my knowledge, HTTP itself does not make use of AES-128-CTR when posting data, nor when using PUT to send a file, despite some implementations not being aware of this method. Willy From dave@cridland.net Mon Jan 10 04:35:34 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB5E28C148 for ; Mon, 10 Jan 2011 04:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9e34SfgijGq for ; Mon, 10 Jan 2011 04:35:32 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 1E9BA28C133 for ; Mon, 10 Jan 2011 04:35:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 9E24C116811D; Mon, 10 Jan 2011 12:37:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InOcFfoV4a9R; Mon, 10 Jan 2011 12:37:40 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id CAE6411680FB; Mon, 10 Jan 2011 12:37:39 +0000 (GMT) References: <20110106221426.GA28367@1wt.eu> <20110107053410.GG28367@1wt.eu> <20110107061043.GJ28367@1wt.eu> <20110107063854.GN28367@1wt.eu> <4D26D20C.8030906@warmcat.com> <10468.1294391783.740346@puncture> <20110107100313.GO28367@1wt.eu> <10468.1294398928.011152@puncture> <4D28AE05.4070500@callenish.com> In-Reply-To: <4D28AE05.4070500@callenish.com> MIME-Version: 1.0 Message-Id: <2948.1294663059.826493@puncture> Date: Mon, 10 Jan 2011 12:37:39 +0000 From: Dave Cridland To: Bruce Atherton , Server-Initiated HTTP Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] A bit of pragmatism / intermediary triage X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 12:35:34 -0000 On Sat Jan 8 18:33:41 2011, Bruce Atherton wrote: > On 07/01/2011 3:15 AM, Dave Cridland wrote: >> >> Would the working group consider masking in this parallel >> universe? Of course not, because that would be silly. > > I disagree. I think an argument can be made for masking even in the > absence of a known attack. Call me silly if you want to. > > Given you've granted me permission, then, yes. You're being silly. > The question is how much are we willing to pay for a benefit that > we can't quantify and that may never appear. Hopefully, if there > were no cost at all to masking you would not have an issue with it. > As the cost goes up, we start seeing more and more people decide > that the price is too high for a risk that is so nebulous. So there > is a real incentive to keeeping the cost of masking low, to me. > > The other question is whether we can eliminate that cost altogether > in situations where we can guarantee via other means that attackers > are not controlling the bits. > > This is all reasonable. >> intermediaries that are already vulnerable to attacks of the form >> we're trying to protect against by using Flash or Java. > > I keep seeing comparisons of Websockets to Flash and Java. These > are not even close to being the same situation. > > Browser vendors do not develop Flash or Java plugins. They do not > ship with them. Many environments forbid the installation of any > plugins for exactly the reason that Flash and Java are security > risks. When a user installs the plugin, they have to take > responsibility for doing so, and any bugs or security issues are > directed to Adobe or Oracle or whoever developed the plugin. > > Websockets is different. Websockets is going to be part of the > browser. The browser vendors are going to ship their own code. That > means that they are responsible for Websockets, as they are not > responsible for Flash and Java. It also means that browsers will > always have an implementation of Websockets installed in all > environments, including the ones that don't allow plugins (although > they may be configured to turn it off). > > What this is saying is that the reasoning for masking is *not* technical, but political. From a technical standpoint, Flash and Java both allow the attack against the intermediaries to be mounted with a far higher degree of success. >> (And, maybe, ActiveX?) One assumes that, therefore, these will be >> fixed, and not just due to websockets, but due to the far more >> widely used rich content technologies of today. > > That seems to be false given that they haven't been fixed to date. > I doubt that any browser vendor wants to take the risk and assume > they will be fixed, only to see themselves labeled "Insecure" by > people who don't understand where the real security vulnerability > was. > > I think it's far too early to be considered false. It'll only take one widely publicised case and a testing tool, and the vast majority of intermediaries will be fixed. The widely publicised case is far more likely to be Flash based than anything else, too. > This is a known vulnerability. No major browser vendor is going to > ship a Websockets implementation that is exposed to it. They have > all said so on this list. Let's move on. Well, as responsible browser vendors, they could just ship with a built-in test tool which checked for a vulnerable intermediary on startup and disable WebSockets if one is found - it'd only take a couple of seconds to test at worst. But instead they seem to want to ship with a truly bizarre overhead of questionable merit. Since this is no longer a technical argument, I'll refrain from attempting to apply technical reasoning, though. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dave@cridland.net Mon Jan 10 04:48:26 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CB728C142 for ; Mon, 10 Jan 2011 04:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ea-6q2UUm4ZN for ; Mon, 10 Jan 2011 04:48:25 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id A3B2628C156 for ; Mon, 10 Jan 2011 04:48:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8D45E1168117; Mon, 10 Jan 2011 12:50:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2mxl3uPQPEQ; Mon, 10 Jan 2011 12:50:32 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 3C86A11680FB; Mon, 10 Jan 2011 12:50:32 +0000 (GMT) References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> In-Reply-To: MIME-Version: 1.0 Message-Id: <2948.1294663832.250014@puncture> Date: Mon, 10 Jan 2011 12:50:32 +0000 From: Dave Cridland To: Maciej Stachowiak , Server-Initiated HTTP , Willy Tarreau Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 12:48:26 -0000 On Sun Jan 9 19:44:45 2011, Maciej Stachowiak wrote: > I remember that being said, but I am skeptical. My understanding of > US crypto export regulations is that merely using existing crypto > facilities from the operating system or from separate components is > not subject to export limitations. AES-CTR is in libcrypto which is > widely available all over the world. I'm skeptical that there is > any place in the world where you can easily use SHA1 HMAC but not > AES-CTR. So if anyone wants to claim that use of AES-CTR would > cause problems with export regulations, I would ask them to > substantiate that claim. > > I can only repeat that in the UK, we must ship software such that high-grade encryption algorithm support can be disabled, by government regulations. Using AES-CTR as a masking algorithm would prevent us from shipping with WebSocket support. > Even if the export considerations do turn out to be real, AES-CTR > has better security properties and considerably better performance > than HMAC. I don't think we should let the legal regime around > crypto limit the quality of the protocol. Perhaps not, but it would affect the deployment. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From gregw@intalio.com Mon Jan 10 06:05:37 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D591F3A69A0 for ; Mon, 10 Jan 2011 06:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4VbMe2XO-cq for ; Mon, 10 Jan 2011 06:05:37 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id DDBF33A6834 for ; Mon, 10 Jan 2011 06:05:36 -0800 (PST) Received: by qwi2 with SMTP id 2so4095494qwi.31 for ; Mon, 10 Jan 2011 06:07:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.36.208 with SMTP id u16mr26913826qad.299.1294668470387; Mon, 10 Jan 2011 06:07:50 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Mon, 10 Jan 2011 06:07:50 -0800 (PST) In-Reply-To: <4D2A4FFE.6000503@callenish.com> References: <4D2A4FFE.6000503@callenish.com> Date: Mon, 10 Jan 2011 15:07:50 +0100 X-Google-Sender-Auth: CEBjSrFhZta1zMoRDEZHZsKnBWM Message-ID: From: Greg Wilkins To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Summary of issues concerning the default masking algorithm X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 14:05:37 -0000 IMNSHO: > a) The client nonce should influence the mask PROS: None that I can think of over a good random mask CONS: Makes the mask stream dependent, preventing debugging of partial streams. If masking is applied to framing, this make multiplexing and debugging significantly more complex. > b) The server nonce should influence the mask same as a) > c) The mask should be kept off the wire by generating the mask using a > shared secret same as a) > d) The attacker should not only be prevented from controlling the bits, but > also the pattern of bits Not sure what this means? If it is referring to using and algorithm such that the a mask pattern does not repeat PROS: Increases the data that must be sent to achieve some plain text from a huge amount to a humongous amount. CONS: Only increases the data that must be sent and does not actually prevent any clear text data. > e) masking the framing as well as the payload. PROS: none that I can think of CONS: makes decoding framing more complex. Means that all WS aware code must implement the specific masking algorithm, which effectively means that it will never be able to be turned off. > f) making masking use the current frame extension mechanism PROS: Puts masking inside the frame, so avoids CONS of e). Validates the extension mechanism. Allows intermediaries that do not care about payload to ignore masking. CONS: None that I can think of. > g) make masking be a negotiated extension (either to turn it on or off) PROS: Allows crypto agility. Allows no masking deployments. CONS: An extension negotiation mechanism will need to be implemented. Slightly more verbose handshake. From ekr@rtfm.com Mon Jan 10 07:37:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2380D3A67ED for ; Mon, 10 Jan 2011 07:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5jZbnXwxTIV for ; Mon, 10 Jan 2011 07:37:02 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id B555528C10C for ; Mon, 10 Jan 2011 07:37:02 -0800 (PST) Received: by gxk28 with SMTP id 28so9004786gxk.31 for ; Mon, 10 Jan 2011 07:39:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.64.2 with SMTP id r2mr6320880agk.133.1294673955918; Mon, 10 Jan 2011 07:39:15 -0800 (PST) Received: by 10.90.154.19 with HTTP; Mon, 10 Jan 2011 07:39:14 -0800 (PST) In-Reply-To: References: <4D26605B.1090409@callenish.com> <4D26DE2D.5040901@ericsson.com> Date: Mon, 10 Jan 2011 07:39:14 -0800 Message-ID: From: Eric Rescorla To: Brodie Thiesfield Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:37:04 -0000 On Sun, Jan 9, 2011 at 7:00 PM, Brodie Thiesfield wrote: > Where clients aren't behind NAT a direct connection can be used, when > they are then a central hub relay. A better approach is to actually do hole punching. Seriously, there is already IETF work being spun up in this area. It will be informed by this WG, but it's a different set of problems. Given that it's out of scope for this WG, we really should not be considering it. -Ekr More complex schemes could be added > later, however simply trying for a direct connection and falling back > to a central relay is possible with the existing protocol. > > However this problem is solved though, we will still have a client is > acting as a server and (I am assuming) that client will still want to > send masked data too. In the case of direct connection, where no > central server can modify the data stream, the client on the other end > must unmask the data coming from the server. So the most basic support > for p2p with the current protocol maintaining security guarantees > would only require a client to be able to accept either masked or > unmasked responses from the server. > > The security paranoid could then also optionally configure a server to > send masked responses (if supported). > > Regards, > Brodie > > > On Mon, Jan 10, 2011 at 11:39 AM, Eric Rescorla wrote: >> Not really. Meaningful p2p operation requires nat traversal >> >> Ekr >> >> On Jan 9, 2011, at 17:02, Brodie Thiesfield wrote: >> >>> I understand that this can be addressed later, however supporting peer >>> to peer in the protocol appears to only require a client to also >>> support the optional masking of the server responses. >>> >>> In the case of a browser acting as the server, it will need to >>> implement the server side of things like handshake and unmasking >>> client messages. However, given that it is really also a client (with >>> the same unknown intermediataries, etc), I assume that it would be >>> desirable to have the same security protections as a simple client, >>> and so it would also want to send messages using masking. >>> >>> As long as simple clients can also receive messages from a server with >>> masking enabled, then there appears to be no reason that peer to peer >>> wouldn't work with the same security guarantees (for the protocol) >>> that client->server does. >>> >>> i.e. >>> client -> server = masked >>> server -> client = cleartext | masked >>> >>> How the server notifies the client that it is going to send masked >>> responses remains unspecified. >>> >>> Regards, >>> Brodie >>> >>> >>> On Fri, Jan 7, 2011 at 7:34 PM, Salvatore Loreto >>> wrote: >>>> On 1/7/11 2:23 AM, John Tamplin wrote: >>>> >>>> On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton wrote: >>>>> >>>>> So far it appears that Greg, Brodie, Jerod, and I favour including >>>>> peer-to-peer design considerations in the spec. I am not sure, but it sounds >>>>> like John considers it out of scope and Scott considers it in scope. What >>>>> about the rest of you? >>>> >>>> I am not opposed to it exactly, but given how long everything has taken I am >>>> keen to keep the base protocol minimal so we can actually get something out >>>> the door. >>>> >>>> I agree with John, >>>> lets keep the base protocol minimal at moment. >>>> Once we have reached consensus on the minimal base protocol we can >>>> start to add other stuff on top of the minimal base. >>>> >>>> If there is consensus in doing something in the future we can track it in >>>> the issue tracker >>>> so we won't forget. >>>> >>>> >>>> cheers >>>> /Sal >>>> >>>> -- >>>> Salvatore Loreto >>>> www.sloreto.com >>>> >>>> _______________________________________________ >>>> hybi mailing list >>>> hybi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hybi >>>> >>>> >>> _______________________________________________ >>> hybi mailing list >>> hybi@ietf.org >>> https://www.ietf.org/mailman/listinfo/hybi >> > From ekr@rtfm.com Mon Jan 10 07:38:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B13528C10C for ; Mon, 10 Jan 2011 07:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsa5FWoLzDqZ for ; Mon, 10 Jan 2011 07:38:18 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 4C3A828B56A for ; Mon, 10 Jan 2011 07:38:18 -0800 (PST) Received: by gwj17 with SMTP id 17so10240029gwj.31 for ; Mon, 10 Jan 2011 07:40:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.64.2 with SMTP id r2mr6322093agk.133.1294674032018; Mon, 10 Jan 2011 07:40:32 -0800 (PST) Received: by 10.90.154.19 with HTTP; Mon, 10 Jan 2011 07:40:31 -0800 (PST) In-Reply-To: References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> Date: Mon, 10 Jan 2011 07:40:31 -0800 Message-ID: From: Eric Rescorla To: Greg Wilkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Masking overhead with measurements and code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:38:19 -0000 On Mon, Jan 10, 2011 at 1:08 AM, Greg Wilkins wrote: > On 9 January 2011 16:14, Eric Rescorla wrote: >> On Sun, Jan 9, 2011 at 1:43 AM, Greg Wilkins wrote: >>> >> >> Wow, I think you have this completely backwards: it's in systems that >> do almost nothing >> that the cost of adding a new, expensive operation is large. In >> systems that are already >> doing a lot of other processing, the marginal cost is comparaitvely >> low even though it may >> occasionally push you over some threshold; Amdahl's law and all that. > > > Eric, > > I did not say system that are "already doing a lot of other > processing", I said systems where parsing is around 5% of the CPU > load. =A0 This may be for a high message rate on a large server or it > may be for a low message rate on a constrained device. =A0 For such > systems, multiplying the CPU work needed to parse a message several > times will have significant impacts. > > Besides, it is self evident that adding cryptographic processing to a > protocol puts additional loads on application servers - we need only > look at SSL and the existence of SSL offload devices. Funny you should mention that: all measurements show that the dominant cost of TLS is the RSA key exchange, which is why it's such a common strategy no= t to accelerate the symmetric cryptography at all. -Ekr From ekr@rtfm.com Mon Jan 10 07:40:41 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDAC03A67FC for ; Mon, 10 Jan 2011 07:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JSkdi+q255p for ; Mon, 10 Jan 2011 07:40:41 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id E7A643A67ED for ; Mon, 10 Jan 2011 07:40:40 -0800 (PST) Received: by yie19 with SMTP id 19so6255318yie.31 for ; Mon, 10 Jan 2011 07:42:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.26.24 with SMTP id d24mr6362976agj.160.1294674174656; Mon, 10 Jan 2011 07:42:54 -0800 (PST) Received: by 10.90.154.19 with HTTP; Mon, 10 Jan 2011 07:42:54 -0800 (PST) In-Reply-To: <2948.1294663832.250014@puncture> References: <20110108111632.GI2479@1wt.eu> <1294531527.7650.535.camel@ds9.ducksong.com> <56F80FB9-DAAD-40CA-92E8-21390546851B@apple.com> <20110109143423.GM5743@1wt.eu> <2948.1294663832.250014@puncture> Date: Mon, 10 Jan 2011 07:42:54 -0800 Message-ID: From: Eric Rescorla To: Dave Cridland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Server-Initiated HTTP Subject: Re: [hybi] AES-CTR is darned fast (was Re: Masking overhead with measurements and code) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:40:41 -0000 On Mon, Jan 10, 2011 at 4:50 AM, Dave Cridland wrote: > On Sun Jan =A09 19:44:45 2011, Maciej Stachowiak wrote: >> >> I remember that being said, but I am skeptical. My understanding of US >> crypto export regulations is that merely using existing crypto facilitie= s >> from the operating system or from separate components is not subject to >> export limitations. AES-CTR is in libcrypto which is widely available al= l >> over the world. I'm skeptical that there is any place in the world where= you >> can easily use SHA1 HMAC but not AES-CTR. So if anyone wants to claim th= at >> use of AES-CTR would cause problems with export regulations, I would ask >> them to substantiate that claim. >> >> > I can only repeat that in the UK, we must ship software such that high-gr= ade > encryption algorithm support can be disabled, by government regulations. I don't mean to be flat-out contradictory, but I'd like to see a legal opinion on this point, because at least in the US, the use to which you are putting encryption matters, and this use would be fine. -Ekr From ekr@rtfm.com Mon Jan 10 07:41:38 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399E33A67FC for ; Mon, 10 Jan 2011 07:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zl1pRj91Ot1 for ; Mon, 10 Jan 2011 07:41:37 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 603633A67ED for ; Mon, 10 Jan 2011 07:41:37 -0800 (PST) Received: by yxt33 with SMTP id 33so8534493yxt.31 for ; Mon, 10 Jan 2011 07:43:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.83.18 with SMTP id k18mr6263131agl.79.1294674231077; Mon, 10 Jan 2011 07:43:51 -0800 (PST) Received: by 10.90.154.19 with HTTP; Mon, 10 Jan 2011 07:43:50 -0800 (PST) In-Reply-To: <20110110063930.GK5743@1wt.eu> References: <4D2A4FFE.6000503@callenish.com> <4D2A6FB9.1030005@callenish.com> <20110110063930.GK5743@1wt.eu> Date: Mon, 10 Jan 2011 07:43:50 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] Summary of issues concerning the default masking algorithm X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:41:38 -0000 On Sun, Jan 9, 2011 at 10:39 PM, Willy Tarreau wrote: > On Sun, Jan 09, 2011 at 06:32:25PM -0800, Bruce Atherton wrote: >> The cost of losing the ability to decode streams is, to me, extremely >> high. It is beyond that, it is painful. When I have to debug a network >> issue in a customer's environment, a problem that would take me a few >> hours with a decoded stream jumps to days or even weeks. What is worse >> is that it is often difficult if not impossible to demonstrate to the >> customer when the issue is not with my application. Although I can >> create multitudes of logs that show all the bits my application receives >> and sends, the customer has no way of knowing whether there are bits >> that are not logged because they are dealt with via another code path. > > +1, that's an experience I share all the day too the other way around, > proving from network captures that the application is faulty, despite > how expensive it was ! Building tools to process this kind of masked data is trivial. Heck, tools to decode full SSL aren't even that hard. I know because I've built them. -Ekr From ekr@rtfm.com Mon Jan 10 07:50:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929453A69A0 for ; Mon, 10 Jan 2011 07:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.658 X-Spam-Level: X-Spam-Status: No, score=-102.658 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emJpQ+iNV38Z for ; Mon, 10 Jan 2011 07:50:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 9AD3D3A6973 for ; Mon, 10 Jan 2011 07:50:36 -0800 (PST) Received: by gxk28 with SMTP id 28so9010487gxk.31 for ; Mon, 10 Jan 2011 07:52:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.67.10 with SMTP id u10mr6305478agk.187.1294674770187; Mon, 10 Jan 2011 07:52:50 -0800 (PST) Received: by 10.90.154.19 with HTTP; Mon, 10 Jan 2011 07:52:50 -0800 (PST) In-Reply-To: <20110109175118.GP5743@1wt.eu> References: <20110109175118.GP5743@1wt.eu> Date: Mon, 10 Jan 2011 07:52:50 -0800 Message-ID: From: Eric Rescorla To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:50:39 -0000 On Sun, Jan 9, 2011 at 9:51 AM, Willy Tarreau wrote: > The server will check the input stream, looking for the bytes "G" and "E"= . > If those bytes do not appear, it will terminate the connection because it > means this connection will require too many blocks to get the correct val= ues. Nice observation. I haven't gotten too much sleep but... As I understand your attack, the way this works is that you're exploiting the fact that the server gets information about the repeating mask to shut down unproduct= ive byte sequences before they have been transmitted over the wire. This makes = sense if you think that the network transmission is the rate limiting step. The obvious countermeasure to this is to ensure that the server doesn't learn anything useful prior to receiving the whole packet. This can't be done with a fixed mask for the reasons you indicate but can be done with a generated mask, I believe. Consider the packet structure (omitting most framing bits) AES-CTR(K_msg, Payload) || K_msg In this case, no matter how much information the attacker has about payload byte i, he doesn't learn anything useful about expected ciphertext (transmitted) byte i+1 until the key is received (this is by definitional properties of AES-CTR). So, the bytestream on the wire is indistinguishable from random, precluding the attack you describe. The major cost is that an ordinary server cannot start processing the message until the per-msg key is received at the end, but since we've already disclaimed most streaming modes of operation (and the client can't stream anyway because of the need to commit to the packet contents), this seems like a relatively minor cost. This attack seems to me like it makes full-length masking more attractive. Best, -Ekr > The 160-bit mask offers us the ability to find the required pattern a lot > faster, because in each connections, this fixed mask can in fact be seen = as 5 > indepedant 32-bit masks. The net effect it that it divides by 5 the numbe= r of > required connections to get the expected bytes (in practice, it is possib= le to > achieve the same optimization with a smaller mask, it just requires the c= lient > to send multiple different patterns). On average, 65536/5 =3D 13107 conne= ctions > are required to get a candidate connection. > > If the server finds that the XOR mask will make "G" and "E" appear, then = it > reads the stream so that the client emits all possible combinations of 3r= d > and 4th chars, which means that at most 20*65536 =3D 1.3 Megabytes are re= quired > once a candidate connection is found. > > The ws-attack program contains both the client and the server code. For t= he > sake of simplicity, it does not do any networking, but it is designed wit= h > clearly distinct parts which communicate via a sequentially accessed buff= er, > so that the roles are more easily identifiable and both could be split if > required. > > Results : > > =A0 The program can be downloaded at http://1wt.eu/websocket/ws-attack.c > > willy@pcw:~/c$ time ./ws-attack > Found pattern 'GET\n' at block 172226 after 6615 connections and 1469504 = bytes sent > > real =A0 =A00m0.030s > user =A0 =A00m0.032s > sys =A0 =A0 0m0.000s > willy@pcw:~/c$ time ./ws-attack > Found pattern 'GET\n' at block 207343 after 16071 connections and 1696448= bytes sent > > real =A0 =A00m0.069s > user =A0 =A00m0.068s > sys =A0 =A0 0m0.000s > willy@pcw:~/c$ time ./ws-attack > Found pattern 'GET\n' at block 150470 after 95 connections and 1313024 by= tes sent > > real =A0 =A00m0.003s > user =A0 =A00m0.000s > sys =A0 =A0 0m0.004s > willy@pcw:~/c$ time ./ws-attack > Found pattern 'GET\n' at block 139582 after 28577 connections and 1996592= bytes sent > > real =A0 =A00m0.119s > user =A0 =A00m0.116s > sys =A0 =A0 0m0.008s > > > Conclusion : > > Between 1.3 and 1.9 MB of framing data were required to get the expected > request the masking method was supposed to prevent from appearing. > > A sliding self-regenerating mask would only make it slightly harder for t= he > server to decide upon accepting or rejecting the connection, because once= it > gets the seed, it can locally simulate the emitted stream to find whether= the > pattern will appear or not, but the improvement is not significant. > > All in all, we see that we still need the client to send megabytes of dat= a > to make a short request pop up. It is extremely unlikely that any caching > intermediary would skip over that amount of data to spot a valid request,= and > it is contrary to the principle of lazyness because implementing such one= is > a lot harder than making it do the right thing. BTW, no such intermediary= has > yet been detected nor identified. > > All the issues always converge to the same point : avoiding the LF charac= ter > (and possibly the CR) in the WS stream. But that's not easy or it require= s > more expensive escaping or encoding (eg: base64). > > Proposals : > > =A01) keep the XOR-based masking with a simpler key generation algorithm = to > =A0 =A0keep the per-frame masking cost low. An improvement might also con= sist > =A0 =A0in avoiding the LF character in the key. > > =A02) use a more expensive LF-less masking such as base64, but this one m= ust be > =A0 =A0optional. > > =A03) escape the LF character and define an escape character which must a= lso be > =A0 =A0escaped itself. It is cheaper network-wise, but more expensive on = the > =A0 =A0client side where the stream must be read once to count the LFs be= fore > =A0 =A0being encoded and emitted. > > =A04) use Dave Cridland's idea of inserting an invalid HTTP request befor= e the > =A0 =A0beginning of the stream. The request should remain simple and shor= t with > =A0 =A0the goal to quickly fail. > > My personal suggestion would be stay in line with the progress that was d= one > and to go for #1. > > Regards, > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From derhoermi@gmx.net Mon Jan 10 09:10:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817913A6817 for ; Mon, 10 Jan 2011 09:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtF1owISt+rv for ; Mon, 10 Jan 2011 09:10:21 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id DC3DB3A67ED for ; Mon, 10 Jan 2011 09:10:20 -0800 (PST) Received: (qmail invoked by alias); 10 Jan 2011 17:12:34 -0000 Received: from dslb-094-223-191-191.pools.arcor-ip.net (EHLO hive) [94.223.191.191] by mail.gmx.net (mp018) with SMTP; 10 Jan 2011 18:12:34 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18ap6x9SXcaP4Wnnfgjzl04d0VMogE59kk2lls5yd qBJj8ewb0aCers From: Bjoern Hoehrmann To: Willy Tarreau Date: Mon, 10 Jan 2011 18:12:27 +0100 Message-ID: References: <20110109175118.GP5743@1wt.eu> In-Reply-To: <20110109175118.GP5743@1wt.eu> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 17:10:22 -0000 * Willy Tarreau wrote: >I found that it was possible to sensibly reduce the difficulty in making >an intermediary forward a valid HTTP request despite masking. My feeling >is that the risk remains extremely low as it still requires a substantial >amount of garbage to be skipped to find a request, and that we have not >detected any such vulnerable intermediaries. Still I wanted to share my >experiments. I think there are a couple of problems with your attack, but while Adam Barth is evaluating whether we can make progress by sending many mails without contributing any new information, it seems better to be brief. As I understand it, you are saying by using many connections you can reduce the amount of data that needs to be sent to make a pattern appear on the wire. You can't make as many connections as you seem to need to make much of a difference, because clients that can be controlled by untrusted parties will have measures against that to prevent probing and denial of service attacks. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ferg@caucho.com Mon Jan 10 10:05:15 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85AEF3A6AFF for ; Mon, 10 Jan 2011 10:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYG-GR95KMGP for ; Mon, 10 Jan 2011 10:05:14 -0800 (PST) Received: from nm22-vm0.bullet.mail.sp2.yahoo.com (nm22-vm0.bullet.mail.sp2.yahoo.com [98.139.91.222]) by core3.amsl.com (Postfix) with SMTP id 5E6023A69CC for ; Mon, 10 Jan 2011 10:05:14 -0800 (PST) Received: from [98.139.91.62] by nm22.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 18:07:28 -0000 Received: from [98.139.91.46] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 18:07:28 -0000 Received: from [127.0.0.1] by omp1046.mail.sp2.yahoo.com with NNFMP; 10 Jan 2011 18:07:28 -0000 X-Yahoo-Newman-Id: 933451.30954.bm@omp1046.mail.sp2.yahoo.com Received: (qmail 39632 invoked from network); 10 Jan 2011 18:07:28 -0000 Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 10 Jan 2011 10:07:28 -0800 PST X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C X-YMail-OSG: js.nIrMVM1n.AhzXkZ1M0Fv5r8Q8Pwce23Ct.uZ5voVAQav ZNQ8UyqnbkoIJ4XBjW489lCHsP9AmWmALP7CDSOMQSfGjPhlQVCmW.4tPSnv OoZtxWonpj6Mu9Wtdd9MN6InCWjQNa6o_R3URCpNU8GcmKbg_hGVbyCKz4Vv BIPzSS_mz86ziBsVk0ytzDMP2AMs6IjJwcqy0nbYuN5pY_cTpGzzMUZfQvIe iacXf6oAkoqP9NpTfryK6j4ZQalNawLzpwUou1L_gzQqAaxt5oMjRxg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D2B4AD7.80100@caucho.com> Date: Mon, 10 Jan 2011 10:07:19 -0800 From: Scott Ferguson User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Willy Tarreau References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> <20110110063646.GJ5743@1wt.eu> In-Reply-To: <20110110063646.GJ5743@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi , "Thomson, Martin" Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:05:15 -0000 Willy Tarreau wrote: > 2) it was speculated that some lazy intermediaries might possibly skip > over whatever they did not understand to resync on an HTTP request > they understand and execute it.... Has anyone attempted to justify this claim? It's implicit in the entire discussion about hash algorithms, but I haven't seen an argument that any intermediary, lazy or not, has or will ever implement any kind of HTTP resyncing. -- Scott From dave@cridland.net Mon Jan 10 10:13:27 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0885A3A6AFF for ; Mon, 10 Jan 2011 10:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7wTtOUAghxn for ; Mon, 10 Jan 2011 10:13:26 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id CB3743A6B06 for ; Mon, 10 Jan 2011 10:13:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8FE2B1168117 for ; Mon, 10 Jan 2011 18:15:29 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSwSCedPs+OU for ; Mon, 10 Jan 2011 18:15:17 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id E27C311680FB for ; Mon, 10 Jan 2011 18:15:16 +0000 (GMT) MIME-Version: 1.0 Message-Id: <2948.1294683316.925357@puncture> Date: Mon, 10 Jan 2011 18:15:16 +0000 From: Dave Cridland To: Server-Initiated HTTP Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:13:27 -0000 Much of the design of the framing was in support of being able to perform lightweight streaming and sendfile() operations. Many of us went along with various very vocal requests for this, leading to a 63-bit frame size, for example, which is impractical with masking. We all, I think, universally assumed a symmetric framing, whereas we have now discarded the symmetry anyway. Given that we now require making, and (as EKR points out in another mail), this in turn requires that the per-frame key is transmitted at the end of each block, which damages streaming, should we be revisisting these early design decisions? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ifette@google.com Mon Jan 10 10:14:00 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD723A6B06 for ; Mon, 10 Jan 2011 10:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.76 X-Spam-Level: X-Spam-Status: No, score=-103.76 tagged_above=-999 required=5 tests=[AWL=-1.684, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D95lWiQm7RpZ for ; Mon, 10 Jan 2011 10:13:59 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 9EBC23A6AFF for ; Mon, 10 Jan 2011 10:13:58 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p0AIGBtu023858 for ; Mon, 10 Jan 2011 10:16:11 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294683372; bh=3u9Wz0PqpFQq7nWgsfXq7NlJioQ=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=L7DkdfYIHG2Kw7NqfoE4bBZIDTvD52kr+4NyDGVigfv7IjQHavopKqXt4fHTAayPo qWMOPTdooSDbZXocP3WoQ== Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by kpbe12.cbf.corp.google.com with ESMTP id p0AIEG4T010107 for ; Mon, 10 Jan 2011 10:16:10 -0800 Received: by qwe5 with SMTP id 5so22151563qwe.26 for ; Mon, 10 Jan 2011 10:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=QkeMrRa2KrXSJ+lLEh0wnOY/PT+uOoGDXqQ4qAPL4Vc=; b=nX6qo+MoND4e09XPcnCD7i57oOl69alVUGeNMM9laXpYHqAqFGOEe/qUZz1GIN88pc H4PtRquMDFLCXm2myJhA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=XKZq5SA97IvjkoBWg+aQRKqlHi3SzYDGNERZGqnnfV8oOWOO8NtccqbH7xKC3aCL4n znB5czeDgtsxquWDkkHw== MIME-Version: 1.0 Received: by 10.229.81.11 with SMTP id v11mr4945358qck.152.1294683369704; Mon, 10 Jan 2011 10:16:09 -0800 (PST) Received: by 10.229.0.137 with HTTP; Mon, 10 Jan 2011 10:16:09 -0800 (PST) In-Reply-To: <20110110065408.GL5743@1wt.eu> References: <20110109224228.GU5743@1wt.eu> <20110110065408.GL5743@1wt.eu> Date: Mon, 10 Jan 2011 10:16:09 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Willy Tarreau Content-Type: multipart/alternative; boundary=0016364274d9590eb6049981f6ad X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:14:00 -0000 --0016364274d9590eb6049981f6ad Content-Type: text/plain; charset=UTF-8 On Sun, Jan 9, 2011 at 10:54 PM, Willy Tarreau wrote: > Hello Ian, > > On Sun, Jan 09, 2011 at 10:08:13PM -0800, Ian Fette > (????????????????????????) wrote: > > > - you're using the OPTIONS method. The WG's consensus was voted as > using > > > GET. While technically working, OPTIONS limits some possibilities > since > > > no path is sent to the server. > > > > > > > > I agree it is important to be able to identify between various resources > on > > a server. E.g. for our use, we will have multiple different websocket > > endpoints, and we want our frontend to be able to dispatch to the > > appropriate backend based on the information in the handshake. That said, > I > > think the draft allows for that (Sec-WebSocket-URL), or as pointed out on > > another thread, it appears OPTIONS does allow for a path component. So, I > > think we should be able to resolve that point. > > Once again,I'm not opposed at all to this point. I'd even say that would it > not have been accepted as a consensus in the last poll, I'd probably have > voted for it. It's just that it's a change from what was planned till now > and participants need to express their opinion on that point. > > > > - your proposal involves AES-128-CTR. As was discussed here, it seems > > > there > > > are still export regulations for certain countries eventhough > they're > > > apparently fading out. It could still be a problem for companies who > > > want > > > to export products to some countries and which never had to put > crypto > > > in > > > them. > > > > > > > It would be nice to understand if this is actually a hard constraint. > > AES-128-CTR has the benefit of being well understood, as well as fast, as > > demonstrated by Maciej in another thread. That said, I don't care > strongly > > one way or another here. > > One of my issue with it is that despite being fast, it's a lot slower than > simpler masking. I design software components to be used at the border side > of infrastructures to dispatch the traffic to multiple servers, and I'm > very much concerned by the performance limitations. On a machine which has > normally no issue processing 10 Gbps of HTTP, I could not even process 1 > Gbps > of WebSocket with large contents. This is much concerning because it > implies > that in order to build the stream analysers we've talked about in the past, > it will become mandatory to install expensive crypto acceleration cards. > This > is not logical for a protocol which is supposed to be transferred in clear > (ws:// as opposed to wss://). Checking for forbidden words, dangerous links > or forbidden contents on campus sites will be much more expensive due to > this > masking algorithm alone. > > > > - several people on the list asked for the ability to be able to > disable > > > the masking in some well-controlled environments (eg: > server-to-server > > > communications). I see no provisions for this. > > > > > > > > There's nothing that would prevent you from writing an extension that > would > > disable the masking, from my understanding. > > Adam did not seem favorable to that. > > > > - it has not yet been stated whether only the payload or also the > framing > > > should be masked. Your proposal masks both, which means that it > > > definitely > > > blocks any possibility of performing multiplexing later. There does > not > > > appear to have been a consensus in this area yet. > > > > > > > > I'm not sure why this would block the possibility of multiplexing. I > would > > agree that would be a problem if it were the case. However, a number of > the > > early proposals for multiplexing included something like a stream-id in > the > > frame. This could still be present. Though it would be masked, so would > the > > length and other things that a meaningful intermediary would care about, > so > > assuming the intermediary was capable of un-masking, is this an issue? > > Yes, and you got the point : if the ID is masked, how to you know which > stream it is in order to pick the right unmask key ? At least the stream > ID will have to be unmasked. If we prepend it before the frame, it means > a new framing format. Till not it was suggested to have it in the frame. > > So, you're saying that with the XOR masking where the entire content required to unmask the frame was included in the frame, it would be easier for an intermediary to thus examine the frame? I agree that it would be easier, and that in the AES method it would require an intermediary to be "active" instead of "passive", e.g. terminate the connection at the intermediary. I personally think that's a good argument towards XOR, but am personally not heavily invested either way as I think for our uses, we would be terminating at the "intermediary" anyways. > > > - Greg proposed to replace the MORE bit with a FIN bit so that the > first > > > hello frame from the server starts with a high bit set, thus > ensuring > > > that we can break the connection on non-HTTP compliant > intermediaries > > > which would expect a second response after the 101. > > > > > > > > The draft Adam sent out is based on an intermediate version I had checked > > into SVN, back when it looked like we were gaining speed on CONNECT. I > > didn't yet get around to flipping MORE/FIN, but I don't have any > ojbections > > to this. > > OK. > > > > Those are just a few notes, it's really not easy to changes :-/ > > > > > > > There's a tool on the IETF to diff drafts. I find it quite helpful, that > > said, a lot of text has changed because I had already started to make > other > > requested changes (including trying to resolve the HTTP compliance issue, > by > > stating the requirements of the handshake rather than stating send X > bytes, > > send Y bytes, ...). This makes the diff a bit harder to interpret, for > sure. > > Ah, OK. Till now I'd only use the automated diffs between incremental > drafts, > I did not know that there were other tools. > > http://tools.ietf.org/rfcdiff :) > Regards, > Willy > > --0016364274d9590eb6049981f6ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 9, 2011 at 10:54 PM, Willy Tarreau <= span dir=3D"ltr"><w@1wt.eu> wr= ote:
Hello Ian,

On Sun, Jan 09, 2011 at 10:08:13PM -0800, Ian Fette (??????????????????????= ??) wrote:
> > =C2=A0- you're using the OPTIONS method. The WG's consens= us was voted as using
> > =C2=A0 =C2=A0GET. While technically working, OPTIONS limits some = possibilities since
> > =C2=A0 =C2=A0no path is sent to the server.
> >
> >
> I agree it is important to be able to identify between various resourc= es on
> a server. E.g. for our use, we will have multiple different websocket<= br> > endpoints, and we want our frontend to be able to dispatch to the
> appropriate backend based on the information in the handshake. That sa= id, I
> think the draft allows for that (Sec-WebSocket-URL), or as pointed out= on
> another thread, it appears OPTIONS does allow for a path component. So= , I
> think we should be able to resolve that point.

Once again,I'm not opposed at all to this point. I'd even say= that would it
not have been accepted as a consensus in the last poll, I'd probably ha= ve
voted for it. It's just that it's a change from what was planned ti= ll now
and participants need to express their opinion on that point.

> > =C2=A0- your proposal involves AES-128-CTR. As was discussed here= , it seems
> > there
> > =C2=A0 =C2=A0are still export regulations for certain countries e= venthough they're
> > =C2=A0 =C2=A0apparently fading out. It could still be a problem f= or companies who
> > want
> > =C2=A0 =C2=A0to export products to some countries and which never= had to put crypto
> > in
> > =C2=A0 =C2=A0them.
> >
>
> It would be nice to understand if this is actually a hard constraint.<= br> > AES-128-CTR has the benefit of being well understood, as well as fast,= as
> demonstrated by Maciej in another thread. That said, I don't care = strongly
> one way or another here.

One of my issue with it is that despite being fast, it's a lot sl= ower than
simpler masking. I design software components to be used at the border side=
of infrastructures to dispatch the traffic to multiple servers, and I'm=
very much concerned by the performance limitations. On a machine which has<= br> normally no issue processing 10 Gbps of HTTP, I could not even process 1 Gb= ps
of WebSocket with large contents. This is much concerning because it implie= s
that in order to build the stream analysers we've talked about in the p= ast,
it will become mandatory to install expensive crypto acceleration cards. Th= is
is not logical for a protocol which is supposed to be transferred in clear<= br> (ws:// as opposed to wss://). Checking for forbidden words, dangerous links=
or forbidden contents on campus sites will be much more expensive due to th= is
masking algorithm alone.

> > =C2=A0- several people on the list asked for the ability to be ab= le to disable
> > =C2=A0 =C2=A0the masking in some well-controlled environments (eg= : server-to-server
> > =C2=A0 =C2=A0communications). I see no provisions for this.
> >
> >
> There's nothing that would prevent you from writing an extension t= hat would
> disable the masking, from my understanding.

Adam did not seem favorable to that.

> > =C2=A0- it has not yet been stated whether only the payload or al= so the framing
> > =C2=A0 =C2=A0should be masked. Your proposal masks both, which me= ans that it
> > definitely
> > =C2=A0 =C2=A0blocks any possibility of performing multiplexing la= ter. There does not
> > =C2=A0 =C2=A0appear to have been a consensus in this area yet. > >
> >
> I'm not sure why this would block the possibility of multiplexing.= I would
> agree that would be a problem if it were the case. However, a number o= f the
> early proposals for multiplexing included something like a stream-id i= n the
> frame. This could still be present. Though it would be masked, so woul= d the
> length and other things that a meaningful intermediary would care abou= t, so
> assuming the intermediary was capable of un-masking, is this an issue?=

Yes, and you got the point : if the ID is masked, how to you know whi= ch
stream it is in order to pick the right unmask key ? At least the stream ID will have to be unmasked. If we prepend it before the frame, it means a new framing format. Till not it was suggested to have it in the frame.


So, you're= saying that with the XOR masking where the entire content required to unma= sk the frame was included in the frame, it would be easier for an intermedi= ary to thus examine the frame? I agree that it would be easier, and that in= the AES method it would require an intermediary to be "active" i= nstead of "passive", e.g. terminate the connection at the interme= diary. I personally think that's a good argument towards XOR, but am pe= rsonally not heavily invested either way as I think for our uses, we would = be terminating at the "intermediary" anyways.
=C2=A0
> > =C2=A0- Greg proposed to replace the MORE bit with a FIN bit so t= hat the first
> > =C2=A0 =C2=A0hello frame from the server starts with a high bit s= et, thus ensuring
> > =C2=A0 =C2=A0that we can break the connection on non-HTTP complia= nt intermediaries
> > =C2=A0 =C2=A0which would expect a second response after the 101.<= br> > >
> >
> The draft Adam sent out is based on an intermediate version I had chec= ked
> into SVN, back when it looked like we were gaining speed on CONNECT. I=
> didn't yet get around to flipping MORE/FIN, but I don't have a= ny ojbections
> to this.

OK.

> > Those are just a few notes, it's really not easy to changes := -/
> >
>
> There's a tool on the IETF to diff drafts. I find it quite helpful= , that
> said, a lot of text has changed because I had already started to make = other
> requested changes (including trying to resolve the HTTP compliance iss= ue, by
> stating the requirements of the handshake rather than stating send X b= ytes,
> send Y bytes, ...). This makes the diff a bit harder to interpret, for= sure.

Ah, OK. Till now I'd only use the automated diffs between increme= ntal drafts,
I did not know that there were other tools.


=C2=A0
Regards,
Willy


--0016364274d9590eb6049981f6ad-- From ifette@google.com Mon Jan 10 10:16:24 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1FF3A6AFF for ; Mon, 10 Jan 2011 10:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.059 X-Spam-Level: X-Spam-Status: No, score=-104.059 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 188-8SeyF6kz for ; Mon, 10 Jan 2011 10:16:23 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E0CB23A6B0A for ; Mon, 10 Jan 2011 10:16:22 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p0AIIb6H023210 for ; Mon, 10 Jan 2011 10:18:37 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294683517; bh=srNa8I0dHm3yhqYlNAXpH7/Vkgw=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=cMkIvxdDSlygEuX1qmu9ghauQOqhfGAx0JBt/Rrjlsq3UYOPzFuriwMlgCAtL+hBJ 92n7XehM3zCD+Qt+IXjDw== Received: from vws7 (vws7.prod.google.com [10.241.21.135]) by wpaz9.hot.corp.google.com with ESMTP id p0AIIZKF021956 for ; Mon, 10 Jan 2011 10:18:36 -0800 Received: by vws7 with SMTP id 7so8002571vws.31 for ; Mon, 10 Jan 2011 10:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=QicaNjWmsecs28TWO6Aj2+J8is/TOdUdHICNsfqMU5Y=; b=JKsbZdzwH602LgYJ312brXUzq59QRJtx+s8pdMuwO/X05jd0mO98wBPnuafutZztDP hjgvogeCKGMFSXpSvUeQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=p9YQemY07Ru/u2GxOWqLqiSo+lEy3kyXIWbmkISKYkfYAGt8HIMwHNR7vdK/JO530m wrjtWHQSeLv5dVyNx+ZA== MIME-Version: 1.0 Received: by 10.229.251.137 with SMTP id ms9mr567702qcb.188.1294683515472; Mon, 10 Jan 2011 10:18:35 -0800 (PST) Received: by 10.229.0.137 with HTTP; Mon, 10 Jan 2011 10:18:35 -0800 (PST) In-Reply-To: <2948.1294683316.925357@puncture> References: <2948.1294683316.925357@puncture> Date: Mon, 10 Jan 2011 10:18:35 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Dave Cridland Content-Type: multipart/alternative; boundary=00163630feb3094cc6049981ff56 X-System-Of-Record: true Cc: Server-Initiated HTTP Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:16:24 -0000 --00163630feb3094cc6049981ff56 Content-Type: text/plain; charset=UTF-8 Please god no. We're just now at the point of hopefully getting agreement on the handshake and being able to ship something, let us not re-open the whole framing debate or it will be 2012 before we ship anything. -Ian On Mon, Jan 10, 2011 at 10:15 AM, Dave Cridland wrote: > Much of the design of the framing was in support of being able to perform > lightweight streaming and sendfile() operations. Many of us went along with > various very vocal requests for this, leading to a 63-bit frame size, for > example, which is impractical with masking. We all, I think, universally > assumed a symmetric framing, whereas we have now discarded the symmetry > anyway. > > Given that we now require making, and (as EKR points out in another mail), > this in turn requires that the per-frame key is transmitted at the end of > each block, which damages streaming, should we be revisisting these early > design decisions? > > Dave. > -- > Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --00163630feb3094cc6049981ff56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please god no. We're just now at the point of hopefully getting agreeme= nt on the handshake and being able to ship something, let us not re-open th= e whole framing debate or it will be 2012 before we ship anything.

-Ian

On Mon, Jan 10, 2011 at 1= 0:15 AM, Dave Cridland <dave@cridland.net> wrote:
Much of the design of the framing was in support of being able to perform l= ightweight streaming and sendfile() operations. Many of us went along with = various very vocal requests for this, leading to a 63-bit frame size, for e= xample, which is impractical with masking. We all, I think, universally ass= umed a symmetric framing, whereas we have now discarded the symmetry anyway= .

Given that we now require making, and (as EKR points out in another mail), = this in turn requires that the per-frame key is transmitted at the end of e= ach block, which damages streaming, should we be revisisting these early de= sign decisions?

Dave.
--
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
=C2=A0- acap://acap.dave.cridland.net/byowner/user/dwd/bookmar= ks/
=C2=A0- http://dave= .cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--00163630feb3094cc6049981ff56-- From ekr@rtfm.com Mon Jan 10 10:18:12 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFEB23A6B0E for ; Mon, 10 Jan 2011 10:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saBJup4F1R3N for ; Mon, 10 Jan 2011 10:18:11 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 8AA4B3A6B10 for ; Mon, 10 Jan 2011 10:18:11 -0800 (PST) Received: by yie19 with SMTP id 19so6321603yie.31 for ; Mon, 10 Jan 2011 10:20:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.26.24 with SMTP id d24mr6565756agj.160.1294683625438; Mon, 10 Jan 2011 10:20:25 -0800 (PST) Received: by 10.90.154.19 with HTTP; Mon, 10 Jan 2011 10:20:25 -0800 (PST) In-Reply-To: References: <20110109224228.GU5743@1wt.eu> <20110110065408.GL5743@1wt.eu> Date: Mon, 10 Jan 2011 18:20:25 +0000 Message-ID: From: Eric Rescorla To: ifette@google.com Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:18:12 -0000 2011/1/10 Ian Fette ($B%$%"%s%U%'%C%F%#(B) : > On Sun, Jan 9, 2011 at 10:54 PM, Willy Tarreau wrote: >> >> Hello Ian, >> >> On Sun, Jan 09, 2011 at 10:08:13PM -0800, Ian Fette >> (????????????????????????) wrote: >> > > - you're using the OPTIONS method. The WG's consensus was voted as >> > > using >> > > GET. While technically working, OPTIONS limits some possibilities >> > > since >> > > no path is sent to the server. >> > > >> > > >> > I agree it is important to be able to identify between various resources >> > on >> > a server. E.g. for our use, we will have multiple different websocket >> > endpoints, and we want our frontend to be able to dispatch to the >> > appropriate backend based on the information in the handshake. That >> > said, I >> > think the draft allows for that (Sec-WebSocket-URL), or as pointed out >> > on >> > another thread, it appears OPTIONS does allow for a path component. So, >> > I >> > think we should be able to resolve that point. >> >> Once again,I'm not opposed at all to this point. I'd even say that would >> it >> not have been accepted as a consensus in the last poll, I'd probably have >> voted for it. It's just that it's a change from what was planned till now >> and participants need to express their opinion on that point. >> >> > > - your proposal involves AES-128-CTR. As was discussed here, it seems >> > > there >> > > are still export regulations for certain countries eventhough >> > > they're >> > > apparently fading out. It could still be a problem for companies >> > > who >> > > want >> > > to export products to some countries and which never had to put >> > > crypto >> > > in >> > > them. >> > > >> > >> > It would be nice to understand if this is actually a hard constraint. >> > AES-128-CTR has the benefit of being well understood, as well as fast, >> > as >> > demonstrated by Maciej in another thread. That said, I don't care >> > strongly >> > one way or another here. >> >> One of my issue with it is that despite being fast, it's a lot slower than >> simpler masking. I design software components to be used at the border >> side >> of infrastructures to dispatch the traffic to multiple servers, and I'm >> very much concerned by the performance limitations. On a machine which has >> normally no issue processing 10 Gbps of HTTP, I could not even process 1 >> Gbps >> of WebSocket with large contents. This is much concerning because it >> implies >> that in order to build the stream analysers we've talked about in the >> past, >> it will become mandatory to install expensive crypto acceleration cards. >> This >> is not logical for a protocol which is supposed to be transferred in clear >> (ws:// as opposed to wss://). Checking for forbidden words, dangerous >> links >> or forbidden contents on campus sites will be much more expensive due to >> this >> masking algorithm alone. >> >> > > - several people on the list asked for the ability to be able to >> > > disable >> > > the masking in some well-controlled environments (eg: >> > > server-to-server >> > > communications). I see no provisions for this. >> > > >> > > >> > There's nothing that would prevent you from writing an extension that >> > would >> > disable the masking, from my understanding. >> >> Adam did not seem favorable to that. >> >> > > - it has not yet been stated whether only the payload or also the >> > > framing >> > > should be masked. Your proposal masks both, which means that it >> > > definitely >> > > blocks any possibility of performing multiplexing later. There does >> > > not >> > > appear to have been a consensus in this area yet. >> > > >> > > >> > I'm not sure why this would block the possibility of multiplexing. I >> > would >> > agree that would be a problem if it were the case. However, a number of >> > the >> > early proposals for multiplexing included something like a stream-id in >> > the >> > frame. This could still be present. Though it would be masked, so would >> > the >> > length and other things that a meaningful intermediary would care about, >> > so >> > assuming the intermediary was capable of un-masking, is this an issue? >> >> Yes, and you got the point : if the ID is masked, how to you know which >> stream it is in order to pick the right unmask key ? At least the stream >> ID will have to be unmasked. If we prepend it before the frame, it means >> a new framing format. Till not it was suggested to have it in the frame. >> > > So, you're saying that with the XOR masking where the entire content > required to unmask the frame was included in the frame, it would be easier > for an intermediary to thus examine the frame? I agree that it would be > easier, and that in the AES method it would require an intermediary to be > "active" instead of "passive", e.g. terminate the connection at the > intermediary. I personally think that's a good argument towards XOR, but am > personally not heavily invested either way as I think for our uses, we would > be terminating at the "intermediary" anyways. > Ian, Im not sure Im following the reasoning here: why does the AES mechanism (which is, after all, just an XOR with a long, randomly computed mask) require an active intermediary? Thanks, -Ekr From gregw@intalio.com Mon Jan 10 10:22:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92BC628C0DC for ; Mon, 10 Jan 2011 10:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyKQsywb2P6Q for ; Mon, 10 Jan 2011 10:22:55 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 991DB28C0CF for ; Mon, 10 Jan 2011 10:22:55 -0800 (PST) Received: by qwi2 with SMTP id 2so4361593qwi.31 for ; Mon, 10 Jan 2011 10:25:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.235.143 with SMTP id kg15mr24622968qcb.17.1294683909709; Mon, 10 Jan 2011 10:25:09 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Mon, 10 Jan 2011 10:25:09 -0800 (PST) In-Reply-To: References: <20110109175118.GP5743@1wt.eu> Date: Mon, 10 Jan 2011 19:25:09 +0100 X-Google-Sender-Auth: irz3j4ThLo7W9uzj8swchl0gku8 Message-ID: From: Greg Wilkins To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:22:56 -0000 Eric, I'm not opposed to sending the key after the masked data, but I don't see how that can be done with masked frames. The receiver will need to see the frame, so they can see the length, so they can find the key. If the frame is masked, the you wont be able to find the key. But, (pushing my normal barrow), I see no reason why we could not switch the extension data to be after the payload data in a frame. With fragmentation, we should always be able to process complete frames. From ifette@google.com Mon Jan 10 10:23:22 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D033F28B23E for ; Mon, 10 Jan 2011 10:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.687 X-Spam-Level: X-Spam-Status: No, score=-103.687 tagged_above=-999 required=5 tests=[AWL=-1.611, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFnURUzAcnB3 for ; Mon, 10 Jan 2011 10:23:21 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8F5293A6B18 for ; Mon, 10 Jan 2011 10:23:20 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p0AIPXvV019105 for ; Mon, 10 Jan 2011 10:25:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294683934; bh=AlfaFBiK9iiN2iN4JIza4+15Z8s=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=pcmFhbJbd3gBr2aawbXJOoGrh9H9DGfVV/zuhvb4O7Je640Jrcu9xhbhMGfoVhSQz +2R4NFaZcE+OF1a+5oq8A== Received: from vws13 (vws13.prod.google.com [10.241.21.141]) by wpaz13.hot.corp.google.com with ESMTP id p0AIPWkD014291 for ; Mon, 10 Jan 2011 10:25:32 -0800 Received: by vws13 with SMTP id 13so7958003vws.25 for ; Mon, 10 Jan 2011 10:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=EIlAtxOeDLUH2OwAhBzy5OMWp+Wa9Oj1GNGMndzFy+c=; b=ZtGSbGNO8Jq6hjk1VHwx0a1XHqvjDLn/MCZ9yW7Xe/GEeKUwP8uSNZdTGW7JjJbmy7 h8AzGVGRTPqo2LmRyaew== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=gLkj3CBWQ/f6XatSYRAiQuMU3i0XfAwRUHrmIJFaYXuPSqrVcadyXMbUre/ihlDzvZ rFp+cKXm4vyF/qBnvQYw== MIME-Version: 1.0 Received: by 10.229.229.200 with SMTP id jj8mr15442193qcb.74.1294683931886; Mon, 10 Jan 2011 10:25:31 -0800 (PST) Received: by 10.229.0.137 with HTTP; Mon, 10 Jan 2011 10:25:31 -0800 (PST) In-Reply-To: References: <20110109224228.GU5743@1wt.eu> <20110110065408.GL5743@1wt.eu> Date: Mon, 10 Jan 2011 10:25:31 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Eric Rescorla Content-Type: multipart/alternative; boundary=001485f6cfb4db46b70499821785 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:23:22 -0000 --001485f6cfb4db46b70499821785 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2011/1/10 Eric Rescorla > 2011/1/10 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83= =83=E3=83=86=E3=82=A3) : > > On Sun, Jan 9, 2011 at 10:54 PM, Willy Tarreau wrote: > >> > >> Hello Ian, > >> > >> On Sun, Jan 09, 2011 at 10:08:13PM -0800, Ian Fette > >> (????????????????????????) wrote: > >> > > - you're using the OPTIONS method. The WG's consensus was voted a= s > >> > > using > >> > > GET. While technically working, OPTIONS limits some possibiliti= es > >> > > since > >> > > no path is sent to the server. > >> > > > >> > > > >> > I agree it is important to be able to identify between various > resources > >> > on > >> > a server. E.g. for our use, we will have multiple different websocke= t > >> > endpoints, and we want our frontend to be able to dispatch to the > >> > appropriate backend based on the information in the handshake. That > >> > said, I > >> > think the draft allows for that (Sec-WebSocket-URL), or as pointed o= ut > >> > on > >> > another thread, it appears OPTIONS does allow for a path component. > So, > >> > I > >> > think we should be able to resolve that point. > >> > >> Once again,I'm not opposed at all to this point. I'd even say that wou= ld > >> it > >> not have been accepted as a consensus in the last poll, I'd probably > have > >> voted for it. It's just that it's a change from what was planned till > now > >> and participants need to express their opinion on that point. > >> > >> > > - your proposal involves AES-128-CTR. As was discussed here, it > seems > >> > > there > >> > > are still export regulations for certain countries eventhough > >> > > they're > >> > > apparently fading out. It could still be a problem for companie= s > >> > > who > >> > > want > >> > > to export products to some countries and which never had to put > >> > > crypto > >> > > in > >> > > them. > >> > > > >> > > >> > It would be nice to understand if this is actually a hard constraint= . > >> > AES-128-CTR has the benefit of being well understood, as well as fas= t, > >> > as > >> > demonstrated by Maciej in another thread. That said, I don't care > >> > strongly > >> > one way or another here. > >> > >> One of my issue with it is that despite being fast, it's a lot slower > than > >> simpler masking. I design software components to be used at the border > >> side > >> of infrastructures to dispatch the traffic to multiple servers, and I'= m > >> very much concerned by the performance limitations. On a machine which > has > >> normally no issue processing 10 Gbps of HTTP, I could not even process= 1 > >> Gbps > >> of WebSocket with large contents. This is much concerning because it > >> implies > >> that in order to build the stream analysers we've talked about in the > >> past, > >> it will become mandatory to install expensive crypto acceleration card= s. > >> This > >> is not logical for a protocol which is supposed to be transferred in > clear > >> (ws:// as opposed to wss://). Checking for forbidden words, dangerous > >> links > >> or forbidden contents on campus sites will be much more expensive due = to > >> this > >> masking algorithm alone. > >> > >> > > - several people on the list asked for the ability to be able to > >> > > disable > >> > > the masking in some well-controlled environments (eg: > >> > > server-to-server > >> > > communications). I see no provisions for this. > >> > > > >> > > > >> > There's nothing that would prevent you from writing an extension tha= t > >> > would > >> > disable the masking, from my understanding. > >> > >> Adam did not seem favorable to that. > >> > >> > > - it has not yet been stated whether only the payload or also the > >> > > framing > >> > > should be masked. Your proposal masks both, which means that it > >> > > definitely > >> > > blocks any possibility of performing multiplexing later. There > does > >> > > not > >> > > appear to have been a consensus in this area yet. > >> > > > >> > > > >> > I'm not sure why this would block the possibility of multiplexing. I > >> > would > >> > agree that would be a problem if it were the case. However, a number > of > >> > the > >> > early proposals for multiplexing included something like a stream-id > in > >> > the > >> > frame. This could still be present. Though it would be masked, so > would > >> > the > >> > length and other things that a meaningful intermediary would care > about, > >> > so > >> > assuming the intermediary was capable of un-masking, is this an issu= e? > >> > >> Yes, and you got the point : if the ID is masked, how to you know whic= h > >> stream it is in order to pick the right unmask key ? At least the stre= am > >> ID will have to be unmasked. If we prepend it before the frame, it mea= ns > >> a new framing format. Till not it was suggested to have it in the fram= e. > >> > > > > So, you're saying that with the XOR masking where the entire content > > required to unmask the frame was included in the frame, it would be > easier > > for an intermediary to thus examine the frame? I agree that it would be > > easier, and that in the AES method it would require an intermediary to = be > > "active" instead of "passive", e.g. terminate the connection at the > > intermediary. I personally think that's a good argument towards XOR, bu= t > am > > personally not heavily invested either way as I think for our uses, we > would > > be terminating at the "intermediary" anyways. > > > > Ian, > > Im not sure Im following the reasoning here: why does the AES > mechanism (which is, > after all, just an XOR with a long, randomly computed mask) require an > active intermediary? > > Thanks, > -Ekr > I guess you're right in that it wouldn't require the intermediary to be active. It would however require the intermediary to maintain state for eac= h connection, correct? (As opposed to XOR where the intermediary could be mostly stateless as the the "masking key" would be embedded in the frame). How large is the state that would need to be maintained? -Ian --001485f6cfb4db46b70499821785 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2011/1/10 Eric Rescorla <ekr@rtfm.com>
2011/1/10 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95= =E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) <ifette@google.com>:
> On Sun, Jan 9, 2011 at 10:54 P= M, Willy Tarreau <w@1wt.eu> wrote: >>
>> Hello Ian,
>>
>> On Sun, Jan 09, 2011 at 10:08:13PM -0800, Ian Fette
>> (????????????????????????) wrote:
>> > > =C2=A0- you're using the OPTIONS method. The WG'= s consensus was voted as
>> > > using
>> > > =C2=A0 =C2=A0GET. While technically working, OPTIONS lim= its some possibilities
>> > > since
>> > > =C2=A0 =C2=A0no path is sent to the server.
>> > >
>> > >
>> > I agree it is important to be able to identify between variou= s resources
>> > on
>> > a server. E.g. for our use, we will have multiple different w= ebsocket
>> > endpoints, and we want our frontend to be able to dispatch to= the
>> > appropriate backend based on the information in the handshake= . That
>> > said, I
>> > think the draft allows for that (Sec-WebSocket-URL), or as po= inted out
>> > on
>> > another thread, it appears OPTIONS does allow for a path comp= onent. So,
>> > I
>> > think we should be able to resolve that point.
>>
>> Once again,I'm not opposed at all to this point. I'd even = say that would
>> it
>> not have been accepted as a consensus in the last poll, I'd pr= obably have
>> voted for it. It's just that it's a change from what was p= lanned till now
>> and participants need to express their opinion on that point.
>>
>> > > =C2=A0- your proposal involves AES-128-CTR. As was discu= ssed here, it seems
>> > > there
>> > > =C2=A0 =C2=A0are still export regulations for certain co= untries eventhough
>> > > they're
>> > > =C2=A0 =C2=A0apparently fading out. It could still be a = problem for companies
>> > > who
>> > > want
>> > > =C2=A0 =C2=A0to export products to some countries and wh= ich never had to put
>> > > crypto
>> > > in
>> > > =C2=A0 =C2=A0them.
>> > >
>> >
>> > It would be nice to understand if this is actually a hard con= straint.
>> > AES-128-CTR has the benefit of being well understood, as well= as fast,
>> > as
>> > demonstrated by Maciej in another thread. That said, I don= 9;t care
>> > strongly
>> > one way or another here.
>>
>> One of my issue with it is that despite being fast, it's a lot= slower than
>> simpler masking. I design software components to be used at the bo= rder
>> side
>> of infrastructures to dispatch the traffic to multiple servers, an= d I'm
>> very much concerned by the performance limitations. On a machine w= hich has
>> normally no issue processing 10 Gbps of HTTP, I could not even pro= cess 1
>> Gbps
>> of WebSocket with large contents. This is much concerning because = it
>> implies
>> that in order to build the stream analysers we've talked about= in the
>> past,
>> it will become mandatory to install expensive crypto acceleration = cards.
>> This
>> is not logical for a protocol which is supposed to be transferred = in clear
>> (ws:// as opposed to wss://). Checking for forbidden words, danger= ous
>> links
>> or forbidden contents on campus sites will be much more expensive = due to
>> this
>> masking algorithm alone.
>>
>> > > =C2=A0- several people on the list asked for the ability= to be able to
>> > > disable
>> > > =C2=A0 =C2=A0the masking in some well-controlled environ= ments (eg:
>> > > server-to-server
>> > > =C2=A0 =C2=A0communications). I see no provisions for th= is.
>> > >
>> > >
>> > There's nothing that would prevent you from writing an ex= tension that
>> > would
>> > disable the masking, from my understanding.
>>
>> Adam did not seem favorable to that.
>>
>> > > =C2=A0- it has not yet been stated whether only the payl= oad or also the
>> > > framing
>> > > =C2=A0 =C2=A0should be masked. Your proposal masks both,= which means that it
>> > > definitely
>> > > =C2=A0 =C2=A0blocks any possibility of performing multip= lexing later. There does
>> > > not
>> > > =C2=A0 =C2=A0appear to have been a consensus in this are= a yet.
>> > >
>> > >
>> > I'm not sure why this would block the possibility of mult= iplexing. I
>> > would
>> > agree that would be a problem if it were the case. However, a= number of
>> > the
>> > early proposals for multiplexing included something like a st= ream-id in
>> > the
>> > frame. This could still be present. Though it would be masked= , so would
>> > the
>> > length and other things that a meaningful intermediary would = care about,
>> > so
>> > assuming the intermediary was capable of un-masking, is this = an issue?
>>
>> Yes, and you got the point : if the ID is masked, how to you know = which
>> stream it is in order to pick the right unmask key ? At least the = stream
>> ID will have to be unmasked. If we prepend it before the frame, it= means
>> a new framing format. Till not it was suggested to have it in the = frame.
>>
>
> So, you're saying that with the XOR masking where the entire conte= nt
> required to unmask the frame was included in the frame, it would be ea= sier
> for an intermediary to thus examine the frame? I agree that it would b= e
> easier, and that in the AES method it would require an intermediary to= be
> "active" instead of "passive", e.g. terminate the = connection at the
> intermediary. I personally think that's a good argument towards XO= R, but am
> personally not heavily invested either way as I think for our uses, we= would
> be terminating at the "intermediary" anyways.
>

Ian,

Im not sure Im following the reasoning here: why does the AES
mechanism (which is,
after all, just an XOR with a long, randomly computed mask) require an
active intermediary?

Thanks,
-Ekr

I guess you're right in that it wouldn'= t require the intermediary to be active. It would however require the inter= mediary to maintain state for each connection, correct? (As opposed to XOR = where the intermediary could be mostly stateless as the the "masking k= ey" would be embedded in the frame). How large is the state that would= need to be maintained?

-Ian
--001485f6cfb4db46b70499821785-- From bruce@callenish.com Mon Jan 10 10:42:06 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A983A6B04 for ; Mon, 10 Jan 2011 10:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONg56eu7i4Zg for ; Mon, 10 Jan 2011 10:42:05 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 19C653A67FF for ; Mon, 10 Jan 2011 10:42:05 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PcMj4-00019v-T5 for hybi@ietf.org; Mon, 10 Jan 2011 10:44:19 -0800 Message-ID: <4D2B5383.7000703@callenish.com> Date: Mon, 10 Jan 2011 10:44:19 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4D2A4FFE.6000503@callenish.com> <4D2A6FB9.1030005@callenish.com> <20110110063930.GK5743@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] Summary of issues concerning the default masking algorithm X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:42:06 -0000 On 10/01/2011 7:43 AM, Eric Rescorla wrote: > Building tools to process this kind of masked data is trivial. Heck, tools to > decode full SSL aren't even that hard. I know because I've built them. I don't understand how you can reliably decode the streams with the currently proposed masking strategy, but I am ready to be proved wrong. First, let me more fully flesh out what is required for these debugging sessions. Bidirectional protocols tend to be much longer lived than others. It is not unusual to get ones that last hours or days or weeks, or even ones that only reset when one end or the other does a reboot. You want to keep your capture logs as short-lived as possible. The bigger the capture log is, the more expensive it is to fix the problem. They take up time not only in storage space and transfer time, but most importantly in time spent analyzing the results. One very common idiom for keeping the capture logs short is to identify an action that triggers the bug, have a customer start the capture, perform the action, give enough time for the bug to manifest, and stop the capture. You still may have tens of thousands of sessions to wade through and filter as best you can, but at least you can be fairly sure the one you want is in there somewhere. Ok, so given all that, how do we deal with a connection that only sends shared secret information at the beginning of the connection when you are less likely to be doing a capture? Well, I guess the shared secret could be repeatedly sent out periodically during the life of the connection. But how often? 30 seconds can be a whole lot of capture on a busy system. Every 2 seconds? What does that do to mobile batteries, or the bandwidth usage of mobile users? Then again, you could put the shared secret on every frame. That would prevent the mask itself from being on the wire and would allow capture tools to decode the stream. But it would also bulk up the data sent with every frame, which I think many would find undesirable. And what would all this data on the wire bring you? A guarantee that naively implemented servers couldn't ignore the influence of the server nonce on the mask? Have you seen the complexity of the masking being proposed? I think we are well past the point where there are going to be naively implemented servers. We left simple implementations as a design concern in a roadside grave 100 miles back. From ekr@rtfm.com Mon Jan 10 10:53:08 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847533A69C5 for ; Mon, 10 Jan 2011 10:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.662 X-Spam-Level: X-Spam-Status: No, score=-102.662 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+zXMj+uSFnL for ; Mon, 10 Jan 2011 10:53:07 -0800 (PST) Received: from mail-yi0-f66.google.com (mail-yi0-f66.google.com [209.85.218.66]) by core3.amsl.com (Postfix) with ESMTP id B9B903A67D9 for ; Mon, 10 Jan 2011 10:53:07 -0800 (PST) Received: by yic24 with SMTP id 24so2874804yic.1 for ; Mon, 10 Jan 2011 10:55:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.232.6 with SMTP id e6mr31419870agh.52.1294685721854; Mon, 10 Jan 2011 10:55:21 -0800 (PST) Received: by 10.90.154.19 with HTTP; Mon, 10 Jan 2011 10:55:21 -0800 (PST) In-Reply-To: References: <20110109224228.GU5743@1wt.eu> <20110110065408.GL5743@1wt.eu> Date: Mon, 10 Jan 2011 18:55:21 +0000 Message-ID: From: Eric Rescorla To: ifette@google.com Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:53:08 -0000 2011/1/10 Ian Fette ($B%$%"%s%U%'%C%F%#(B) : > I guess you're right in that it wouldn't require the intermediary to be > active. It would however require the intermediary to maintain state for each > connection, correct? (As opposed to XOR where the intermediary could be > mostly stateless as the the "masking key" would be embedded in the frame). > How large is the state that would need to be maintained? Basically the AES key schedule, which is pretty small (4k for a speed-optimized version) plus as much of the frame as you buffer [the whole thing if the key is at the end, obviously.] -Ekr From ekr@rtfm.com Mon Jan 10 10:57:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B3B3A6B0D for ; Mon, 10 Jan 2011 10:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.665 X-Spam-Level: X-Spam-Status: No, score=-102.665 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtZpPvEGbupr for ; Mon, 10 Jan 2011 10:57:39 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 934033A6823 for ; Mon, 10 Jan 2011 10:57:39 -0800 (PST) Received: by yxt33 with SMTP id 33so8615195yxt.31 for ; Mon, 10 Jan 2011 10:59:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.83.18 with SMTP id k18mr6515065agl.79.1294685992612; Mon, 10 Jan 2011 10:59:52 -0800 (PST) Received: by 10.90.154.19 with HTTP; Mon, 10 Jan 2011 10:59:52 -0800 (PST) In-Reply-To: References: <20110109175118.GP5743@1wt.eu> Date: Mon, 10 Jan 2011 18:59:52 +0000 Message-ID: From: Eric Rescorla To: Greg Wilkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:57:40 -0000 I'm not sure precisely what you mean by "masked frames". If I were king, th= ings would look like this: - length - masked portion - key With everything else being packed into the masked portion. I agree that length should not be masked. -Ekr On Mon, Jan 10, 2011 at 6:25 PM, Greg Wilkins wrote: > Eric, > > I'm not opposed to sending the key after the masked data, but I don't > see how that can be done with masked frames. > The receiver will need to see the frame, so they can see the length, > so they can find the key. =A0If the frame is masked, the you wont be > able to find the key. > > But, (pushing my normal barrow), I see no reason why we could not > switch the extension data to be after the payload data in a frame. > With fragmentation, we should always be able to process complete > frames. > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From gregw@intalio.com Mon Jan 10 11:17:40 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9AF3A6B0E for ; Mon, 10 Jan 2011 11:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caJcNKWAc-Z1 for ; Mon, 10 Jan 2011 11:17:39 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 43C613A6B0C for ; Mon, 10 Jan 2011 11:17:39 -0800 (PST) Received: by qyk34 with SMTP id 34so1851003qyk.10 for ; Mon, 10 Jan 2011 11:19:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.36.208 with SMTP id u16mr27150798qad.299.1294687193403; Mon, 10 Jan 2011 11:19:53 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Mon, 10 Jan 2011 11:19:53 -0800 (PST) In-Reply-To: References: <20110109175118.GP5743@1wt.eu> Date: Mon, 10 Jan 2011 20:19:53 +0100 X-Google-Sender-Auth: 8HfuSZRGCPRe5Lsfv8eF3wQpTE4 Message-ID: From: Greg Wilkins To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:17:40 -0000 On 10 January 2011 19:59, Eric Rescorla wrote: > I'm not sure precisely what you mean by "masked frames". If I were king, things > would look like this: > > - length > - masked portion > - key > > With everything else being packed into the masked portion. Well we are not that far apart, as was proposing - flags/opcode - length - masked portion - key (in extension data) although as pointed out in a separate thread, that ordering makes our 63 bit length a bit of overkill. As I was an advocate for smaller frames and fragmentation, I'd have no issue with reducing the max frame size so that the key could be sent afterwards. But I see no will to revisit framing, so that leaves us with: - flags/opcode - key (in extension data) - length - masked portion is that really that far from what you have proposed? Plus if the masking is an extension then objections to cryptographic masking are less. From bruce@callenish.com Mon Jan 10 11:23:21 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D727C3A6B1D for ; Mon, 10 Jan 2011 11:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0ziDWklm5BM for ; Mon, 10 Jan 2011 11:23:21 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 223FE3A6B1C for ; Mon, 10 Jan 2011 11:23:21 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PcNN0-0008D4-Pv for hybi@ietf.org; Mon, 10 Jan 2011 11:25:35 -0800 Message-ID: <4D2B5D2F.80503@callenish.com> Date: Mon, 10 Jan 2011 11:25:35 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Hybi References: <20110110000908.GD5743@1wt.eu> <8B0A9FCBB9832F43971E38010638454F03F5258EEC@SISPE7MB1.commscope.com> <20110110063646.GJ5743@1wt.eu> <20110110065822.GM5743@1wt.eu> <20110110070820.GN5743@1wt.eu> <20110110075208.GO5743@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:23:22 -0000 On 09/01/2011 11:55 PM, Adam Barth wrote: > Or we could just use AES-128-CTR like everyone else in the known > universe and not worry about whether we've shaved exactly the right > number of hairs off our home-brew pseudo crypto. I've written applications that use simple XOR masking because AES-128-CTR is unnecessarily complex. Does that mean I'm now in an unknown universe? Cool. Do I get to win the lottery in this one? From jat@google.com Mon Jan 10 11:29:23 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B835828C0EF for ; Mon, 10 Jan 2011 11:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.84 X-Spam-Level: X-Spam-Status: No, score=-103.84 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5D73qv07jop for ; Mon, 10 Jan 2011 11:29:22 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A92ED28B23E for ; Mon, 10 Jan 2011 11:29:22 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p0AJVag5002949 for ; Mon, 10 Jan 2011 11:31:36 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294687896; bh=NMJmnJVKNlBgDeYq+UK6TJgomuQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=knC55v3cqDejB/7a+06GYKcFBQ5HddsZwtE/1wDqhPGRagXW6qtK/N6HhY3DXw1JP 1fs+IYJnEtX9wx0vQ9IYA== Received: from gwb20 (gwb20.prod.google.com [10.200.2.20]) by kpbe14.cbf.corp.google.com with ESMTP id p0AJU0Mr008542 for ; Mon, 10 Jan 2011 11:31:35 -0800 Received: by gwb20 with SMTP id 20so8895552gwb.1 for ; Mon, 10 Jan 2011 11:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=Hz2LXNoHEyCHqn2+A8QnNhrKpZULhIQvhewHKFHmOGc=; b=bUdwhLoj+dlmnLViPXFcePCHkCDby1zeWKh08Job2vneGZfi6ohJwsfrXJ1vMfMglw 886XOa1JwcV/HqgN+9bw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=F60QQbyrpYFGvMOY7b16+CuSfHDV3akzkTR+22BzMldyUL+xMQS6/qO/etuS7pLTDR oJ/chBmTIMHd0i7GN+qQ== Received: by 10.151.85.10 with SMTP id n10mr28255412ybl.206.1294687895089; Mon, 10 Jan 2011 11:31:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Mon, 10 Jan 2011 11:31:14 -0800 (PST) In-Reply-To: References: <20110109175118.GP5743@1wt.eu> From: John Tamplin Date: Mon, 10 Jan 2011 14:31:14 -0500 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:29:23 -0000 On Mon, Jan 10, 2011 at 10:52 AM, Eric Rescorla wrote: > On Sun, Jan 9, 2011 at 9:51 AM, Willy Tarreau wrote: > >> The server will check the input stream, looking for the bytes "G" and "E". >> If those bytes do not appear, it will terminate the connection because it >> means this connection will require too many blocks to get the correct values. > > Nice observation. This issue was raised some weeks ago -- the answer is simply to not allow the client to alter the message after it has been handed off to the network layer. Even if some streaming API were exposed to JS, you would send a message fragment in its own frame when the buffer filled up -- the key from that frame would be useless for the attacker for the next frame. If one day JS adds the ability to send large byte buffers, the browser will just have to enforce copy-on-write or some similar mechanism to avoid letting the JS code change the buffer after the server might have received some portion of the message. > The major cost is that an ordinary server cannot start processing the > message until the per-msg > key is received at the end, but since we've already disclaimed most > streaming modes > of operation (and the client can't stream anyway because of the need > to commit to the > packet contents), this seems like a relatively minor cost. I think this is an unacceptable cost, as the server now must buffer every frame completely before handing bytes off to the next higher layer. Currently, the JS client has no way to modify the message being sent while the key for that frame is useful. If it ever does get that capability, it seems easier to address it there than to cripple every server implementation. -- John A. Tamplin Software Engineer (GWT), Google From jat@google.com Mon Jan 10 11:34:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D4028C0EF for ; Mon, 10 Jan 2011 11:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.726 X-Spam-Level: X-Spam-Status: No, score=-104.726 tagged_above=-999 required=5 tests=[AWL=-1.749, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T9gZ6wm7KAn for ; Mon, 10 Jan 2011 11:34:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id CF31A28B23E for ; Mon, 10 Jan 2011 11:34:40 -0800 (PST) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p0AJasFx025912 for ; Mon, 10 Jan 2011 11:36:54 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294688214; bh=3lW/DhNAVmG0rIwli8761Nm2pwc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=fi9KJGZRwO/0TOMN+nbk9YNLQ4QakxkgCOoH7fSnv4YBW0EnWKwTJK/ohHMLQfGWa DNn9V7XbQXKWO7sHE1IpA== Received: from ywe10 (ywe10.prod.google.com [10.192.5.10]) by hpaq14.eem.corp.google.com with ESMTP id p0AJaqcO031420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 10 Jan 2011 11:36:53 -0800 Received: by ywe10 with SMTP id 10so8552605ywe.38 for ; Mon, 10 Jan 2011 11:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=2vFNNT6+QByyR/wz48vVDeOcscNs/QZDa+5EE908i5M=; b=YcRGJP2mJpVPqaiw2sqhKadSDc/GtXZm7/+3ITmUsHg0bMNlI6Xs+Zd6BRbuooNxJy rH1zf/xFtrdMEUIOZWAg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ZdLzts/3/B4Gmz1xHomNWGDjJP7StfvPrdzG5GvlIO3bvg0G0Rvhq73S01ngLhTyto tYu+tnxj6FFt66MaXl4g== Received: by 10.151.143.12 with SMTP id v12mr29460467ybn.35.1294688212121; Mon, 10 Jan 2011 11:36:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Mon, 10 Jan 2011 11:36:32 -0800 (PST) In-Reply-To: References: <20110109175118.GP5743@1wt.eu> From: John Tamplin Date: Mon, 10 Jan 2011 14:36:32 -0500 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:34:42 -0000 On Mon, Jan 10, 2011 at 2:19 PM, Greg Wilkins wrote: > On 10 January 2011 19:59, Eric Rescorla wrote: >> I'm not sure precisely what you mean by "masked frames". If I were king,= things >> would look like this: >> >> - length >> - masked portion >> - key >> >> With everything else being packed into the masked portion. > > Well we are not that far apart, as was proposing > > =C2=A0- flags/opcode > =C2=A0- length > =C2=A0- masked portion > =C2=A0- key (in extension data) > > although as pointed out in a separate thread, that ordering makes our > 63 bit length a bit of overkill. Why does moving the key after the payload alter the utility of long lengths= ? However, this also means that extension data cannot affect interpretation of the payload data -- personally I am ok with that because I think the interpretation of the payload data should be controlled by the opcode, but during our earlier framing discussions there were several who felt otherwise. My main objection to putting the key after the payload is that it requires buffering of every frame from the client. Aside from latency issues from the buffering, this imposes a significant cost on servers handling many connections simultaneously. > As I was an advocate for smaller frames and fragmentation, I'd have no > issue with reducing the max frame size so that the key could be sent > afterwards. =C2=A0 But I see no will to revisit framing, so that leaves u= s > with: > > =C2=A0- flags/opcode > =C2=A0- key (in extension data) > =C2=A0- length > =C2=A0- masked portion The current framing has the length before the extension data. > Plus if the masking is an extension then objections to cryptographic > masking are less. If browsers are going to require it and Dave's statement about UK crypto restrictions is correct, it would still limit the ability to deploy infrastructure and server that are compatible with browser-based clients (which initially will be the 99% case). --=20 John A. Tamplin Software Engineer (GWT), Google From dave@cridland.net Mon Jan 10 11:35:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D9228C0EF for ; Mon, 10 Jan 2011 11:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BssCDa0gHt1u for ; Mon, 10 Jan 2011 11:35:31 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 21E5128B23E for ; Mon, 10 Jan 2011 11:35:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8EC79116811D; Mon, 10 Jan 2011 19:37:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZmlysjZPJ4u; Mon, 10 Jan 2011 19:37:38 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 3369611680FB; Mon, 10 Jan 2011 19:37:38 +0000 (GMT) References: <2948.1294683316.925357@puncture> In-Reply-To: MIME-Version: 1.0 Message-Id: <2948.1294688258.221233@puncture> Date: Mon, 10 Jan 2011 19:37:38 +0000 From: Dave Cridland To: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= , Server-Initiated HTTP Content-Type: text/plain; delsp="yes"; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:35:32 -0000 On Mon Jan 10 18:18:35 2011, Ian Fette (イアンフェッティ) wrote: > Please god no. We're just now at the point of hopefully getting > agreement on > the handshake and being able to ship something, let us not re-open > the whole > framing debate or it will be 2012 before we ship anything. Well, indeed, but given EKR's recent message, I feel it's rather too late to do anything but, unfortunately. EKR's already suggesting a length|payload|key framing, after all, and there's little point in having the length twice. But note that during the masking debate, any requirements which ran contrary to masking were discarded, so many of the requirements we based this framing design on are no longer in force anyway. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From jat@google.com Mon Jan 10 11:44:10 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1004F28C0FC for ; Mon, 10 Jan 2011 11:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.7 X-Spam-Level: X-Spam-Status: No, score=-104.7 tagged_above=-999 required=5 tests=[AWL=-1.723, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y658054+HHw for ; Mon, 10 Jan 2011 11:44:09 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id BC8CD28C0F1 for ; Mon, 10 Jan 2011 11:44:08 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p0AJkMpH031760 for ; Mon, 10 Jan 2011 11:46:22 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294688782; bh=wWg6LVrAJ2U8yPbiSGXS5gNF+WY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CoQ5++yUnFIYqvbGNL4oSiP80894ipNCa0HjXPYCEFrxmyWDbDZWQ5Sg45S4vrtCK KZKsbCq4uvGp2PUzFTrag== Received: from ywi6 (ywi6.prod.google.com [10.192.9.6]) by kpbe14.cbf.corp.google.com with ESMTP id p0AJjABQ026979 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 10 Jan 2011 11:46:20 -0800 Received: by ywi6 with SMTP id 6so8021364ywi.6 for ; Mon, 10 Jan 2011 11:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=Ciyms2rD6+gUsi8pSBOXsLDNW6hyizJYaZqU+RZyhY0=; b=tHeB98ztSIFs8l5OTl4cd/UWm3VG29sXPtvZydObenvyOVieoPRiMib3BSLLyZC3zG B9O5n6xa3NDIOrgtP5sA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=nFmzOy6MDDNOs0/sC86+WczRLQtUVU2Kqg+afrcYljtpFhVWqzHJupkMQcvytEJJBB 2nAvYRK7vrhR6mI9hC1A== Received: by 10.150.91.18 with SMTP id o18mr29442950ybb.92.1294688780550; Mon, 10 Jan 2011 11:46:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Mon, 10 Jan 2011 11:46:00 -0800 (PST) In-Reply-To: <2948.1294683316.925357@puncture> References: <2948.1294683316.925357@puncture> From: John Tamplin Date: Mon, 10 Jan 2011 14:46:00 -0500 Message-ID: To: Dave Cridland Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Server-Initiated HTTP Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:44:10 -0000 On Mon, Jan 10, 2011 at 1:15 PM, Dave Cridland wrote: > Much of the design of the framing was in support of being able to perform > lightweight streaming and sendfile() operations. Many of us went along with > various very vocal requests for this, leading to a 63-bit frame size, for > example, which is impractical with masking. We all, I think, universally > assumed a symmetric framing, whereas we have now discarded the symmetry > anyway. Why is a 63-bit frame size impractical with masking? As long as the masking key is before the payload that is masked, you can apply it as you go with minimal cost. The server->client connection isn't masked, and the proponents of sendfile() compatibility were talking about the server, so that hasn't changed either. > Given that we now require making, and (as EKR points out in another mail), > this in turn requires that the per-frame key is transmitted at the end of > each block, which damages streaming, should we be revisisting these early > design decisions? I do not believe it is necessary or desirable to place the key at the end of the frame. What is required is that the client can't alter the payload of a frame while it is in progress. For a streaming application, I would expect the typical application to have a buffer and to write a fragment when the buffer is full or the message is terminated - which doesn't allow the client to alter the message after the server might have received the key. The one case which might be a problem in the future, is when JS supports a byte buffer API -- the browser would just have to make sure that the JS code can't modify the byte buffer while the message is being written to the network. -- John A. Tamplin Software Engineer (GWT), Google From mcmanus@ducksong.com Mon Jan 10 11:46:36 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D2628C106 for ; Mon, 10 Jan 2011 11:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8BEUY+H5V9G for ; Mon, 10 Jan 2011 11:46:35 -0800 (PST) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by core3.amsl.com (Postfix) with ESMTP id 78A2228C0FF for ; Mon, 10 Jan 2011 11:46:35 -0800 (PST) Received: by linode.ducksong.com (Postfix, from userid 1000) id A3BB610300; Mon, 10 Jan 2011 14:48:49 -0500 (EST) 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 C400910305; Mon, 10 Jan 2011 14:48:42 -0500 (EST) From: "Pat McManus @Mozilla" To: John Tamplin In-Reply-To: References: <20110109175118.GP5743@1wt.eu> Content-Type: text/plain; charset="UTF-8" Date: Mon, 10 Jan 2011 14:48:29 -0500 Message-ID: <1294688909.7650.693.camel@ds9.ducksong.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:46:36 -0000 Breaking streaming by placing the key after the message is a cost out of proportion to the benefit I see. Heretofore masking has been a marginal cpu tax in exchange for a small reduction in risk, but placing the key at the end of the message sacrifices an important property of websockets. We should work to keep that in place. -- http://www.getfirefox.com/ From gregw@intalio.com Mon Jan 10 11:50:32 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D192228C0E4 for ; Mon, 10 Jan 2011 11:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLZk-fAgM3s7 for ; Mon, 10 Jan 2011 11:50:32 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D9DB828C0F4 for ; Mon, 10 Jan 2011 11:50:31 -0800 (PST) Received: by qwi2 with SMTP id 2so4449770qwi.31 for ; Mon, 10 Jan 2011 11:52:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.36.208 with SMTP id u16mr27178032qad.299.1294689165984; Mon, 10 Jan 2011 11:52:45 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Mon, 10 Jan 2011 11:52:45 -0800 (PST) In-Reply-To: References: <20110109175118.GP5743@1wt.eu> Date: Mon, 10 Jan 2011 20:52:45 +0100 X-Google-Sender-Auth: ljZEE8LFiSWsKt2QTwecBk1GrkI Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:50:32 -0000 On 10 January 2011 20:36, John Tamplin wrote: > Why does moving the key after the payload alter the utility of long lengt= hs? because you have to hold 2^63 bytes of data before you get the key which you need to decode the data. So you can't process the data as you go. >> =A0- flags/opcode >> =A0- key (in extension data) >> =A0- length >> =A0- masked portion > > The current framing has the length before the extension data. oops yes.. but it's essentially the same. From ifette@google.com Mon Jan 10 12:16:19 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F390A28C0E5 for ; Mon, 10 Jan 2011 12:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.001 X-Spam-Level: X-Spam-Status: No, score=-104.001 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnEyJE59MnmM for ; Mon, 10 Jan 2011 12:16:18 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C37FA28C0F9 for ; Mon, 10 Jan 2011 12:16:17 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p0AKIVtM025471 for ; Mon, 10 Jan 2011 12:18:31 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294690712; bh=53wJvmhK6kvSxdOsoj6HEgCtzdM=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=B64/YRSna/59C5LK8h1lao44PsST0Xa92wzMGWcFC0AXpoznmYqyh9meYMR5K7oko ebs7WtFeJV2WZAZmoDZtg== Received: from qyk1 (qyk1.prod.google.com [10.241.83.129]) by hpaq11.eem.corp.google.com with ESMTP id p0AKGMKi005925 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 10 Jan 2011 12:18:30 -0800 Received: by qyk1 with SMTP id 1so1797077qyk.18 for ; Mon, 10 Jan 2011 12:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Mgwfpt+2vMI9PNlvqkXyvd8woIeILka7oKiPN7qh0kA=; b=Fh7xVojDOpPx6sa1McQIXkPF5ikpNMR5NBmR5bknnf9YwbuFy4D0xpRwTQlmHyiqE3 ZjyrUfqeE5mWEJH37v9g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=tOc+GMVysMCdrq83/ul1uvGUfkv8ywgRTIvjX7GpCLyVjZjaikeCGt07PTzYM1ABBd 4/ZlAEe5cnMJJuBoB6VQ== MIME-Version: 1.0 Received: by 10.229.242.83 with SMTP id lh19mr25531736qcb.226.1294690708627; Mon, 10 Jan 2011 12:18:28 -0800 (PST) Received: by 10.229.0.137 with HTTP; Mon, 10 Jan 2011 12:18:28 -0800 (PST) In-Reply-To: References: <2948.1294683316.925357@puncture> Date: Mon, 10 Jan 2011 12:18:28 -0800 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: John Tamplin Content-Type: multipart/alternative; boundary=0016363b8e7ac822f8049983ab61 X-System-Of-Record: true Cc: Server-Initiated HTTP Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:16:19 -0000 --0016363b8e7ac822f8049983ab61 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 10, 2011 at 11:46 AM, John Tamplin wrote: > On Mon, Jan 10, 2011 at 1:15 PM, Dave Cridland wrote: > > Much of the design of the framing was in support of being able to perform > > lightweight streaming and sendfile() operations. Many of us went along > with > > various very vocal requests for this, leading to a 63-bit frame size, for > > example, which is impractical with masking. We all, I think, universally > > assumed a symmetric framing, whereas we have now discarded the symmetry > > anyway. > > Why is a 63-bit frame size impractical with masking? As long as the > masking key is before the payload that is masked, you can apply it as > you go with minimal cost. The server->client connection isn't masked, > and the proponents of sendfile() compatibility were talking about the > server, so that hasn't changed either. > > > Given that we now require making, and (as EKR points out in another > mail), > > this in turn requires that the per-frame key is transmitted at the end of > > each block, which damages streaming, should we be revisisting these early > > design decisions? > > I do not believe it is necessary or desirable to place the key at the > end of the frame. What is required is that the client can't alter the > payload of a frame while it is in progress. For a streaming > application, I would expect the typical application to have a buffer > and to write a fragment when the buffer is full or the message is > terminated - which doesn't allow the client to alter the message after > the server might have received the key. The one case which might be a > problem in the future, is when JS supports a byte buffer API -- the > browser would just have to make sure that the JS code can't modify the > byte buffer while the message is being written to the network. > > I would personally agree that I don't want to see the key at the end. It makes it impossible to do anything useful with it until we have all the data, which seems tragic. -Ian > -- > John A. Tamplin > Software Engineer (GWT), Google > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016363b8e7ac822f8049983ab61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 10, 2011 at 11:46 AM, John Tamplin <= span dir=3D"ltr"><jat@google.com&g= t; wrote:
On Mon, Jan 10, 2011 at 1:15 PM, Dave Cridland <dave@cridland.net> wrote:
> Much of the design of the framing was in support of being able to perf= orm
> lightweight streaming and sendfile() operations. Many of us went along= with
> various very vocal requests for this, leading to a 63-bit frame size, = for
> example, which is impractical with masking. We all, I think, universal= ly
> assumed a symmetric framing, whereas we have now discarded the symmetr= y
> anyway.

Why is a 63-bit frame size impractical with masking? =C2=A0As long as= the
masking key is before the payload that is masked, you can apply it as
you go with minimal cost. =C2=A0The server->client connection isn't = masked,
and the proponents of sendfile() compatibility were talking about the
server, so that hasn't changed either.

> Given that we now require making, and (as EKR points out in another ma= il),
> this in turn requires that the per-frame key is transmitted at the end= of
> each block, which damages streaming, should we be revisisting these ea= rly
> design decisions?

I do not believe it is necessary or desirable to place the key at the=
end of the frame. =C2=A0What is required is that the client can't alter= the
payload of a frame while it is in progress. =C2=A0For a streaming
application, I would expect the typical application to have a buffer
and to write a fragment when the buffer is full or the message is
terminated - which doesn't allow the client to alter the message after<= br> the server might have received the key. =C2=A0The one case which might be a=
problem in the future, is when JS supports a byte buffer API -- the
browser would just have to make sure that the JS code can't modify the<= br> byte buffer while the message is being written to the network.


I would= personally agree that I don't want to see the key at the end. It makes= it impossible to do anything useful with it until we have all the data, wh= ich seems tragic.=C2=A0

-Ian
=C2=A0
--
John A. Tamplin
Software Engineer (GWT), Google
__________________________________= _____________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--0016363b8e7ac822f8049983ab61-- From gregw@intalio.com Mon Jan 10 12:51:44 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554DD3A6768 for ; Mon, 10 Jan 2011 12:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYcGHn6mL-tB for ; Mon, 10 Jan 2011 12:51:43 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id E156C3A672E for ; Mon, 10 Jan 2011 12:51:42 -0800 (PST) Received: by qwi2 with SMTP id 2so4511646qwi.31 for ; Mon, 10 Jan 2011 12:53:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.236.134 with SMTP id kk6mr24052392qcb.93.1294692837257; Mon, 10 Jan 2011 12:53:57 -0800 (PST) Sender: gregw@intalio.com Received: by 10.220.160.12 with HTTP; Mon, 10 Jan 2011 12:53:57 -0800 (PST) In-Reply-To: References: <2948.1294683316.925357@puncture> Date: Mon, 10 Jan 2011 21:53:57 +0100 X-Google-Sender-Auth: Iz1bJDiLbNgjC0CmGV1ahYHoxIc Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:51:44 -0000 2011/1/10 Ian Fette ($B%$%"%s%U%'%C%F%#(B) : > I would personally agree that I don't want to see the key at the end. It > makes it impossible to do anything useful with it until we have all the > data, which seems tragic. I'm neutral on the key before / key after issue (as I'm not a fan of streaming and would have been happy with a 16 bit length). But it is good to see that an advocate of strong masking are prepared to accept unmasked framing in the form of length data key as that is only a few short step to opcode length key data and then we can keep our framing as is. From dave@cridland.net Mon Jan 10 13:04:53 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B527D3A6778 for ; Mon, 10 Jan 2011 13:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyisQLk5gJEr for ; Mon, 10 Jan 2011 13:04:52 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 771C33A6767 for ; Mon, 10 Jan 2011 13:04:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id E4C4A116811F; Mon, 10 Jan 2011 21:07:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9iNHJ8IfVlA; Mon, 10 Jan 2011 21:07:01 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id B65F111680FB; Mon, 10 Jan 2011 21:07:01 +0000 (GMT) References: <2948.1294683316.925357@puncture> In-Reply-To: MIME-Version: 1.0 Message-Id: <2948.1294693621.741254@puncture> Date: Mon, 10 Jan 2011 21:07:01 +0000 From: Dave Cridland To: Greg Wilkins , Server-Initiated HTTP Content-Type: text/plain; delsp="yes"; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:04:53 -0000 On Mon Jan 10 20:53:57 2011, Greg Wilkins wrote: > 2011/1/10 Ian Fette (イアンフェッティ) : > > I would personally agree that I don't want to see the key at the > end. It > > makes it impossible to do anything useful with it until we have > all the > > data, which seems tragic. > > I'm neutral on the key before / key after issue (as I'm not a fan of > streaming and would have been happy with a 16 bit length). > > But it is good to see that an advocate of strong masking are > prepared > to accept unmasked framing in the form of > > length > data > key > > as that is only a few short step to > > opcode > length > key > data > > and then we can keep our framing as is. Well, you can't have the length at the front of the frame, obviously. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dave@cridland.net Mon Jan 10 13:11:58 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4E63A67E1 for ; Mon, 10 Jan 2011 13:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZzBVfH+OsrX for ; Mon, 10 Jan 2011 13:11:56 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 5EE4B3A67DA for ; Mon, 10 Jan 2011 13:11:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id E61F7116811E; Mon, 10 Jan 2011 21:14:09 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T6KUtJeuzzz; Mon, 10 Jan 2011 21:14:05 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id C138D11680FB; Mon, 10 Jan 2011 21:14:05 +0000 (GMT) References: <2948.1294683316.925357@puncture> <2948.1294693621.096557@puncture> In-Reply-To: <2948.1294693621.096557@puncture> MIME-Version: 1.0 Message-Id: <2948.1294694045.801094@puncture> Date: Mon, 10 Jan 2011 21:14:05 +0000 From: Dave Cridland To: Dave Cridland , Greg Wilkins , Server-Initiated HTTP Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:11:58 -0000 On Mon Jan 10 21:07:01 2011, Dave Cridland wrote: > Well, you can't have the length at the front of the frame, > obviously. Well, maybe not so obvious - a length of between 5135603447290989056 and 5135603447290989311 inclusive encodes as a string of 'GET / \r\n' followed by a junk octet. As a 63-bit length, this would be valid if we assume a 64-bit length field. Same problem - an attacker controls the bits on the wire, only this time they're controlling the ideal bits on the wire to mount their attack. I don't think, for a moment, that an attacker within a browser's sandbox is likely to be able to coerce WebSocket into sending such a frame, given it's pushing 4.5 petabytes, but I suppose a browser might have some length overflow/underflow case that's exploitable in this way. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From fenix@google.com Mon Jan 10 13:24:28 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1AD3A6816 for ; Mon, 10 Jan 2011 13:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.014 X-Spam-Level: X-Spam-Status: No, score=-104.014 tagged_above=-999 required=5 tests=[AWL=-2.791, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFHOCLgtMzCa for ; Mon, 10 Jan 2011 13:24:27 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 9ABCF3A6801 for ; Mon, 10 Jan 2011 13:24:26 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p0ALQerV005374 for ; Mon, 10 Jan 2011 13:26:40 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294694800; bh=PXByOdfph4tPRTkgkZuSmohUCpI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=csYXmLidNwm9GI74TQRn4/Bus/Ox7blp0RjRMv3H6tG/TrNzLKOmwbEhnzruqIlBu DBTyjegnAf0BS0NUHPcyg== Received: from gwj21 (gwj21.prod.google.com [10.200.10.21]) by wpaz9.hot.corp.google.com with ESMTP id p0ALQc3K017935 for ; Mon, 10 Jan 2011 13:26:39 -0800 Received: by gwj21 with SMTP id 21so9312562gwj.41 for ; Mon, 10 Jan 2011 13:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ieH80ws3WJoeKf4GKOY9kpO87SB4sUP08z00kNlqNLo=; b=boCcGskRsGqOYE/QP7yDq1/7Gf05vZEm2Aefg8sQmi8+aymL4CYhdwcAzMfI/RmYeX xRm7UXidM+4nYxnt5+3A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hVuJiHhoOwMTgsPcXlUg52eMgfmP/BmIvJQooTg4rpT55myABC6VH/kEnnRfll62Yb J5wih8wilIkcx5BlFWzA== MIME-Version: 1.0 Received: by 10.150.185.2 with SMTP id i2mr28471497ybf.155.1294694797806; Mon, 10 Jan 2011 13:26:37 -0800 (PST) Received: by 10.151.116.9 with HTTP; Mon, 10 Jan 2011 13:26:37 -0800 (PST) In-Reply-To: References: <2948.1294683316.925357@puncture> Date: Mon, 10 Jan 2011 13:26:37 -0800 Message-ID: From: Roberto Peon To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd47d1a84129b0499849ff2 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:24:28 -0000 --000e0cd47d1a84129b0499849ff2 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Having the mask-key at the end makes it hard to do the right thing quickly (low latency), or efficiently (low memory) for medium to large sized messages assuming no fragmentation. I do prefer having the frame include the key (e.g. as Greg proposes) in the initial framing data. I don't believe that the length bits are an interesting attack vector as the browser would need something that size before it could encode that length. Or are we assuming that the browser will send the header before it has all of the data for the message? That'd be bizzare. -=R On Mon, Jan 10, 2011 at 12:53 PM, Greg Wilkins wrote: > 2011/1/10 Ian Fette ($B%$%"%s%U%'%C%F%#(B) : > > I would personally agree that I don't want to see the key at the end. It > > makes it impossible to do anything useful with it until we have all the > > data, which seems tragic. > > I'm neutral on the key before / key after issue (as I'm not a fan of > streaming and would have been happy with a 16 bit length). > > But it is good to see that an advocate of strong masking are prepared > to accept unmasked framing in the form of > > length > data > key > > as that is only a few short step to > > opcode > length > key > data > > and then we can keep our framing as is. > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd47d1a84129b0499849ff2 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 SGF2aW5nIHRoZSBtYXNrLWtleSBhdCB0aGUgZW5kIG1ha2VzIGl0IGhhcmQgdG8gZG8gdGhlIHJp Z2h0IHRoaW5nIHF1aWNrbHkgKGxvdyBsYXRlbmN5KSwgb3IgZWZmaWNpZW50bHkgKGxvdyBtZW1v cnkpIGZvciBtZWRpdW0gdG8gbGFyZ2Ugc2l6ZWQgbWVzc2FnZXMgYXNzdW1pbmcgbm8gZnJhZ21l bnRhdGlvbi48ZGl2PkkgZG8gcHJlZmVyIGhhdmluZyB0aGUgZnJhbWUgaW5jbHVkZSB0aGUga2V5 IChlLmcuIGFzIEdyZWcgcHJvcG9zZXMpIGluIHRoZSBpbml0aWFsIGZyYW1pbmcgZGF0YS48L2Rp dj4KPGRpdj48YnI+PC9kaXY+PGRpdj5JIGRvbiYjMzk7dCBiZWxpZXZlIHRoYXQgdGhlIGxlbmd0 aCBiaXRzIGFyZSBhbiBpbnRlcmVzdGluZyBhdHRhY2sgdmVjdG9yIGFzIHRoZSBicm93c2VyIHdv dWxkIG5lZWQgc29tZXRoaW5nIHRoYXQgc2l6ZSBiZWZvcmUgaXQgY291bGQgZW5jb2RlIHRoYXQg bGVuZ3RoLjwvZGl2PjxkaXY+T3IgYXJlIHdlIGFzc3VtaW5nIHRoYXQgdGhlIGJyb3dzZXIgd2ls bCBzZW5kIHRoZSBoZWFkZXIgYmVmb3JlIGl0IGhhcyBhbGwgb2YgdGhlIGRhdGEgZm9yIHRoZSBt ZXNzYWdlPyBUaGF0JiMzOTtkIGJlIGJpenphcmUuPC9kaXY+CjxkaXY+LT1SPC9kaXY+PGRpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBK YW4gMTAsIDIwMTEgYXQgMTI6NTMgUE0sIEdyZWcgV2lsa2lucyA8c3BhbiBkaXI9Imx0ciI+Jmx0 OzxhIGhyZWY9Im1haWx0bzpncmVnd0B3ZWJ0aWRlLmNvbSI+Z3JlZ3dAd2VidGlkZS5jb208L2E+ Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXg7Ij4KMjAxMS8xLzEwIElhbiBGZXR0ZSAoGyRCJSQlIiVzJVUlJyVDJUYlIxsoQikg Jmx0OzxhIGhyZWY9Im1haWx0bzppZmV0dGVAZ29vZ2xlLmNvbSI+aWZldHRlQGdvb2dsZS5jb208 L2E+Jmd0Ozo8YnI+CjxkaXYgY2xhc3M9ImltIj4mZ3Q7IEkgd291bGQgcGVyc29uYWxseSBhZ3Jl ZSB0aGF0IEkgZG9uJiMzOTt0IHdhbnQgdG8gc2VlIHRoZSBrZXkgYXQgdGhlIGVuZC4gSXQ8YnI+ CiZndDsgbWFrZXMgaXQgaW1wb3NzaWJsZSB0byBkbyBhbnl0aGluZyB1c2VmdWwgd2l0aCBpdCB1 bnRpbCB3ZSBoYXZlIGFsbCB0aGU8YnI+CiZndDsgZGF0YSwgd2hpY2ggc2VlbXMgdHJhZ2ljLjxi cj4KPGJyPgo8L2Rpdj5JJiMzOTttIG5ldXRyYWwgb24gdGhlIGtleSBiZWZvcmUgLyBrZXkgYWZ0 ZXIgaXNzdWUgKGFzIEkmIzM5O20gbm90IGEgZmFuIG9mPGJyPgpzdHJlYW1pbmcgYW5kIHdvdWxk IGhhdmUgYmVlbiBoYXBweSB3aXRoIGEgMTYgYml0IGxlbmd0aCkuPGJyPgo8YnI+CkJ1dCBpdCBp cyBnb29kIHRvIHNlZSB0aGF0IGFuIGFkdm9jYXRlIG9mIHN0cm9uZyBtYXNraW5nIGFyZSBwcmVw YXJlZDxicj4KdG8gYWNjZXB0IHVubWFza2VkIGZyYW1pbmcgaW4gdGhlIGZvcm0gb2Y8YnI+Cjxi cj4KICZuYnNwOyBsZW5ndGg8YnI+CiAmbmJzcDsgZGF0YTxicj4KICZuYnNwOyBrZXk8YnI+Cjxi cj4KYXMgdGhhdCBpcyBvbmx5IGEgZmV3IHNob3J0IHN0ZXAgdG88YnI+Cjxicj4KICZuYnNwO29w Y29kZTxicj4KICZuYnNwO2xlbmd0aDxicj4KICZuYnNwO2tleTxicj4KICZuYnNwO2RhdGE8YnI+ Cjxicj4KYW5kIHRoZW4gd2UgY2FuIGtlZXAgb3VyIGZyYW1pbmcgYXMgaXMuPGJyPgo8ZGl2Pjxk aXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPgpoeWJpIG1haWxpbmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRv Omh5YmlAaWV0Zi5vcmciPmh5YmlAaWV0Zi5vcmc8L2E+PGJyPgo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5YmkiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5Ymk8L2E+PGJyPgo8L2Rpdj48L2Rpdj48 L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2Pgo= --000e0cd47d1a84129b0499849ff2-- From bruce@callenish.com Mon Jan 10 13:30:11 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB13C3A681E for ; Mon, 10 Jan 2011 13:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOteSbiPOtoD for ; Mon, 10 Jan 2011 13:30:10 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id 7C2733A67F4 for ; Mon, 10 Jan 2011 13:30:10 -0800 (PST) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1PcPLk-0006xC-B7 for hybi@ietf.org; Mon, 10 Jan 2011 13:32:24 -0800 Message-ID: <4D2B7AE9.2050101@callenish.com> Date: Mon, 10 Jan 2011 13:32:25 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Hybi References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com Subject: Re: [hybi] It's time to ship X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:30:11 -0000 Adam, I've read over your protocol spec. I've carefully considered it, and I've decided I will not use it in any application I design. There are always alternatives. I will use something that is better suited to my needs. I'd offer more constructive feedback but I am convinced I will be ignored. I wish you all the best with shipping your protocol. I am sure many people will be very interested in it. Sincerely, Bruce. On 09/01/2011 4:46 PM, Adam Barth wrote: > On Sun, Jan 9, 2011 at 4:39 PM, Greg Wilkins wrote: >> On 9 January 2011 23:21, Adam Barth wrote: >>> Gentle people of hybi, >>> >>> There's been a lot of good discussion in this working group gathering >>> consensus around the data framing and the handshake. At some point we >>> need to declare victory and ship the protocol, otherwise proprietary >>> solutions will continue to eat our lunch. >>> >>> I've written up a more formal version of Pat's proposal based on the >>> recent straw poll and subsequent discussion. This protocol is by no >>> means perfect, but it's good enough: >>> >>> http://www.ietf.org/id/draft-abarth-thewebsocketprotocol-01.txt >> I cannot agree this proposal. > Thanks for your feedback. I'd encourage you not to implement this > protocol then. > > Kind regards, > Adam > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From dave@cridland.net Mon Jan 10 13:36:17 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFBE3A680C for ; Mon, 10 Jan 2011 13:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMwMLgyuMxmK for ; Mon, 10 Jan 2011 13:36:16 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 88FA73A67DA for ; Mon, 10 Jan 2011 13:36:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 1925B116811D; Mon, 10 Jan 2011 21:38:30 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYVtGXXQzV+b; Mon, 10 Jan 2011 21:38:26 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id F0C5711680FB; Mon, 10 Jan 2011 21:38:25 +0000 (GMT) References: <2948.1294683316.925357@puncture> In-Reply-To: MIME-Version: 1.0 Message-Id: <2948.1294695505.996045@puncture> Date: Mon, 10 Jan 2011 21:38:25 +0000 From: Dave Cridland To: Roberto Peon , Server-Initiated HTTP , Greg Wilkins Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:36:17 -0000 On Mon Jan 10 21:26:37 2011, Roberto Peon wrote: > I don't believe that the length bits are an interesting attack > vector as the > browser would need something that size before it could encode that > length. > Or are we assuming that the browser will send the header before it > has all > of the data for the message? That'd be bizzare. Well, I don't believe that the attacks mitigated by the masking are an interesting attack vector, but we're still protecting against it. If such a vulnerability in the length encoding were exploited, I'd expect it to be exploited by a bug in the length calculation of the browser's framing implementation, and not by actually trying to send that much data. But given the working group's attitude to protecting against theoretical bugs in the intermediaries and servers, I figured I ought to raise this possibility at least. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From fenix@google.com Mon Jan 10 13:37:50 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A63A3A6827 for ; Mon, 10 Jan 2011 13:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.192 X-Spam-Level: X-Spam-Status: No, score=-104.192 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3EhoqvjbT30 for ; Mon, 10 Jan 2011 13:37:49 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 5B51C3A680C for ; Mon, 10 Jan 2011 13:37:49 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p0ALe3gb002891 for ; Mon, 10 Jan 2011 13:40:03 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294695603; bh=n5aTtqPL0TBZAm/J3wIuJd1cwP0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=xQnml6wZ0xRI03MsUD4IAloEkZ2xeDCdFshpaNIB93f3tDcG0hrIhehr0I/NwSWRJ KrK9Gn+G4QReG2KzQNXwg== Received: from yxi11 (yxi11.prod.google.com [10.190.3.11]) by hpaq12.eem.corp.google.com with ESMTP id p0ALe1dE009149 for ; Mon, 10 Jan 2011 13:40:02 -0800 Received: by yxi11 with SMTP id 11so10055199yxi.2 for ; Mon, 10 Jan 2011 13:40:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=wFbyy5Nm2TgM7dGNaaAHgJVIARUlRsbDHd1k9xDdtHQ=; b=InVpal9q4fL+hFMigop1PyptRYMHGuxrKbHZwgOheb8pXnT1Lc2gPKnnFvsXfIx08n fQQ2pu3hZjkWIZA45GVw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RfJTqVoltljhd+oJdA/qIyPVJblXfKVEFyj3KP6UNAcwP8PcEtgub8FmOOjl/h3872 EFAZ7ekvxt/FxpWXBU2w== MIME-Version: 1.0 Received: by 10.151.101.14 with SMTP id d14mr7228292ybm.326.1294695601291; Mon, 10 Jan 2011 13:40:01 -0800 (PST) Received: by 10.151.116.9 with HTTP; Mon, 10 Jan 2011 13:40:00 -0800 (PST) In-Reply-To: <2948.1294695505.996045@puncture> References: <2948.1294683316.925357@puncture> <2948.1294695505.996045@puncture> Date: Mon, 10 Jan 2011 13:40:00 -0800 Message-ID: From: Roberto Peon To: Dave Cridland Content-Type: multipart/alternative; boundary=00151751149e684462049984cfe7 X-System-Of-Record: true Cc: Server-Initiated HTTP Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:37:50 -0000 --00151751149e684462049984cfe7 Content-Type: text/plain; charset=ISO-8859-1 Okdokie, thanks for the explanation! -=R On Mon, Jan 10, 2011 at 1:38 PM, Dave Cridland wrote: > On Mon Jan 10 21:26:37 2011, Roberto Peon wrote: > >> I don't believe that the length bits are an interesting attack vector as >> the >> browser would need something that size before it could encode that length. >> Or are we assuming that the browser will send the header before it has all >> of the data for the message? That'd be bizzare. >> > > Well, I don't believe that the attacks mitigated by the masking are an > interesting attack vector, but we're still protecting against it. > > If such a vulnerability in the length encoding were exploited, I'd expect > it to be exploited by a bug in the length calculation of the browser's > framing implementation, and not by actually trying to send that much data. > But given the working group's attitude to protecting against theoretical > bugs in the intermediaries and servers, I figured I ought to raise this > possibility at least. > > > Dave. > -- > Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > --00151751149e684462049984cfe7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Okdokie, thanks for the explanation!
-=3DR

On Mon, Jan 10, 2011 at 1:38 PM, Dave Cridland <= dave@cridland.net> wrote= :
On Mon Jan 10 21:26:37 20= 11, Roberto Peon wrote:
I don't believe that the length bits are an interesting attack vector a= s the
browser would need something that size before it could encode that length.<= br> Or are we assuming that the browser will send the header before it has all<= br> of the data for the message? That'd be bizzare.

Well, I don't believe that the attacks mitigated by the masking are an = interesting attack vector, but we're still protecting against it.

If such a vulnerability in the length encoding were exploited, I'd expe= ct it to be exploited by a bug in the length calculation of the browser'= ;s framing implementation, and not by actually trying to send that much dat= a. But given the working group's attitude to protecting against theoret= ical bugs in the intermediaries and servers, I figured I ought to raise thi= s possibility at least.


Dave.
--
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
=A0- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/=
=A0- http://dave.cr= idland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

--00151751149e684462049984cfe7-- From salvatore.loreto@ericsson.com Mon Jan 10 14:38:39 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44F928C0E1 for ; Mon, 10 Jan 2011 14:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Pc-9X87gaMQ for ; Mon, 10 Jan 2011 14:38:38 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A190228C106 for ; Mon, 10 Jan 2011 14:38:22 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-27-4d2b8ae39bd5 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 60.C2.23694.3EA8B2D4; Mon, 10 Jan 2011 23:40:36 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Mon, 10 Jan 2011 23:40:35 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9D898251F; Tue, 11 Jan 2011 00:40:35 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6117C50547; Tue, 11 Jan 2011 00:40:35 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BA03E50546; Tue, 11 Jan 2011 00:40:34 +0200 (EET) Message-ID: <4D2B8AE2.30207@ericsson.com> Date: Mon, 10 Jan 2011 23:40:34 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Joe Hildebrand , =?UTF-8?B?IklhbiBGZXR0ZSAo?= Subject: [hybi] GET+Upgrade+XOR in 04 version X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 22:38:39 -0000 Hi there, Joe and I, as chairs, would like to see a -04 version of the draft-ietf-hybi-thewebsocketprotocol that reflect both the consensus we reached based on the poll and what's been discussed the most: "GET+Upgrade and XOR". However because because there are still on going discussions on how to mask and OPTIONS has been recently proposed as an alternative to GET we have decided to hold, after the 04 version will be released, two separate polls 1) OPTIONS vs GET 2) a straw poll to resolve the question of masking the -05 version will then be based on the result of those polls. cheers /Sal -- Salvatore Loreto www.sloreto.com From w@1wt.eu Mon Jan 10 15:02:25 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1409B3A672F for ; Mon, 10 Jan 2011 15:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEje3JTp0TH1 for ; Mon, 10 Jan 2011 15:02:24 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id BDCB53A6403 for ; Mon, 10 Jan 2011 15:02:23 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0AN4U9t016315; Tue, 11 Jan 2011 00:04:30 +0100 Date: Tue, 11 Jan 2011 00:04:30 +0100 From: Willy Tarreau To: "Ian Fette (????????????????????????)" Message-ID: <20110110230430.GA16301@1wt.eu> References: <2948.1294683316.925357@puncture> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Server-Initiated HTTP Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:02:25 -0000 On Mon, Jan 10, 2011 at 12:18:28PM -0800, Ian Fette (????????????????????????) wrote: > On Mon, Jan 10, 2011 at 11:46 AM, John Tamplin wrote: > > > On Mon, Jan 10, 2011 at 1:15 PM, Dave Cridland wrote: > > > Much of the design of the framing was in support of being able to perform > > > lightweight streaming and sendfile() operations. Many of us went along > > with > > > various very vocal requests for this, leading to a 63-bit frame size, for > > > example, which is impractical with masking. We all, I think, universally > > > assumed a symmetric framing, whereas we have now discarded the symmetry > > > anyway. > > > > Why is a 63-bit frame size impractical with masking? As long as the > > masking key is before the payload that is masked, you can apply it as > > you go with minimal cost. The server->client connection isn't masked, > > and the proponents of sendfile() compatibility were talking about the > > server, so that hasn't changed either. > > > > > Given that we now require making, and (as EKR points out in another > > mail), > > > this in turn requires that the per-frame key is transmitted at the end of > > > each block, which damages streaming, should we be revisisting these early > > > design decisions? > > > > I do not believe it is necessary or desirable to place the key at the > > end of the frame. What is required is that the client can't alter the > > payload of a frame while it is in progress. For a streaming > > application, I would expect the typical application to have a buffer > > and to write a fragment when the buffer is full or the message is > > terminated - which doesn't allow the client to alter the message after > > the server might have received the key. The one case which might be a > > problem in the future, is when JS supports a byte buffer API -- the > > browser would just have to make sure that the JS code can't modify the > > byte buffer while the message is being written to the network. > > > > > I would personally agree that I don't want to see the key at the end. It > makes it impossible to do anything useful with it until we have all the > data, which seems tragic. indeed, and it would also make it impossible to send large frames. Right now we support lengths up to 63 bit, but anything more than a few tens of kB is going to be painful on some components, especially those which are designed to support vast amounts of concurrent connections. Willy > > -Ian > > > > -- > > John A. Tamplin > > Software Engineer (GWT), Google > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From w@1wt.eu Mon Jan 10 15:07:42 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2CC33A657C for ; Mon, 10 Jan 2011 15:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tlb29H3Ahu9 for ; Mon, 10 Jan 2011 15:07:41 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 686183A6403 for ; Mon, 10 Jan 2011 15:07:41 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0AN9t06016336; Tue, 11 Jan 2011 00:09:55 +0100 Date: Tue, 11 Jan 2011 00:09:55 +0100 From: Willy Tarreau To: Eric Rescorla Message-ID: <20110110230955.GB16301@1wt.eu> References: <20110109175118.GP5743@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Limitations of the XOR-based masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:07:42 -0000 Hi Eric, On Mon, Jan 10, 2011 at 07:52:50AM -0800, Eric Rescorla wrote: > On Sun, Jan 9, 2011 at 9:51 AM, Willy Tarreau wrote: > > > The server will check the input stream, looking for the bytes "G" and "E". > > If those bytes do not appear, it will terminate the connection because it > > means this connection will require too many blocks to get the correct values. > > Nice observation. > > I haven't gotten too much sleep but... > > As I understand your attack, the way this works is that you're > exploiting the fact that > the server gets information about the repeating mask to shut down unproductive > byte sequences before they have been transmitted over the wire. This makes sense > if you think that the network transmission is the rate limiting step. Yes that was the asumption. > The obvious countermeasure to this is to ensure that the server > doesn't learn anything > useful prior to receiving the whole packet. This can't be done with a > fixed mask for the > reasons you indicate but can be done with a generated mask, I believe. > Consider the > packet structure (omitting most framing bits) > > AES-CTR(K_msg, Payload) || K_msg > > In this case, no matter how much information the attacker has about > payload byte i, > he doesn't learn anything useful about expected ciphertext > (transmitted) byte i+1 > until the key is received (this is by definitional properties of > AES-CTR). So, the bytestream > on the wire is indistinguishable from random, precluding the attack > you describe. I also thought about that possibility, but it's clearly unusable on large frames due to the need to buffer everything before taking the simplest decision. Also, many intermediaries will have to receive a whole frame before forwarding it, adding up the serialization delays for each hop. And the emitter would receive no indication of any possible start of receipt which can be particularly annoying when sending large frames (eg: user uploading a photo in a rich application). Or we would have to define a new frame-based masking on top of current framing which would not permit large frames at all and which would always indicate all the information needed to parse and take decision. This becomes quite complex and counter-efficient for what it tries to solve :-/ Willy From brofield@gmail.com Mon Jan 10 16:09:55 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114623A6828 for ; Mon, 10 Jan 2011 16:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py9ftswDUsbL for ; Mon, 10 Jan 2011 16:09:53 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 80AF93A681D for ; Mon, 10 Jan 2011 16:09:53 -0800 (PST) Received: by qyk34 with SMTP id 34so2113587qyk.10 for ; Mon, 10 Jan 2011 16:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jBqQAeGDeXC71vUXR2PkitG5GefNsGFLXfX+g9bMosg=; b=WDwRAoXw/XTjwEbdFZ+6T6W/grd5pIGFWt+HL0YoHJQpIHwUhvnUqhtp/68STbtKBT 3lCjRaNlk6p8yuCM0DaVm6evDwxrX7OFLccPieAbopTEDbKe09V/AA41Vc7zH0VoxhCd c5hv2t+ya/r/PgupkWIawTRvAZTuHyLyaC7Ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=uNSGIff227HxjaMm+T9Nuypiqma1i1SkoJxanhr6ouWTinuNK0gPUOVmE/fcdK9l5h rcd2qhxFMYcatNHQpZA1qo8v03HOnMvOCmnYf8sHYINpbYeE/h2lcDkGVxuLb9B2tfjb QDG5If00I/v9Afj/LAhPGE6yObyfEMEJhEeMQ= MIME-Version: 1.0 Received: by 10.229.250.9 with SMTP id mm9mr25231971qcb.264.1294704728052; Mon, 10 Jan 2011 16:12:08 -0800 (PST) Sender: brofield@gmail.com Received: by 10.229.84.66 with HTTP; Mon, 10 Jan 2011 16:12:07 -0800 (PST) In-Reply-To: References: <4D26605B.1090409@callenish.com> <4D26DE2D.5040901@ericsson.com> Date: Tue, 11 Jan 2011 09:12:07 +0900 X-Google-Sender-Auth: N80VyKpgXnfE7utZ2LPzNi73i_U Message-ID: From: Brodie Thiesfield To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:09:55 -0000 On Tue, Jan 11, 2011 at 12:39 AM, Eric Rescorla wrote: > On Sun, Jan 9, 2011 at 7:00 PM, Brodie Thiesfield wrote: >> Where clients aren't behind NAT a direct connection can be used, when >> they are then a central hub relay. > > A better approach is to actually do hole punching. Seriously, there is > already IETF work > being spun up in this area. It will be informed by this WG, but it's a > different set of problems. > > Given that it's out of scope for this WG, we really should not be > considering it. Yes, I agree that hole punching would be better, and when the work is done it can be used. I'm not asking the WG to design p2p into the protocol. I'm suggesting that the protocol have a flexibility that would permit a basic p2p usage, rather than precluding it by design. The essential points are: * basic direct + central hub p2p is almost possible with the current protocol * since both client and server are browsers, both client and server will be wanting to send masked data * therefore the client needs to be able to receive and decode masked frames All that is required to enable simple p2p then is for the masking to be designed such that the recipient can detect that it is being used and unmask the data. To do this, either the client must be informed out of band by the server that masking will be used for the server->client channel too, OR a frame must be self-describing with the masking details (extensions, reserved bits). The current push for masking to be placed into the extension data would do this. Regards, Brodie > More complex schemes could be added >> later, however simply trying for a direct connection and falling back >> to a central relay is possible with the existing protocol. >> >> However this problem is solved though, we will still have a client is >> acting as a server and (I am assuming) that client will still want to >> send masked data too. In the case of direct connection, where no >> central server can modify the data stream, the client on the other end >> must unmask the data coming from the server. So the most basic support >> for p2p with the current protocol maintaining security guarantees >> would only require a client to be able to accept either masked or >> unmasked responses from the server. >> >> The security paranoid could then also optionally configure a server to >> send masked responses (if supported). >> >> Regards, >> Brodie >> >> >> On Mon, Jan 10, 2011 at 11:39 AM, Eric Rescorla wrote: >>> Not really. Meaningful p2p operation requires nat traversal >>> >>> Ekr >>> >>> On Jan 9, 2011, at 17:02, Brodie Thiesfield wrote: >>> >>>> I understand that this can be addressed later, however supporting peer >>>> to peer in the protocol appears to only require a client to also >>>> support the optional masking of the server responses. >>>> >>>> In the case of a browser acting as the server, it will need to >>>> implement the server side of things like handshake and unmasking >>>> client messages. However, given that it is really also a client (with >>>> the same unknown intermediataries, etc), I assume that it would be >>>> desirable to have the same security protections as a simple client, >>>> and so it would also want to send messages using masking. >>>> >>>> As long as simple clients can also receive messages from a server with >>>> masking enabled, then there appears to be no reason that peer to peer >>>> wouldn't work with the same security guarantees (for the protocol) >>>> that client->server does. >>>> >>>> i.e. >>>> client -> server = masked >>>> server -> client = cleartext | masked >>>> >>>> How the server notifies the client that it is going to send masked >>>> responses remains unspecified. >>>> >>>> Regards, >>>> Brodie >>>> >>>> >>>> On Fri, Jan 7, 2011 at 7:34 PM, Salvatore Loreto >>>> wrote: >>>>> On 1/7/11 2:23 AM, John Tamplin wrote: >>>>> >>>>> On Thu, Jan 6, 2011 at 7:37 PM, Bruce Atherton wrote: >>>>>> >>>>>> So far it appears that Greg, Brodie, Jerod, and I favour including >>>>>> peer-to-peer design considerations in the spec. I am not sure, but it sounds >>>>>> like John considers it out of scope and Scott considers it in scope. What >>>>>> about the rest of you? >>>>> >>>>> I am not opposed to it exactly, but given how long everything has taken I am >>>>> keen to keep the base protocol minimal so we can actually get something out >>>>> the door. >>>>> >>>>> I agree with John, >>>>> lets keep the base protocol minimal at moment. >>>>> Once we have reached consensus on the minimal base protocol we can >>>>> start to add other stuff on top of the minimal base. >>>>> >>>>> If there is consensus in doing something in the future we can track it in >>>>> the issue tracker >>>>> so we won't forget. >>>>> >>>>> >>>>> cheers >>>>> /Sal >>>>> >>>>> -- >>>>> Salvatore Loreto >>>>> www.sloreto.com >>>>> >>>>> _______________________________________________ >>>>> hybi mailing list >>>>> hybi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/hybi >>>>> >>>>> >>>> _______________________________________________ >>>> hybi mailing list >>>> hybi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hybi >>> >> > From duerst@it.aoyama.ac.jp Mon Jan 10 16:55:56 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B4E3A682E for ; Mon, 10 Jan 2011 16:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.357 X-Spam-Level: X-Spam-Status: No, score=-100.357 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHqdf7L5393U for ; Mon, 10 Jan 2011 16:55:55 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id DF0463A67D6 for ; Mon, 10 Jan 2011 16:55:54 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p0B0w8Od019676 for ; Tue, 11 Jan 2011 09:58:08 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 740f_50de_db2a0da8_1d1d_11e0_8d8b_001d096c5782; Tue, 11 Jan 2011 09:58:08 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36160) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 11 Jan 2011 09:58:08 +0900 Message-ID: <4D2BAB1F.2030307@it.aoyama.ac.jp> Date: Tue, 11 Jan 2011 09:58:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Roberto Peon References: <2948.1294683316.925357@puncture> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] Do we need to change the framing again? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:55:56 -0000 On 2011/01/11 6:26, Roberto Peon wrote: > I don't believe that the length bits are an interesting attack vector as the > browser would need something that size before it could encode that length. > Or are we assuming that the browser will send the header before it has all > of the data for the message? That'd be bizzare. That's not only bizzare, it would also be a security risk, in that the server and the client could exchange data about the masking key(stream) in a side channel, allowing the client to create data that it knows what it will look after masking. This is a security concern that we have to warn against in the security section. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From jat@google.com Mon Jan 10 18:10:04 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B806C3A691E for ; Mon, 10 Jan 2011 18:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.825 X-Spam-Level: X-Spam-Status: No, score=-103.825 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ASVoQw7wTGe for ; Mon, 10 Jan 2011 18:10:04 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C9CAC3A691C for ; Mon, 10 Jan 2011 18:10:03 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p0B2CIIl022517 for ; Mon, 10 Jan 2011 18:12:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294711938; bh=QfXRtou6o3KCgjSQoKst0GphzY4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=U5Yt/sruFYXy/Fw8Mb7yRqwntbSfDmStN/6Raa4y8VcGiTFUi1ObSDq4H6GucxcND Z69QKzgrKLf1pmRBfMudw== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by wpaz1.hot.corp.google.com with ESMTP id p0B2CGx7016680 for ; Mon, 10 Jan 2011 18:12:17 -0800 Received: by gwj20 with SMTP id 20so8273608gwj.33 for ; Mon, 10 Jan 2011 18:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=yTrd9VfNRch9KtypTAejhJXHbluiliAr51tRQ2OV6mU=; b=rVS8IDG/FFOwte1d9h4qwngbcUO6132mvoMSUtB2mT1V3OOCKxo0qSPCTaEG6lMG9a z9CDI3a/Nqa7fOUa8e+w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Hk80LySVOwityzr15uOC5kGw6NW9DH5myZEu4NEJof8CDbuRFlon5SSzecpqyCaHPz r/Kb0rGqd53qfbqAvNtg== Received: by 10.151.85.10 with SMTP id n10mr28716130ybl.206.1294711936789; Mon, 10 Jan 2011 18:12:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.212.8 with HTTP; Mon, 10 Jan 2011 18:11:56 -0800 (PST) In-Reply-To: References: <4D26605B.1090409@callenish.com> <4D26DE2D.5040901@ericsson.com> From: John Tamplin Date: Mon, 10 Jan 2011 21:11:56 -0500 Message-ID: To: Brodie Thiesfield Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Can Websockets be used peer to peer? Was Straw Poll: is Upgrade...? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 02:10:04 -0000 On Mon, Jan 10, 2011 at 7:12 PM, Brodie Thiesfield wrote: > The essential points are: > * basic direct + central hub p2p is almost possible with the current protocol > * since both client and server are browsers, both client and server > will be wanting to send masked data > * therefore the client needs to be able to receive and decode masked frames > > All that is required to enable simple p2p then is for the masking to > be designed such that the recipient can detect that it is being used > and unmask the data. > > To do this, either the client must be informed out of band by the > server that masking will be used for the server->client channel too, > OR a frame must be self-describing with the masking details > (extensions, reserved bits). The current push for masking to be placed > into the extension data would do this. It seems to me to be totally separate as to how the masking is actually applied -- you could easily define an extension "servermask" which specifies that server->client frames will be masked (probably the same mechanism as client->server, but it doesn't have to be), and then if that extension is negotiated then you proceed with masking in both directions. -- John A. Tamplin Software Engineer (GWT), Google From Internet-Drafts@ietf.org Tue Jan 11 10:45:03 2011 Return-Path: X-Original-To: hybi@core3.amsl.com Delivered-To: hybi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004A528C2F1; Tue, 11 Jan 2011 10:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1EH45qt2ovR; Tue, 11 Jan 2011 10:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B38B3A6A7E; Tue, 11 Jan 2011 10:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111184502.30771.57773.idtracker@localhost> Date: Tue, 11 Jan 2011 10:45:02 -0800 Cc: hybi@ietf.org Subject: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-04.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 18:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF. Title : The WebSocket protocol Author(s) : I. Fette Filename : draft-ietf-hybi-thewebsocketprotocol-04.txt Pages : 49 Date : 2011-01-11 The WebSocket protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an initial handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or