Re: [hybi] Extensibility mechanisms?

Scott Ferguson <ferg@caucho.com> Thu, 22 July 2010 21:11 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 BB11B3A63EC for <hybi@core3.amsl.com>; Thu, 22 Jul 2010 14:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 z36Ocg+dqgk4 for <hybi@core3.amsl.com>; Thu, 22 Jul 2010 14:11:08 -0700 (PDT)
Received: from smtp111.biz.mail.mud.yahoo.com (smtp111.biz.mail.mud.yahoo.com [209.191.68.76]) by core3.amsl.com (Postfix) with SMTP id 481C33A69BE for <hybi@ietf.org>; Thu, 22 Jul 2010 14:11:05 -0700 (PDT)
Received: (qmail 88549 invoked from network); 22 Jul 2010 21:11:14 -0000
Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 22 Jul 2010 14:11:14 -0700 PDT
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
X-YMail-OSG: XCqfW.wVM1k65s8jyb7OQF.qJiRg6dN6ex8owasGn2sHNzN _Vgs7c9pr3HdMwnqj7GdAVHQTygMBg4oxMUM2UhRVuk0ZCu1XfEr8E9eairo cJiZeCLqFyu_610oWixr6a4XIW5pFNdCQEOLnmiCY0M5xUR_yMFOPe6ww12K Moo46WJNxAiN2WHY.spMHSjdkJlve0ekMVZEHlHc88KNlAce2c3518bef05L L_QcKQ0gV_TNzgzWy9oXRFms9_4Q7JfyonHi5qcuZ.9Jt7DeV9t0JXdmtQNa bbPdtLUbnzKTVR8yxV8QN4eWYorKkf.vdfp.xAYuclHykrW59uxJYgA--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4C48B3EC.8040908@caucho.com>
Date: Thu, 22 Jul 2010 14:11:08 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <h2w5c902b9e1004152345j992b815bz5f8d38f06a19181a@mail.gmail.com> <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> <4C47C5B0.3030006@caucho.com> <AANLkTi=ND-FOH8OoD=TCbiyeSZ-h0LhxQBXN5w-2hfvj@mail.gmail.com> <4C48A468.3040009@caucho.com> <AANLkTikeLr325F03bowJu7NeHEqY_+OzEnQcrxHbCwhW@mail.gmail.com> <4C48AF24.2040501@caucho.com> <AANLkTinodV_uPvJLxSG_uyg9pjeCjC=iDOxP0SinGxtN@mail.gmail.com>
In-Reply-To: <AANLkTinodV_uPvJLxSG_uyg9pjeCjC=iDOxP0SinGxtN@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 21:11:13 -0000

Adam Barth wrote:
> On Thu, Jul 22, 2010 at 1:50 PM, Scott Ferguson <ferg@caucho.com> wrote:
>   
>> Adam Barth wrote:
>>     
>>> We need to know the server understands web sockets before spamming
>>> them with attacker-controlled bytes.  If we don't, we'll repeat the
>>> long and tragic history of cross-protocol vulnerabilities caused by
>>> HTTP POST.
>>>
>>> This is a hard requirement.
>>>       
>> Then I think it should be added to the requirements document, because that's
>> a fundamental design decision.
>>     
>
>    REQ. 19:  WebSocket should be designed to be robust against cross-
>       protocol attacks.  The protocol design should consider and
>       mitigate the risk presented by WebSocket clients to existing
>       servers (including HTTP servers).  It should also consider and
>       mitigate the risk to WebSocket servers presented by clients for
>       other protocols (including HTTP).
>   
Yes, but that's not specific enough for your requirement because 
"consider and mitigate" doesn't necessarily imply "client must validate 
server before sending content."

As long as everyone's clear and agrees on the "client must validate 
server before sending content" requirement, then we're fine.

-- Scott
> Adam
>
>
>
>