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-dra...@ietf.org <mailto:internet-dra...@ietf.org>"
<internet-dra...@ietf.org <mailto:internet-dra...@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-annou...@ietf.org <mailto:i-d-annou...@ietf.org>"
<i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>>
*Reply-To: *"internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>" <internet-dra...@ietf.org
<mailto:internet-dra...@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
_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
