Re: [hybi] Extensibility mechanisms?

Scott Ferguson <ferg@caucho.com> Thu, 22 July 2010 04:14 UTC

Return-Path: <ferg@caucho.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 AA5D23A6947 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 21:14:58 -0700 (PDT)
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.001, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 v1k7QYAYaTSL for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 21:14:50 -0700 (PDT)
Received: from smtp113.biz.mail.mud.yahoo.com (smtp113.biz.mail.mud.yahoo.com [209.191.68.78]) by core3.amsl.com (Postfix) with SMTP id 1233A3A693F for <hybi@ietf.org>; Wed, 21 Jul 2010 21:14:42 -0700 (PDT)
Received: (qmail 16170 invoked from network); 22 Jul 2010 04:14:48 -0000
Received: from scott-fergusons-macbook-pro-3.local (ferg@71.141.247.84 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 21 Jul 2010 21:14:47 -0700 PDT
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
X-YMail-OSG: 3XmrLfMVM1nEpZpAFVQycg0XMssPwu7j91ruJM.upLilShf 3pkc6W0XdBrSBpi0fdI.U9GD4vDQS6fzF_k6ssHYc0IoeKBd2v4J6QbFYsfJ Y4aIYvsJHtCGxyTUanN.hFlspOKxNrxyXY2i7Urul4Ud4pSPTUaC6bm2C6fX CgEgud8IqhfLMcyRJ6silHAvisc3sN1SkgmHJD73jWkzc4gefFpGHQfC7hIO E4SdXTmEz8sQd5gRfmCyTAZMmeGr5SRbDMs1CC6sdCDl6rFne.mthr4Yaocb GyvkZ3.Z9iPtvRLqZnyBF
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4C47C5B0.3030006@caucho.com>
Date: Wed, 21 Jul 2010 21:14:40 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <h2w5c902b9e1004152345j992b815bz5f8d38f06a19181a@mail.gmail.com> <4BCAB2C1.2000404@webtide.com> <B9DC25B0-CD21-44E7-BD9B-06D0C9440933@apple.com> <4BCB7829.9010204@caucho.com> <Pine.LNX.4.64.1004182349240.751@ps20323.dreamhostps.com> <4BCC0A07.9030003@gmx.de> <Pine.LNX.4.64.1004190753510.23507@ps20323.dreamhostps.com> <4BCC111C.90707@gmx.de> <Pine.LNX.4.64.1004190837570.23507@ps20323.dreamhostps.com> <4BCC204D.30004@gmx.de> <z2gad99d8ce1004190822ne4dd36b6v54d63efcc448e840@mail.gmail.com> <Pine.LNX.4.64.1007202204270.7242@ps20323.dreamhostps.com> <AANLkTikkfdlUxQ0MGNvVQKa5gfovkGHWdCgyN9juKSQJ@mail.gmail.com> <4C462F9E.9030207@caucho.com> <Pine.LNX.4.64.1007212153110.7242@ps20323.dreamhostps.com> <AANLkTiku76oSucTNDFdwgsFBNFa_cCpC-YktTnMfX47-@mail.gmail.com> <4C479130.4020500@caucho.com> <AANLkTikLDjBP-Xs5t6TxmJuq4nG8jwThQ=n34B4cEmup@mail.gmail.com> <4C479CE4.6070805@caucho.com> <AANLkTims1er0Rbv0ysP4gRs1Kd0He8hapHeJ3nON=JQa@mail.gmail.com>
In-Reply-To: <AANLkTims1er0Rbv0ysP4gRs1Kd0He8hapHeJ3nON=JQa@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Extensibility mechanisms?
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, 22 Jul 2010 04:14:59 -0000

Adam Barth wrote:
> I don't think you understand how cross-protocol attacks work, and I'm
> not that interested in educating you about them.  HTTP POST requests
> are also very poorly designed in this way and have been the cause of a
> number of cross-protocol attacks, most recently against IRC.
>   
Well, we have two conflicting desires that need to be resolved:

  1) To make WebSockets initial latency no worse than HTTP. (If I 
understand correctly, this is the issue raised by Jamie and also Greg.)

  2) cross-site scripting

I see only 3 possible resolutions:

  a) That 1 & 2 are irreconcilable and WebSocket performance must be 
worse than HTTP/comet because its security must be better than HTTP.

  b) WebSocket performance must be as good as HTTP/comet as long as its 
security is no worse than HTTP.

  c)  Both 1 & 2 are resolvable and the solution is XXX.

If (a) or (b) are selected, it should be a conscious decision, not 
chosen by default. I assume you're in camp (a)?

If you believe (c), than it seems to me you either need to propose an 
XXX or suggest fixes to a flawed XXX proposal to make it work.

The current official draft proposes (a), but it seemed to me that the 
group is divided on the issue, and I made an attempt at an XXX. Perhaps 
I misunderstood, everyone's in camp (a).

-- Scott

(I suppose there might be a (d): browser clients are restricted to (a) 
but non-browser clients can use (b). But that would probably be too 
messy for a spec.)
> Adam
>
>
>
>