Subject: [websec] draft-ietf-websec-origin-02

From: Adam Barth <[email-masked]>
Date: Fri, 24 Jun 2011 13:59:46 -0700

I've posted an updated version of the origin draft:

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

The new version includes Security Considerations, IANA Considerations,
and a completed references section.  Feedback on the new Security
Considerations section would be much appreciated.

I also removed the (stub) Privacy Considerations section.  If there's
something you think should be discussed there, let me know.

Thanks,
Adam

---

From: Thomas Fossati <[email-masked]>
Date: Sat, 25 Jun 2011 08:48:25 +0200

> I've posted an updated version of the origin draft:

Good job.

> Considerations section would be much appreciated.

What about a 'Reliance on HTTP intermediaries' (e.g. implication of cache poisoning) in parallel with the 'Reliance on DNS' subsection ?

Also it'd be nice to have a reference to the chrome-extension scheme.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Jun 2011 12:48:13 +0200

On 2011-06-24 22:59, Adam Barth wrote:
> ...
> ...

Editorial nits: the references section should cite Internet Drafts as 
such; see

http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hybi-thewebsocketprotocol-09.xml

and

http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-websec-mime-sniff-03.xml

(note you may want to short the anchors)

For the W3C references I recommend the format in 
<http://greenbytes.de/tech/webdav/rfc2629xslt/w3c-references.html>:

<reference anchor='WD-cors-20100727'
            target='http://www.w3.org/TR/2010/WD-cors-20100727/'>
   <front>
     <title>Cross-Origin Resource Sharing</title>
     <author fullname='Anne van Kesteren' surname='van Kesteren' 
initials='A.'/>
     <date year='2010' month='July' day='27'/>
   </front>
   <seriesInfo name='W3C Working Draft' value='WD-cors-20100727'/>
   <annotation>
     Latest version available at
     <eref target='http://www.w3.org/TR/cors/'/>.
   </annotation>
</reference>

<reference anchor='WD-html5-20110525'
            target='http://www.w3.org/TR/2011/WD-html5-20110525/'>
   <front>
     <title>HTML5</title>
     <author fullname='Ian Hickson' surname='Hickson' initials='I.'/>
     <date year='2011' month='May' day='25'/>
   </front>
   <seriesInfo name='W3C Working Draft' value='WD-html5-20110525'/>
   <annotation>
     Latest version available at
     <eref target='http://www.w3.org/TR/html5/'/>.
   </annotation>
</reference>

Best regards, Julian

---

From: "Blanc Gregory" <[email-masked]>
Date: Sun, 26 Jun 2011 03:17:37 +0900

Hello,

please find below a few spotted typos and comments.

abstract: 
"underlie" instead of "underly"
"concept of origin" instead of "origin concept"

page 5:
"an idna-canonicalized" instead of "a idna-canonicalized"

page 9:
3.4.1
"content retrieved from one URI" instead of "content retrieve from one URI"

page 10:
3.4.2
"permitted to use" instead of "permitted use"

page 13:
5.
"Two origins" instead of "To origins"

page 16:
7.2
"For example, consider a user agent that executes scripts on behalf of
origins.  If one of those scripts causes the user agent to issue an
HTTP request, the user agent might wish to use the Origin header to
inform the server that the request was issued by the script".
Since the Origin header is a list of serialized origins, we can
assume this contains the origin that issued the request but not
the specific script as the sentence above indicates.
This is somehow tackled in page 19, section 8.3.

"In some cases, a number of origins contribute to causing the user
agents to issue an HTTP request.  In those cases, the user agent can
list all the origins in the Origin header.  For example, if the HTTP
request was initially issued by one origin but then later redirected
by another origin, the user agent might wish to inform the server
that two origins were involved in causing the user agent to issue the
request".
Does the sentence above only refer to the case of redirection as
evidenced by the example or does the author implies other cases?
To the best of my knowledge, I cannot think of any other case?
Maybe I should think more about it. At least, cases implied here
are only sequential and never concurrent, aren't they?

Regards,

Greg

06/25/11 に、Adam Barth  <[email-masked]> さんは書きました:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Chris Weber <[email-masked]>
Date: Sun, 26 Jun 2011 14:57:43 -0700

A couple of questions:

