Re: [hybi] New port and Tunneling?

"Shelby Moore" <shelby@coolpage.com> Tue, 17 August 2010 11:59 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 66C8A3A693A for <hybi@core3.amsl.com>; Tue, 17 Aug 2010 04:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.808
X-Spam-Level:
X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.791, 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 yK0TnXHf-ZIO for <hybi@core3.amsl.com>; Tue, 17 Aug 2010 04:59: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 5D0B23A67F4 for <hybi@ietf.org>; Tue, 17 Aug 2010 04:59:15 -0700 (PDT)
Received: (qmail 36296 invoked by uid 65534); 17 Aug 2010 11:59: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; Tue, 17 Aug 2010 07:59:50 -0400
Message-ID: <b5f838a87561f318ae6c3958a058b057.squirrel@sm.webmail.pair.com>
In-Reply-To: <9e3c9de9b6d6278aa26921f4b22963ad.squirrel@sm.webmail.pair.com>
References: <9e3c9de9b6d6278aa26921f4b22963ad.squirrel@sm.webmail.pair.com>
Date: Tue, 17 Aug 2010 07:59:50 -0400
From: Shelby Moore <shelby@coolpage.com>
To: Vladimir Katardjiev <vladimir@d2dx.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 <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: Tue, 17 Aug 2010 11:59:16 -0000

> SOP = same origin policy
>
> I will phrase this generally for all potential protocols, not just HTTP.
>
> Status quo should remain, where "cookies" (i.e. any client-side persistent
> user data) are (at least by default) inaccessible if they were not created
> by *.domain of the current page (i.e. window.location.*).
>
> There are only two categories of SOP attacks (all attacks fall under these
> two):
>
> 1. Cross-domain requests where "cookies" for the domain, receiving the
> request, are automatically included in the request.
>
> 2. Cross-domain requests that load malicious resources (e.g. usually
> scripts) from foreign domain into current domain.


Clarify that to be "There are only two categories of SOP applicable
cross-domain attacks for accessing network resources (all such attacks
fall under the above two)".

Of course SOP still has to always apply to script access to the
client-side resources (e.g. to cookies, frames, etc). Someone could argue
for more user trust granularity for client-side-resources SOP, but I would
retort that it would be unreasonably complex for users to manage N-tuples
of domains that are trusted with respect to each other.

The reason #2 does not involve N-tuples complexity is because the domain
of the current page is entirely in control of when it initiates access to
network resources.  Whereas for client-side resources, the domain is not
in control of when its resources are accessed-- the browser is the
gatekeeper.