Re: [hybi] New port and Tunneling?

"Shelby Moore" <shelby@coolpage.com> Wed, 18 August 2010 09:18 UTC

Return-Path: <shelby@coolpage.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 0D2473A6872 for <hybi@core3.amsl.com>; Wed, 18 Aug 2010 02:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.936
X-Spam-Level:
X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.663, 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 HyV7kY6p3NCo for <hybi@core3.amsl.com>; Wed, 18 Aug 2010 02:18:19 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com [66.39.3.83]) by core3.amsl.com (Postfix) with SMTP id D01E33A690A for <hybi@ietf.org>; Wed, 18 Aug 2010 02:18:18 -0700 (PDT)
Received: (qmail 20167 invoked by uid 65534); 18 Aug 2010 09:18:54 -0000
Received: from 121.97.54.174 ([121.97.54.174]) (SquirrelMail authenticated user shelby@coolpage.com) by sm.webmail.pair.com with HTTP; Wed, 18 Aug 2010 05:18:54 -0400
Message-ID: <3e50c95e3ae1941b02c7ff4e78af3313.squirrel@sm.webmail.pair.com>
In-Reply-To: <bf5e9182df28773664681624b1cd20e0.squirrel@sm.webmail.pair.com>
References: <9e3c9de9b6d6278aa26921f4b22963ad.squirrel@sm.webmail.pair.com> <b5f838a87561f318ae6c3958a058b057.squirrel@sm.webmail.pair.com> <657f148a719e31c1699dccfe3e6e63c4.squirrel@sm.webmail.pair.com> <AANLkTimV77PKU3pTAgfBMu5XvzKX7ovHdE6xBCh9o-dx@mail.gmail.com> <340466c936045003a3930a65610df597.squirrel@sm.webmail.pair.com> <19abc4caa904ecc7371926db9a711cdb.squirrel@sm.webmail.pair.com> <bf5e9182df28773664681624b1cd20e0.squirrel@sm.webmail.pair.com>
Date: Wed, 18 Aug 2010 05:18:54 -0400
From: Shelby Moore <shelby@coolpage.com>
To: shelby@coolpage.com
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: hybi@ietf.org
Subject: Re: [hybi] New port and Tunneling?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shelby@coolpage.com
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: Wed, 18 Aug 2010 09:18:20 -0000

>>> After sending this email, I am going to take some time to read some of
>>> your publications, so I can understand better your expertise.
>>
>> Thank you for providing public copies of your research papers.
>>
>> Now I am going to teach you (arrogant? maybe, but not desired, just the
>> way it is[1]).
>>
>> I just read the following (in this order):
>>
>> 1) Beware of Finer-Grained Origins
>> Collin Jackson and Adam Barth
>> In Proc. of Web 2.0 Security and Privacy 2008 (W2SP 2008)
>> http://www.adambarth.com/papers/2008/jackson-barth-b.pdf
>>
>> I agree with you. Sub-origin is brittle. Proliferating granularity that
>> does not match the user's capability to manage trust, is self-defeating
>> because of Coase's Theorem (nature routes around any artificial
>> barrier/cost). The user will always try to maximize his desired trust.
>> Thus trust granularity must correlate with the user's trust, not with
>> any
>> other centralized trust paradigm. This is precisely why I pointed out
>> that
>> SOP != trust in my prior posts of this thread. You got the problem
>> correct, but (at least in that paper) you didn't quite grok that Coase's
>> Theorem is the generalization and thus what the general solution must
>> be.
>> Also we must understand the human limitations to manage complexity and
>> that is why my proposed improvement to whitelisting SOP was designed to
>> minimize the complexity and maximize the type of trust granularity that
>> is
>> meaningful to the user.
>
>
> I think it is already well understood that any choices the user is given
> about security are useless if the user can not correlate them to something
> meaning.
>
> My proposal to whitelist SOP does not good if that opens some
> vulnerability that causes the problem to appear at another origin than the
> one the user whitelisted.
>
> I think my categorization of the request vulnerabilities into 2 major
> categories, shows that the user will always associate the blame with the
> origin that was whitelisted, so those 2 very specific vulnerability
> categories.
>
> The next question is how useful is it?

Argh, I am angry at myself for so many typos.  I need to take break.

The should be "meaningful" and "for those 2 very specific".

And I meant "My proposal to whitelist SOP with respect to network requests
only".  I am not proposing to whitelist SOP for client resource access,
etc...