Re: [hybi] Shipping WebSockets

Maciej Stachowiak <mjs@apple.com> Thu, 16 December 2010 01:19 UTC

Return-Path: <mjs@apple.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56783A7080 for <hybi@core3.amsl.com>; Wed, 15 Dec 2010 17:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.276
X-Spam-Level:
X-Spam-Status: No, score=-107.276 tagged_above=-999 required=5 tests=[AWL=-0.677, 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 cmmYcPZ90-73 for <hybi@core3.amsl.com>; Wed, 15 Dec 2010 17:19:14 -0800 (PST)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 030A43A6FCE for <hybi@ietf.org>; Wed, 15 Dec 2010 17:19:13 -0800 (PST)
Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id B08D5BFE6931 for <hybi@ietf.org>; Wed, 15 Dec 2010 17:20:57 -0800 (PST)
X-AuditID: 11807134-b7c51ae000005439-df-4d0969792b8a
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id B4.56.21561.979690D4; Wed, 15 Dec 2010 17:20:57 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.72.147.28] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LDH00HOSYESH660@elliott.apple.com> for hybi@ietf.org; Wed, 15 Dec 2010 17:20:57 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <07788BB1-182D-4260-A73B-8082D7463BF9@mnot.net>
Date: Wed, 15 Dec 2010 17:20:52 -0800
Message-id: <011E0760-A64B-4C26-B2CF-6F5CDCA0EC25@apple.com>
References: <B0B3789C-1D3C-4A4E-B37F-8F43FFC7D905@mnot.net> <AANLkTi=Z8Hcp7FBDumgMPH4YmQ1=yqOPwAxD095yzLBt@mail.gmail.com> <AANLkTik6etgMy7jDhWtg+xqhoMzsJy-4U-xveue2gD32@mail.gmail.com> <AANLkTimw5bHL+GwkMhPC5DwLUJZzeSvfURQQy-XSJxpi@mail.gmail.com> <F16F4A8A-CFBD-44C1-B4A2-EC209E793AF7@mimectl> <07788BB1-182D-4260-A73B-8082D7463BF9@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
Cc: "hybi@ietf.org HTTP" <hybi@ietf.org>
Subject: Re: [hybi] Shipping WebSockets
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Dec 2010 01:19:16 -0000

On Dec 15, 2010, at 4:59 PM, Mark Nottingham wrote:

> From an HTTP standpoint, this looks good to me, and it nicely demonstrates a point I've been trying to make repeatedly -- that we don't have to fall into the trap of a false choice between the 'old' upgrade proposal and the CONNECT proposal.
> 
> I'm very interested to hear the reactions of the CONNECT proponents.

- I don't think this proposal does anything to address the flaws found by Adam's study.

- In fact I don't think anything about this proposal meaningfully improves security relative to the current draft. Some of the changes may have good non-security motivations I see it as a waste of time to putter around the edges of the handshake until we have security figured out. Security issues currently make the protocol non-viable. I don't see the value in producing more drafts that are not safe to ship in product.

- The summary claims that this handshake doesn't introduce a round trip, but it clearly does, since the hello frames are only exchanged after the handshake completes.

(That's setting aside the obvious point that this internet-draft is not suitable for use as drop-in spec text, both due to being written as an old vs. new comparison and due to insufficient detail.)

For these reasons, I think the proposed draft is not a particularly useful direction.

Regards,
Maciej


> 
> Regards,
> 
> 
> On 16/12/2010, at 5:30 AM, Gabriel Montenegro wrote:
> 
>> FYI, we have submitted a draft that's essentially the handshake that Greg proposed a while back.
>> We'd like to use it as a basis for further iteration.
>> 
>> http://tools.ietf.org/html/draft-montenegro-hybi-upgrade-hello-handshake
>> 
>> Agree on base64.
>> 
>> Gabriel
>> From: hybi-bounces@ietf.org [hybi-bounces@ietf.org] on behalf of Greg Wilkins [gregw@webtide.com]
>> Sent: Wednesday, December 15, 2010 09:03
>> To: John Tamplin
>> Cc: hybi@ietf.org HTTP
>> Subject: Re: [hybi] Shipping WebSockets
>> 
>> On 15 December 2010 17:44, John Tamplin <jat@google.com> wrote:
>>> On Wed, Dec 15, 2010 at 3:39 AM, Greg Wilkins <gregw@webtide.com> wrote:
>>>> Does anybody object to wrapping the nonce/hash bytes sent after the
>>>> handshake requests as HELLO frames?  This means that implementations
>>>> only need to deal with 2 framing mechanisms not 3.
>>> 
>>> In the absence of information about the rest of the handshake, yes.
>>> All else being equal, I would prefer they be included in headers.
>> 
>> Well I would not argue with them being headers either.
>> 
>> 
>>> I don't understand what you mean about 2 framing mechanisms instead of 3 though.
>> 
>> The connection opens, you first have to parse HTTP.  You then have to
>> parse 8 bytes.  You then parse websocket packets.
>> 
>> Sure that is trivial if you are writing a blocking implementation.
>> But if you want to scale, you have to be asynchronous and you can't
>> assume that all the 8 bytes will arrive at once.  So you have to have
>> a little state machine to track the arrival of those bytes.  This is
>> just needless complication and will be a source of errors.    If the
>> bytes are framed as WS, then you can simply switch from the HTTP
>> parser to the WS parser
>> 
>> Also, without any framing, then any 8 bytes sent (eg another HTTP
>> request) will look like the random bytes.  This is not robust
>> 
>> 
>> 
>> 
>>>> Does anybody object to simple hex encoding of nonces and hashes?
>>> 
>>> I wouldn't block it, but base64 seems better and sufficient.
>> 
>> sure b64 is good also.
>> 
>> 
>> cheers
>> _______________________________________________
>> 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
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi