draft-ietf-websec-origin-05.txt   draft-ietf-websec-origin-06.txt 
websec A. Barth websec A. Barth
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track September 23, 2011 Intended status: Standards Track October 3, 2011
Expires: March 26, 2012 Expires: April 5, 2012
The Web Origin Concept The Web Origin Concept
draft-ietf-websec-origin-05 draft-ietf-websec-origin-06
Abstract Abstract
This document defines the concept of an "origin", which is often used This document defines the concept of an "origin", which is often used
as the scope of authority or privilege by user agents. Typically, as the scope of authority or privilege by user agents. Typically,
user agents isolate content retrieved from different origins to user agents isolate content retrieved from different origins to
prevent malicious web site operators from interfering with the prevent malicious web site operators from interfering with the
operation of benign web sites. In addition to outlining the operation of benign web sites. In addition to outlining the
principles that underlie the concept of origin, this document defines principles that underlie the concept of origin, this document defines
how to determine the origin of a URI, how to serialize an origin into how to determine the origin of a URI, how to serialize an origin into
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 26, 2012. This Internet-Draft will expire on April 5, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 4 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 4
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 6 3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 6
3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 9 3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 10 3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 2, line 41 skipping to change at page 2, line 41
6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 15 6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 15
6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 15 6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 15
7. The HTTP Origin header field . . . . . . . . . . . . . . . . . 17 7. The HTTP Origin header field . . . . . . . . . . . . . . . . . 17
7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 17 7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 19 8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 19
8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 19 8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 19
8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 20 8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8.4. IDNA dependency and migration . . . . . . . . . . . . . . 20
9.1. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. IDNA dependency and migration . . . . . . . . . . . . . . . . 22 9.1. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
User agents interact with content created by a large number of User agents interact with content created by a large number of
authors. Although many of those authors are well-meaning, some authors. Although many of those authors are well-meaning, some
authors might be malicious. To the extent that user agents undertake authors might be malicious. To the extent that user agents undertake
actions based on content they process, user agent implementors might actions based on content they process, user agent implementors might
wish to restrict the ability of malicious authors to disrupt the wish to restrict the ability of malicious authors to disrupt the
confidentiality or integrity of other content or servers. confidentiality or integrity of other content or servers.
skipping to change at page 4, line 37 skipping to change at page 4, line 37
notation of [RFC5234]. notation of [RFC5234].
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US- sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US-
ASCII character), VCHAR (any visible US-ASCII character), and WSP ASCII character), VCHAR (any visible US-ASCII character), and WSP
(whitespace). (whitespace).
The OWS (optional whitespace) rule is used where zero or more linear The OWS rule is used where zero or more linear whitespace octets
whitespace characters MAY appear: might appear. OWS SHOULD either not be produced or be produced as a
single SP. Multiple OWS octets that occur within field-content
OWS = *( [ obs-fold ] WSP ) SHOULD either be replaced with a single SP or transformed to all SP
; "optional" whitespace octets (each octet other than SP replaced with SP) before
obs-fold = CRLF interpreting the field value or forwarding the message downstream.
OWS SHOULD either not be produced or be produced as a single SP OWS = *( SP / HTAB / obs-fold )
character. ; "optional" whitespace
obs-fold = CRLF ( SP / HTAB )
; obsolete line folding
2.3. Terminology 2.3. Terminology
The terms user agent, client, server, proxy, and origin server have The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification ([RFC2616], Section the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
1.3). 1.3).
A globally unique identifier is a value which is different from all A globally unique identifier is a value which is different from all
other previously existing values. For example, a sufficiently long other previously existing values. For example, a sufficiently long
random string is likely to be a globally unique identifier. If the random string is likely to be a globally unique identifier. If the
origin value never leaves the user agent, a monotonically increasing origin value never leaves the user agent, a monotonically increasing
counter local to the user agent can also serve as a globally unique counter local to the user agent can also serve as a globally unique
identifier identifier
For the purposes of this document, we define "idna-canonicalized host
name" as the string generated by the following algorithm:
1. Convert the host name to a sequence of NR-LDH labels (see Section
2.3.2.2 of [RFC5890]) and/or A-labels according to the
appropriate IDNA specification [RFC5891] or [RFC3490] (see
Section 10 of this specification)
2. Convert the labels to lower case (using the i;ascii-casemap
collation defined in [RFC4790]).
3. Concatenate the labels, separating each label from the next with
a %x2E (".") character.
3. Principles of the Same-Origin Policy 3. Principles of the Same-Origin Policy
Many user agents undertake actions on behalf of remote parties. For Many user agents undertake actions on behalf of remote parties. For
example, HTTP user agents follow redirects, which are instructions example, HTTP user agents follow redirects, which are instructions
from remote servers and HTML user agents expose rich DOM interfaces from remote servers and HTML user agents expose rich DOM interfaces
to scripts retrieved from remote servers. to scripts retrieved from remote servers.
Without any security model, user agents might undertake actions Without any security model, user agents might undertake actions
detrimental to the user or to other parties. Over time, many web- detrimental to the user or to other parties. Over time, many web-
related technologies have converged towards a common security model, related technologies have converged towards a common security model,
skipping to change at page 12, line 14 skipping to change at page 12, line 14
4. Origin of a URI 4. Origin of a URI
The origin of a URI is the value computed by the following algorithm: The origin of a URI is the value computed by the following algorithm:
1. If the URI does not use a hierarchical element as a naming 1. If the URI does not use a hierarchical element as a naming
authority (see [RFC3986], Section 3.2), or if the URI is not an authority (see [RFC3986], Section 3.2), or if the URI is not an
absolute URI, then generate a fresh globally unique identifier absolute URI, then generate a fresh globally unique identifier
and return that value. and return that value.
1. NOTE: Running this algorithm multiple times for the same URI NOTE: Running this algorithm multiple times for the same URI
can produce different values each time. Typically, user can produce different values each time. Typically, user
agents compute the origin of, for example, an HTML document agents compute the origin of, for example, an HTML document
once and use that origin for subsequent security checks once and use that origin for subsequent security checks rather
rather than recomputing the origin for each security check. than recomputing the origin for each security check.
2. Let uri-scheme be the scheme component of the URI, converted to 2. Let uri-scheme be the scheme component of the URI, converted to
lowercase. lowercase.
3. If the implementation doesn't support the protocol given by uri- 3. If the implementation doesn't support the protocol given by uri-
scheme, then return generate a fresh globally unique identifier scheme, then return generate a fresh globally unique identifier
and return that value. and return that value.
4. If uri-scheme is "file", the implementation MAY return an 4. If uri-scheme is "file", the implementation MAY return an
implementation-defined value. implementation-defined value.
1. NOTE: Historically, user agents have granted content from the 1. NOTE: Historically, user agents have granted content from the
file scheme a tremendous amount of privilege. However, file scheme a tremendous amount of privilege. However,
granting all local files such wide privileges can lead to granting all local files such wide privileges can lead to
privilege escalation attacks. Some user agents have had privilege escalation attacks. Some user agents have had
success granting local files directory-based privileges, but success granting local files directory-based privileges, but
this approach has not been widely adopted. Other user agents this approach has not been widely adopted. Other user agents
use globally unique identifiers for each file URI, which is use globally unique identifiers for each file URI, which is
the most secure option. the most secure option.
5. Let uri-host be the idna-canonicalized form of the host component 5. Let uri-host be the host component of the URI, converted to lower
of the URI. case (using the i;ascii-casemap collation defined in [RFC4790]).
1. NOTE: This document assumes that the user agent performs IDNA
processing and validation when constructing the URI. In
particular, this document assumes the uri-host will contain
only LDH-labels because the user agent will have already
converted any non-ASCII labels to their corresponding
A-labels (see [RFC5890]). For this reason, origin-based
security policies are sensitive to the IDNA algorithm
employed by the user agent. See Section 8.4 for further
discussion.
6. If there is no port component of the URI: 6. If there is no port component of the URI:
1. Let uri-port be the default port for the protocol given by 1. Let uri-port be the default port for the protocol given by
uri-scheme. uri-scheme.
Otherwise: Otherwise:
2. Let uri-port be the port component of the URI. 2. Let uri-port be the port component of the URI.
skipping to change at page 15, line 27 skipping to change at page 15, line 27
null null
(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C)
and abort these steps. and abort these steps.
2. Otherwise, let result be the scheme part of the origin triple. 2. Otherwise, let result be the scheme part of the origin triple.
3. Append the string "://" to result. 3. Append the string "://" to result.
4. Apply the IDNA ToUnicode algorithm (from the appropriate IDNA 4. Append each component of the host part of the origin triple
specification [RFC5891] or [RFC3490], see Section 10 of this (converted as follows) to the result, separated by U+002E FULL
specification) to each component of the host part of the origin STOP code points ("."):
triple, and append the results of each component, in the same
order, separated by U+002E FULL STOP code points (".") to result. * If the component is an A-label, use the corresponding U-label
instead (see [RFC5890] and [RFC5891]).
* Otherwise, use the component verbatim.
5. If the port part of the origin triple is different than the 5. If the port part of the origin triple is different than the
default port for the protocol given by the scheme part of the default port for the protocol given by the scheme part of the
origin triple: origin triple:
1. Append a U+003A COLON code point (":") and the given port, in 1. Append a U+003A COLON code point (":") and the given port, in
base ten, to result. base ten, to result.
6. Return result. 6. Return result.
skipping to change at page 17, line 13 skipping to change at page 17, line 13
6. Return result. 6. Return result.
7. The HTTP Origin header field 7. The HTTP Origin header field
This section defines the HTTP Origin header field. This section defines the HTTP Origin header field.
7.1. Syntax 7.1. Syntax
The Origin header field has the following syntax: The Origin header field has the following syntax:
origin = "Origin:" OWS origin-list-or-null OWS origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = "null" / origin-list origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list = serialized-origin *( SP serialized-origin ) origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ] serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> productions from RFC3986 ; <scheme>, <host>, <port> from RFC3986
7.2. Semantics 7.2. Semantics
When included in an HTTP request, the Origin header field indicates When included in an HTTP request, the Origin header field indicates
the origin(s) that "caused" the user agent to issue the request, as the origin(s) that "caused" the user agent to issue the request, as
defined by the API that triggered the user agent to issue the defined by the API that triggered the user agent to issue the
request. request.
For example, consider a user agent that executes scripts on behalf of 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 origins. If one of those scripts causes the user agent to issue an
skipping to change at page 21, line 5 skipping to change at page 20, line 38
Consider, for example, cross-site scripting in HTML documents. If an Consider, for example, cross-site scripting in HTML documents. If an
attacker can inject script content into an HTML document, those attacker can inject script content into an HTML document, those
scripts will run with the authority of the document's origin, perhaps scripts will run with the authority of the document's origin, perhaps
allowing the script access to sensitive information, such as the allowing the script access to sensitive information, such as the
user's medical records. If, however, the script's authority were user's medical records. If, however, the script's authority were
limited to those objects that the script could designate, the limited to those objects that the script could designate, the
attacker would not gain any advantage by injecting the script into an attacker would not gain any advantage by injecting the script into an
HTML document hosted by a third party. HTML document hosted by a third party.
8.4. IDNA dependency and migration
The security properties of the same-origin policy can depend
crucially on details of the IDNA algorithm employed by the user
agent. In particular, a user agent might map some international
domain names (for example, those involving the U+00DF character) to
different ASCII representations depending on whether the user agent
uses IDNA2003 [RFC3490] or IDNA2008 [RFC5890].
Migrating from one IDNA algorithm to another might redraw a number of
security boundaries, potentially erecting new security boundaries or,
worse, tearing down security boundaries between two mutually
distrusting entities. Changing security boundaries is risky because
combining two mutually distrusting entities into the same origin
might allow one to attack the other.
9. IANA Considerations 9. IANA Considerations
The permanent message header field registry (see [RFC3864]) should be The permanent message header field registry (see [RFC3864]) should be
updated with the following registrations: updated with the following registrations:
9.1. Origin 9.1. Origin
Header field name: Origin Header field name: Origin
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 7) Specification document: this specification (Section 7)
10. IDNA dependency and migration 10. References
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 [UnicodeTR46] in order to
facilitate a smoother IDNA transition. If a user agent does not
implement IDNA2008, the user agent MUST implement IDNA2003 [RFC3490].
11. References
11.1. Normative References 10.1. Normative References
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
See Section 10 for an explanation why the normative
reference to an obsoleted specification is needed.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, Application Protocol Collation Registry", RFC 4790,
March 2007. March 2007.
[UnicodeTR46]
The Unicode Consortium, "Unicode IDNA Compatibility
Processing", 2010, <http://unicode.org/reports/tr46/>.
[Unicode52] [Unicode52]
The Unicode Consortium, "The Unicode Standard, Version The Unicode Consortium, "The Unicode Standard, Version
5.1.0", Unicode 5.0.0, Boston, MA, Addison-Wesley ISBN 5.1.0", Unicode 5.0.0, Boston, MA, Addison-Wesley ISBN
0-321-48091-0, as amended by Unicode 5.1.0 0-321-48091-0, as amended by Unicode 5.1.0
http://www.unicode.org/versions/Unicode5.1.0/, 2008, http://www.unicode.org/versions/Unicode5.1.0/, 2008,
<http://www.unicode.org/versions/Unicode5.2.0/>. <http://www.unicode.org/versions/Unicode5.2.0/>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
11.2. Informative References 10.2. Informative References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
August 1998. August 1998.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
See Section 8.4 for an explanation why the normative
reference to an obsoleted specification is needed.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[WEBSOCKETS] [WEBSOCKETS]
Fette, I., "The WebSocket protocol", Fette, I. and A. Melnikov, "The WebSocket protocol",
draft-ietf-hybi-thewebsocketprotocol-09 (work in draft-ietf-hybi-thewebsocketprotocol-17 (work in
progress), June 2011. progress), September 2011.
[SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing", [SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing",
draft-ietf-websec-mime-sniff-03 (work in progress), draft-ietf-websec-mime-sniff-03 (work in progress),
May 2011. May 2011.
[HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5-20110525, [HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5-20110525,
May 2011, <http://www.w3.org/TR/2011/WD-html5-20110525/>. May 2011, <http://www.w3.org/TR/2011/WD-html5-20110525/>.
Latest version available at <http://www.w3.org/TR/html5/>. Latest version available at <http://www.w3.org/TR/html5/>.
skipping to change at page 26, line 8 skipping to change at page 25, line 8
<http://w2spconf.com/2008/papers/s2p1.pdf>. <http://w2spconf.com/2008/papers/s2p1.pdf>.
[CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman, [CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman,
"Protecting Browsers from Extension Vulnerabilities", "Protecting Browsers from Extension Vulnerabilities",
2010, 2010,
<http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>. <http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
We would like to thank Lucas Adamski, Stephen Farrell, Miguel A. We would like to thank Lucas Adamski, Stephen Farrell, Miguel A.
Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Collin Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Jeff Hodges,
Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham, Julian Collin Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham,
Reschke, Jonas Sicking, Sid Stamm, Daniel Veditz, and Chris Weber for Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid Stamm, Daniel
their valuable feedback on this document. Veditz, and Chris Weber for their valuable feedback on this document.
Author's Address Author's Address
Adam Barth Adam Barth
Google, Inc. Google, Inc.
Email: ietf@adambarth.com Email: ietf@adambarth.com
URI: http://www.adambarth.com/ URI: http://www.adambarth.com/
 End of changes. 21 change blocks. 
82 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/