1) Do you have a reference to the "chrome-extension URI scheme"?
I was just trying to figure out what it was.

2) In section 6.1 where it says:

"4. Apply the IDNA ToUnicode algorithm [RFC5891] to each component of
the host part of the origin triple"

Should the reference be to Section 4.2 "ToUnicode" of RFC3490 http://tools.ietf.org/html/rfc3490#section-4.2, or Section 5.2 "Conversion to Unicode" of RFC 5891 http://tools.ietf.org/html/rfc5891#section-5.2?

-Chris

On 6/24/2011 1:59 PM, Adam Barth wrote:

Thanks,
Adam

---

From: Adam Barth <[email-masked]>
Date: Sun, 26 Jun 2011 15:08:12 -0700

On Sun, Jun 26, 2011 at 2:57 PM, Chris Weber <[email-masked]> wrote:
> A couple of questions:
>
> 1) Do you have a reference to the "chrome-extension URI scheme"?  I was just
> trying to figure out what it was.

I'll add a reference.  It's not standard, but it's used in the Chrome
extension system.  Basically, the URLs look like the following:

chrome-extension://ankgjoopnopeoeljehjkighfcfefalcg/foo.html

ankgjoopnopeoeljehjkighfcfefalcg is (roughly) a fingerprint of a public key.

> Should the reference be to Section 4.2 "ToUnicode" of RFC3490
> http://tools.ietf.org/html/rfc3490#section-4.2, or Section 5.2 "Conversion
> to Unicode" of RFC 5891 http://tools.ietf.org/html/rfc5891#section-5.2?

http://tools.ietf.org/html/draft-ietf-websec-origin-02#section-10.1

[[
   IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not
   backwards-compatible.  For this reason, there will be a transition
   period (possibly of a number of years).  User agents SHOULD implement
   IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46
   <http://unicode.org/reports/tr46/>] in order to facilitate a smoother
   IDNA transition.  If a user agent does not implement IDNA2008, the
   user agent MUST implement IDNA2003 [RFC3490].
]]

which is a polite way of saying that the authors of RFC 5891 didn't
pay attention to the constraints of some implementors, which means
those implementors will probably ignore RFC 5891 for the foreseeable
future.

Adam

---

From: Robert Buchholz <[email-masked]>
Date: Wed, 29 Jun 2011 15:59:27 +0200

Besides the typos noted by Gregory, page 20 has:
  "This practice is incompatible with URIs schemes that"
which should probably be
  "This practice is incompatible with URI schemes that"

Robert

---

From: Chris Weber <[email-masked]>
Date: Thu, 30 Jun 2011 15:35:23 -0700

On 6/24/2011 1:59 PM, Adam Barth wrote

In section 4 step 5 what was intended by "idna-canonicalization"?

5. Let uri-host be the idna-canonicalization of the host component
of the URI.

Are implementers to choose whether to apply IDNA2003, IDNA2008, or
TR46 in determining the canonical form?  If so should the reference
to section 10.1 be made here?

-Chris

---

From: Adam Barth <[email-masked]>
Date: Thu, 30 Jun 2011 15:50:16 -0700

On Thu, Jun 30, 2011 at 3:35 PM, Chris Weber <[email-masked]> wrote:
> Are implementers to choose whether to apply IDNA2003, IDNA2008, or TR46 in
> determining the canonical form?  If so should the reference to section 10.1
> be made here?

We should reference 10.1.  This tail isn't going to wag the IDNA dog.

Adam

---

From: Adam Barth <[email-masked]>
Date: Thu, 30 Jun 2011 15:51:33 -0700

> We should reference 10.1.  This tail isn't going to wag the IDNA dog.

Actually, I misspoke.  The idna-canonicalization is a defined
algorithm in the spec (which eventually references 10.1).  I need to
go through and make sure all the reference point to the right things.

Adam

---

From: Chris Weber <[email-masked]>
Date: Thu, 30 Jun 2011 16:30:08 -0700

> go through and make sure all the reference point to the right things.

Oh duh, I feel silly.  Editorial nit - maybe a minor change to make the 
terms (or tense) match would help.  Keeping with section 2.3's defined 
term "idna-canonicalized" then the sentence in section 4 step 5 would read:

   "Let uri-host be the idna-canonicalized form of the host component of 
the URI."

-Chris