Re: [websec] Fwd: I-D Action: draft-nir-websec-extended-origin-00.txt

Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 03 March 2012 16:07 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B30B21F86C7 for <websec@ietfa.amsl.com>; Sat, 3 Mar 2012 08:07:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.778
X-Spam-Level:
X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKF4M+VBsczP for <websec@ietfa.amsl.com>; Sat, 3 Mar 2012 08:07:56 -0800 (PST)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id ADA4721F86C2 for <websec@ietf.org>; Sat, 3 Mar 2012 08:07:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=MCHIWih1SdG5aGOVmeGWRYlj3wX69Kqu3b1KvS6dOM38Sm6HuvhzHgs3cwcWAHCGp4EUb6xQu2m4zsGs/fOlCSV7yV0X13jXkOqH4BirW/YAWpTQ9oaLANVhzdHP1gP8; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Received: (qmail 21789 invoked from network); 3 Mar 2012 17:07:31 +0100
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.68?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Mar 2012 17:07:31 +0100
Message-ID: <4F5241C3.6070401@gondrom.org>
Date: Sat, 03 Mar 2012 16:07:31 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: websec@ietf.org
References: <20120202220021.31936.37346.idtracker@ietfa.amsl.com> <C35E9FBD-8AF7-4F63-B798-1316B985E032@checkpoint.com>
In-Reply-To: <C35E9FBD-8AF7-4F63-B798-1316B985E032@checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [websec] Fwd: I-D Action: draft-nir-websec-extended-origin-00.txt
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Mar 2012 16:07:57 -0000

Hello Yoav,

thank you for the interesting draft.

<hat="individual">

I have a few points as feedback:
- the 3-tupel of origin consists of "real" parameters (protocol, URL, 
port), while the introduction of the 4th tupel feels like an artificial 
parameter extension as it is not mapped to anything visible to the 
client and in fact will be spliced by the middle-server (vpn server). 
This makes me very hesitant, whether this would be a good idea.

- As Adam mentioned that there will be migration problems.
At the moment all browsers and other systems operate on the SOP with 
3-tupel to compare for identity. It will be difficult (read: near 
impossible) to enforce that all deployed systems out there shall from 
now on be compliant with a 4-tupel and no longer assume identity of two 
sites when only the first three parameters are equal.

So, although I agree that economic reasons are absolutely viable reasons 
for such an idea, I have concerns that this draft is only a workaround 
for certain closed areas (i.e. where a company can basically enforce 
that all accessing clients are in fact updated using such a 4-tupel 
policy) but will create severe consistency issues in the Internet where 
you would then see a mix of 3-tupel and 4-tupel clients, with the risk 
of messing up the predictability of handling of SOP.

Maybe a question regarding the use cases:
As in general, systems use sub-domains for such purpose (as explained by 
you and James), I am wondering whether there are other scenarios (beyond 
VPN) that may need this 4th origin parameter?

Best regards, Tobias


On 02/02/12 22:54, Yoav Nir wrote:
> Hi
>
> I have just submitted this draft. The purpose of this is to address 
> the case where a single portal hides several real servers behind it, 
> by translating their URLs into URL that seem to be from that server.
>
> In that case the same origin policy is not enforced correctly, because 
> cookies and scripts from one server behind the portal (for example, a 
> mail server) can be shared and can affect pages form another server 
> behind the same portal.
>
> This draft proposes a header that will tell the client (browser) what 
> the real origin is, and allow the client to apply the SOP.
>
> If people find this interesting, I would like to discuss this in 
> Paris. Any comments will be greatly appreciated.
>
> Yoav
>
> Begin forwarded message:
>
>> *From: *"internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>" 
>> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
>> *Subject: **I-D Action: draft-nir-websec-extended-origin-00.txt*
>> *Date: *February 3, 2012 12:00:21 AM GMT+02:00
>> *To: *"i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>" 
>> <i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>>
>> *Reply-To: *"internet-drafts@ietf.org 
>> <mailto:internet-drafts@ietf.org>" <internet-drafts@ietf.org 
>> <mailto:internet-drafts@ietf.org>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>> Title           : A More Granular Web Origin Concept
>> Author(s)       : Yoav Nir
>> Filename        : draft-nir-websec-extended-origin-00.txt
>> Pages           : 8
>> Date            : 2012-02-02
>>
>>   This document defines an HTTP header that allows to partition a
>>   single origin as defined in RFC 6454 into multiple origins, so that
>>   the same origin policy applies among them.
>>
>>   The header introduced in this document allows the portal to specify
>>   that resources that appear to be from the same origin should, in
>>   fact, be treated as though they are from different origins, by
>>   extending the 3-tuple of the origin to a 4-tuple.  The user agent is
>>   expected to apply the same-origin policy according to the 4-tuple
>>   rather than the 3-tuple.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nir-websec-extended-origin-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-nir-websec-extended-origin-00.txt
>
>
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec