Subject: Re: [websec] WG Last Call on draft-ietf-websec-origin-02 until Aug-15

From: Adam Barth <[email-masked]>
Date: Tue, 16 Aug 2011 19:14:11 -0700

I've upload a new version of the draft, which incorporates all the
feedback I've received:

http://www.ietf.org/id/draft-ietf-websec-origin-03.txt

Please let me know if I've missed any feedback.

Thanks all,
Adam

On Mon, Jul 18, 2011 at 12:38 PM, Tobias Gondrom
<[email-masked]> wrote:
> Hello dear websec fellows,
>
> after reading the feedback and the update on the origin draft, I have the
> impression that the draft is in good shape and like to ask for WG Last Call
> for this document:
> http://tools.ietf.org/html/draft-ietf-websec-origin-02
>
> As we are close to the IETF meeting in Quebec, this last call will be
> extended to four weeks and _*close on August-15.*_ Please make a last
> careful review of the draft and submit comments, questions and discuss items
> for this draft ASAP. If you perceive any major issues, it might also make
> sense to raise them during our meeting in Quebec on July-25.
>
> Kind regards and thank you,
>
> Tobias
> chair of websec
>
>
> Tobias Gondrom
> email: [email-masked]
> mobile: +447521003005
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 20 Aug 2011 18:52:48 +0100

>Please let me know if I've missed any feedback.
Hi Adam,
Sorry, I forgot to send out my comments on -02:

3.2.1.  Examples

   All of the following resources have the same origin:

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

The first and the last example are identical, was this intentional?

4.  Origin of a URI

   The origin of a URI is the value computed by the following algorithm:

   1.  If the URI does not use a server-based naming authority, or if
       the URI is not an absolute URI, then return a globally unique
       identifier.

 [...]

   6.  If there is no port component of the URI:

       1.  Let uri-port be the default port for the protocol given by
           uri-scheme.

       Otherwise:

       2.  Let uri-port be the port component of the URI.

I know this is an obscure case, but what will this algorithm return for 
a mailto URI (assuming that it is supported)? I am not entirely clear 
that # 1 applies here.

5.  Comparing Origins

      NOTE: A URI is not necessarily same-origin with itself.  For
      example, a data URI is not same-origin with itself because data

An Informative reference for the "data" URI scheme is needed here.

      URIs do not use a server-based naming authority and therefore have
      globally unique identifiers as origins.

6.  Serializing Origins

   This section defines how to serialize an origin to a unicode string
   and to an ASCII string.

Both Unicode and ASCII need references, I think they are normative.

---

From: Adam Barth <[email-masked]>
Date: Sat, 20 Aug 2011 12:47:00 -0700

> The first and the last example are identical, was this intentional?

Nope.  Fixed.

> I know this is an obscure case, but what will this algorithm return for a
> mailto URI (assuming that it is supported)? I am not entirely clear that # 1
> applies here.

It's a globally unique identifier.  mailto doesn't use a server-based
naming authority.  For example, here's a nutty mailto URI:

mailto:[email-masked],[email-masked]

Although the common case of mailto URLs does contain the name of a
single server, the general case doesn't.  (Admitted, this probably
isn't as clearly defined as it could be.)

> An Informative reference for the "data" URI scheme is needed here.

Done.

> Both Unicode and ASCII need references, I think they are normative.

Ok.  Are these the best references?

      <t>This section defines how to serialize an origin to a unicode <xref
      target="RFC5198" /> string and to an ASCII <xref target="RFC20" />
      string.</t>

Thanks,
Adam

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 22 Aug 2011 09:50:07 +0100

Hi Adam,

Adam Barth wrote:

>isn't as clearly defined as it could be.
>
Exactly my point. At first I thought that you meant URI scheme which 
allows for the <authority> component, but it seems like you are trying 
to define a wider category.

>)
Something like:

   [Unicode52]  The Unicode Consortium.  The Unicode Standard, Version
                5.2.0, defined by: "The Unicode Standard, Version
                5.2.0", (Mountain View, CA: The Unicode Consortium,
                2009. ISBN 978-1-936213-00-9).

for Unicode. Probably worth pointing to Unicode 6.0 though.

I think RFC 20 is Ok.

                <http://www.unicode.org/versions/Unicode5.2.0/>.

---

From: Adam Barth <[email-masked]>
Date: Tue, 23 Aug 2011 11:38:20 -0700

On Mon, Aug 22, 2011 at 1:50 AM, Alexey Melnikov
<[email-masked]> wrote:
> Exactly my point. At first I thought that you meant URI scheme which allows
> for the <authority> component, but it seems like you are trying to define a
> wider category.

I've reworked this phrase to more directly reference Section 3.2 of
RFC3986 (and I added an explicit reference).

Done.

Adam

---

From: Gervase Markham <[email-masked]>
Date: Wed, 24 Aug 2011 09:54:33 +0100

Hi Adam,

I've only just read this document; I didn't realise it contained a
dis-recommendation for the use of the Public Suffix List.

I couldn't see in the document any other way of allowing two
non-identical but related origins to collaborate. Do you have a
recommendation for this use case (a number of sites across the same
company, and so on)? It's rather an important one on the web today.

Gerv

---

From: Adam Barth <[email-masked]>
Date: Wed, 24 Aug 2011 02:11:39 -0700

> company, and so on)? It's rather an important one on the web today.

Cross-Origin Resource Sharing is an excellent way of collaborating
between multiple origins:

http://www.w3.org/TR/cors/

In any case, nothing in this document changes how cookies work.  The
IETF recently published RFC6265, which explicitly mentions the use of
the public suffix list.  Similarly, HTML continues to require support
for document.domain, which also uses the public suffix list.

The purpose of this text in this document is to caution against
creating more such reliance on the public suffix list.  Instead, the
verified origin approach (e.g., as used in CORS and CSP) is a much
more robust way of addressing many of the same use cases.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Aug 2011 10:08:21 +0200

On 2011-08-26 09:58, Adam Barth wrote:
> ...
> That could well be important if the Origin header is used in other
> protocols, such as CORS.  Would you recommend requiring the first or
> the last instance?
> ...

(cc'ing the IETF WG; I was replying to the wrong email thread)

I think the right thing to do would be to recommend one of:

- treat the message as invalid, or

- ignore the header field (whatever that means...).

Picking one of the two seems to be the wrong approach.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Fri, 26 Aug 2011 01:12:56 -0700

[-public-web-security, to avoid cross-posting too much]

> Picking one of the two seems to be the wrong approach.

Ok.  Maybe the best solution is to treat the header as if it contained
the value "null", which basically means the server doesn't know which
origin sent the message.  That what we recommend user agents do when
they get confused about what value to put in the header.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Aug 2011 10:50:04 +0200

On 2011-08-26 10:12, Adam Barth wrote:
> On Fri, Aug 26, 2011 at 1:08 AM, Julian Reschke<[email-masked]>  wrote:

It just occurred to me that this will be hard to do in some cases.

Intermediaries/middleware/libraries are allowed to collapse multiple 
headers into a single one, so

   Origin: http://example.com
   Origin: b

would be combined to

   Origin: http://example.com,b

The "," is allowed in reg-name, so you can't detect this as invalid.

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Fri, 26 Aug 2011 02:04:54 -0700

On Fri, Aug 26, 2011 at 1:50 AM, Julian Reschke <[email-masked]> wrote:
> Intermediaries/middleware/libraries are allowed to collapse multiple headers
> into a single one, so
>

Correct.  That's why we forbid user agents from generating those requests.

Adam