Subject: [websec] Reviews of draft-ietf-websec-origin and principles-of-origin - until end of May

From: Tobias Gondrom <[email-masked]>
Date: Fri, 13 May 2011 06:44:47 +0100

Hello dear websec fellows,

to follow up on one of the tasks from our meeting in Prague is the draft

http://tools.ietf.org/html/draft-ietf-websec-origin-00
and http://www.ietf.org/id/draft-abarth-principles-of-origin-00.txt

At the meeting 8 people (am not gonna name them here) indicated that
they still want to submit their review and feedback on this draft until
May.

I would like to ask you and every interested party to please do that, so
that Adam can incorporate your comments for a timely progress and next
version.

During the meeting there was also the suggestion to merge both documents
(origin and principles-of-origin) with no objections raised. If you want
to raise objections against that merge please do so now, so that Adam
can proceed with the next revision of the document.

As the document has been reviewed thoroughly in its version before it
was adopted as a WG document and seems quite stable and mature, I
perceive it likely, it could go into WGLC soon.
So definitely now is a good time to review it and get your comments in.

All the best,

Tobias
(websec chair)

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 May 2011 10:47:33 +0200

On 13.05.2011 07:44, Tobias Gondrom wrote:
> ...
> ...

I believe that having two documents make sense; what's the benefit of 
merging?

That being said, a few comments on draft-abarth-principles-of-origin-00:

Terminology: replace "URL" by "URI" throughout. Replace "MIME type" by 
"media type" throughout. Add proper references.

...

    A: Although the DNS has hierarchical delegation, the trust
    relationships between host names vary by deployment.  For example, at
    many educational institutions, students can host content at
    https://example.edu/~student/, but that does not mean a document
    authored by a student should be part of the same origin (i.e.,
    represent the same principal) as a web application for managing
    grades hosted at https://grades.example.edu/.

Comment: Maybe point out that under this arrangement, the URIs for 
different students *will* be in the same origin?

...

4.  Authority

It's a bit unfortunate that "authority" is used by RFC 3986 (URI) for 
something slightly different. If we don't want to change the term (which 
I assume) then it might be a good idea to clarify that this is not the 
same thing as the "authority" component of a URI as defined in 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.2>.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 28 May 2011 15:24:00 +1000

Hi Adam,

A bit late to the party, but FWIW I like this document.

It brings two questions to mind, however:

* Currently, HTTPbis ticket 270 [1] moves the details of the Upgrade process in HTTP to p2-semantics [2], which "updates" (not obsoletes) RFC2817 [3], the definition of how to upgrade to TLS within HTTP/1.1 (i.e., without changing the scheme). I'm wondering if a stronger statement needs to be made; e.g., obsoleting 2817, or marking it historic. It may also be worth mentioning in your draft as a bad practice.

* It doesn't mention CORS [4], which is a *much* more fine-grained (and as I've said many times, undesirably chatty) definition of a trust domain. Shouldn't there be some guidance the relationship between these different concepts, when it's appropriate ot use them, etc?

Cheers,

1. <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/240>
2. <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14>
3. <http://www.ietf.org/rfc/rfc2817.txt>
4. <http://www.w3.org/TR/cors/>

On 22/02/2011, at 9:10 AM, Adam Barth wrote:

> Pursuant to the charter, I've posted an informational draft that
> "describes the same-origin security model overall:"
> 
> http://www.ietf.org/id/draft-abarth-principles-of-origin-00.txt
> 
> I don't expect this document to be very controversial.  I'm sure folks
> will nitpick me over renaming URL to URI and MIME types to media
> types, however.  :)
> 
> Feedback welcome.
> 
> Adam
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

--
Mark Nottingham   http://www.mnot.net/

---

From: Adam Barth <[email-masked]>
Date: Fri, 27 May 2011 22:29:41 -0700

> A bit late to the party, but FWIW I like this document.

Thanks.  Not too late.  I've got the doc open in my editor as we speak.  :)

> * Currently, HTTPbis ticket 270 [1] moves the details of the Upgrade process in HTTP to p2-semantics [2], which "updates" (not obsoletes) RFC2817 [3], the definition of how to upgrade to TLS within…

Yeah, it's probably not intuitive why this causes security problems.

> * It doesn't mention CORS [4], which is a *much* more fine-grained (and as I've said many times, undesirably chatty) definition of a trust domain. Shouldn't there be some guidance the relationship…

There's a whole topic of controlled interaction between principals
(e.g., CORS, postMessage).  That's certainly important stuff, but I'm
not clear to me how to says something helpful about it compactly.  In
some sense, it's "a layer above" in that it builds on top of these
concepts. I'll find a way to add something in the network access
section about opting into more sharing (e.g., CORS).

Thanks!
Adam

---

From: Chris Weber <[email-masked]>
Date: Sat, 28 May 2011 09:02:16 -0700

Some minor suggestions on section "5.2.  Network Access".

    "Access to network resources varies depending on whether the resources
    are in the same origin as the document attempting to access them.

    Generally, reading information from another origin is forbidden."

Based on the generality of the content that is allowed - images, script, 
style sheets, it almost seems that the above sentence could be reversed 
to say that "Generally, reading information from another origin is 
allowed."  Otherwise, you could further demonstrate some of the cases 
where it is generally forbidden, such as with XmlHttpRequest.

    "However, a document is permitted use some kinds of resources
    retrieved from other origins.  For example, a document is permitted
    to execute script, render images, and apply style sheets from any
    origin.  Likewise, a document can display a document from another
    origin in a frame."

The notion of displaying a document in a frame may be misleading in the 
context of this paragraph, given that the other examples grant full 
access to the creator document's DOM, while the document in the frame 
does not.

    "Generally, sending information to another origin is permitted.
    However, sending information over the network in arbitrary formats is
    dangerous.  For this reason, user agents restrict documents to
    sending information using particular protocols, such as in an HTTP
    request without custom headers."

I'm feeling a bit hungry here, can you provide some more food for 
thought?  Some simple examples may help.  I'm thinking of HTML's 
postMessage interface and HTML forms.

Best regards,
Chris Weber

---

From: Chris Weber <[email-masked]>
Date: Sat, 28 May 2011 09:15:52 -0700

I wanted to suggest that section "3. Origin" include some examples 
presented in a clear and explicit way, such as in a list.

3.1 Examples of Resources With the Same Origin

All of the following resources can be said to have the same origin.

http://example.com
http://example.com:80
http://example.com/path/file
http://example.com

In these cases each URI would be parsed into identical scheme, host, and 
port components.

3.2 Examples of Resources With Different Origin

Each of the following resources can be said to have a different origin 
from the others in this list.

http://example.com
http://example.com:8080
http://www.example.com
https://example.com:80
https://example.com
http://google.com
http://ietf.org

In each case at least one element from the URI scheme, host, and port 
component will differ from the others in the list.

Best regards,
Chris Weber