Re: [hybi] New port and Tunneling?

"Shelby Moore" <shelby@coolpage.com> Wed, 18 August 2010 09:01 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 D2A213A681A for <hybi@core3.amsl.com>; Wed, 18 Aug 2010 02:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.695, 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 1UIN9xpTI9jG for <hybi@core3.amsl.com>; Wed, 18 Aug 2010 02:01:15 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com [66.39.3.83]) by core3.amsl.com (Postfix) with SMTP id 503383A6872 for <hybi@ietf.org>; Wed, 18 Aug 2010 02:01:15 -0700 (PDT)
Received: (qmail 18853 invoked by uid 65534); 18 Aug 2010 09:01:50 -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:01:50 -0400
Message-ID: <bf5e9182df28773664681624b1cd20e0.squirrel@sm.webmail.pair.com>
In-Reply-To: <19abc4caa904ecc7371926db9a711cdb.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>
Date: Wed, 18 Aug 2010 05:01:50 -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:01:17 -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?