Re: [hybi] New port and Tunneling?

"Shelby Moore" <shelby@coolpage.com> Wed, 18 August 2010 08:13 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 EAFA13A6A53 for <hybi@core3.amsl.com>; Wed, 18 Aug 2010 01:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.587
X-Spam-Level:
X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_50=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 6F09j3YB7sC3 for <hybi@core3.amsl.com>; Wed, 18 Aug 2010 01:13:37 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com [66.39.3.83]) by core3.amsl.com (Postfix) with SMTP id 94C9A3A6A2E for <hybi@ietf.org>; Wed, 18 Aug 2010 01:13:35 -0700 (PDT)
Received: (qmail 15479 invoked by uid 65534); 18 Aug 2010 08:14:09 -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 04:14:09 -0400
Message-ID: <19abc4caa904ecc7371926db9a711cdb.squirrel@sm.webmail.pair.com>
In-Reply-To: <340466c936045003a3930a65610df597.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>
Date: Wed, 18 Aug 2010 04:14:09 -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 08:13:49 -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.


2) Robust Defenses for Cross-Site Request Forgery
Adam Barth, Collin Jackson, and John C. Mitchell
In Proc. of the 15th ACM Conf. on Computer and Communications Security
(CCS 2008)
http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

Sorry to say you committed the exact mistake in this paper as I predicted
you would make in my prior rebuttal post. NEVER is relying on the client a
security solution (e.g. Referrer for HTTPS, or Origin for HTTP). That is
the antithesis of security. The 100% solution to that CSRF login problem
is as I have implemented at AsiaDear.com . The server never uses any
persistent client data for login, except when index.php is requested, it
reads the cookie. But since index.php never accepts any GET or POST
inputs, then no server side-effects can occur when index.php is requested
and the cookie is injected from the client. Think about that deeply and
you will get the "a ha". The /rest/* APIs are always requested with the
session id GET/POST input to prove the user is signed in (non-geeks prefer
term "sign in" than "log in"), so there is no way to get that that session
id unless you can hack the browser (or inject into the index.php page
script with other category of vulnerability) because it is stored in the
script for index.php on the client. If the user is signed in with
"remember me" checked, and then you request one of /rest/* apis (try
user.php and photo.php), you will receive back "you were signed out". But
then if you do something at index.php, you see you are still signed in.
Exactly how it should work! Your suggested use of an Origin HTTP header is
wrong. Never should the server be programmed to rely on extra actors for
its state-machine. The entire Origin WG draft is wrongheaded (I can go
into that in great detail with you if you want).



3) Towards a Formal Foundation of Web Security
Devdatta Akhawe, Adam Barth, Peifung E. Lam, John C. Mitchell, and Dawn Song
In Proc. of the 23th IEEE Computer Security Foundations Symposium (CSF 2010)
http://www.adambarth.com/papers/2010/akhawe-barth-lam-mitchell-song.pdf

The problem with models is that if they conflate vulnerabilities, they do
not give correct insight. You've got so many fundamental flaws, that you
can't even begin to declare a model. It wasn't worth entirely wrapping my
mind around this paper, because for one you start by definining the
fundamental components in a way that conflates vulnerabilities. Sorry.



[1] http://esr.ibiblio.org/?p=1327 , Killing the Founder - Eric Raymond blog