Subject: Re: [websec] Comments on draft-abarth-principles-of-origin-00, was: Reviews of draft-ietf-websec-origin and principles-of-origin - until end of May

From: Adam Barth <[email-masked]>
Date: Mon, 13 Jun 2011 09:46:36 -0700

On Fri, May 13, 2011 at 1:47 AM, Julian Reschke <[email-masked]> wrote:
> Terminology: replace "URL" by "URI" throughout.

Done.

> Replace "MIME type" by "media type" throughout.

Done.

> Add proper references.

Which references would you like to see added?

>   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?

Done.

> 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>.

Done.

Thanks!
Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 13 Jun 2011 10:40:20 -0700

On Fri, May 27, 2011 at 10:24 PM, Mark Nottingham <[email-masked]> wrote:
> A bit late to the party, but FWIW I like this document.

Thanks.

> 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.

This was actually already in the document somewhat obliquely, but I've
made it less oblique by adding a reference to RFC 2817.  In some
sense, it's not really RFC 2817's fault because if that had become
popular, then the rest of the security model would have evolved in a
different way.

> * 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 to use them, etc?

I've added a reference to CORS.  I don't want to go into too much
detail, but explaining that servers can opt into sharing their content
more widely seems valuable.

Thanks!

Adam

> 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: Mon, 13 Jun 2011 10:58:21 -0700

On Sat, May 28, 2011 at 9:02 AM, Chris Weber <[email-masked]> wrote:
> 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.

The general case is that it is forbidden.  It's only in the enumerated
special cases that it is allowed.  The number of enumerated cases
isn't related to what happens in the general case.

>   "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.

That's not accurate.  Rendering an image from another origin does not
grant fully access to the creator document's DOM, nor does applying
style sheets (in modern browsers).

>   "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.

I added a sentence about the recent issues with WebSockets expanding
the allowable set of things an origin can send.

Thanks!
Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 13 Jun 2011 11:09:55 -0700

On Sat, May 28, 2011 at 9:15 AM, Chris Weber <[email-masked]> wrote:
> 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.

Done.

Thanks,
Adam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jun 2011 21:38:46 +0200

On 2011-06-13 18:46, Adam Barth wrote:
> On Fri, May 13, 2011 at 1:47 AM, Julian Reschke<[email-masked]>  wrote:
 > ...

I believe I was thinking that RFC 3986 and the MIME specs (RFC 2045 etc) 
should be cited...

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Mon, 13 Jun 2011 12:41:01 -0700

Will do.  Thanks.

Adam