[http-state] HTTP cookie processing wrt "public suffixes"
2 views
Skip to first unread message
=JeffH
Nov 9, 2014, 6:23:38 PM11/9/14
to HTTP State
This is a (draft) community-service posting: The purpose is to unambiguously
state the specification of "cookie processing wrt public suffixes".
It is somewhat difficult to tease this out of the requisite specification(s)
and associated documents, e.g., [RFC6265] and the Public Suffix List [PSL],
and so here it is (corrections/comments welcome).
=JeffH
------
HTTP cookie processing wrt "public suffixes" aka "effective TLDs"
Contents:
1. Terminology
2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs
3. Detailed Cookie-setting and -returning Algorithms wrt eTLDs
4. Excerpts from [RFC6265]
6. References
1. Terminology:
Cookie - a unit of HTTP state management data, sent by the server to the UA
as part of (some) HTTP responses. The UA returns cookie(s) to the server on
all subsequent requests, modulo various rules (some of which are discussed
herein, the full story is given by [RFC6265]).
effective TLD (eTLD) - a term closely related to "public suffix". It is more
general than the term "public suffix" -- i.e., because it implies that the
domain in question ought to be treated as effectively a TLD, but it may
actually not be an official TLD, nor might it allow for "public" subdomain
registrations (as the term "public suffix" specifically implies).
Origin - {scheme, host, port} tuple of a webapp [RFC6454].
Public Suffix - A "public suffix" is a DNS domain [RFC1034] under which
Internet users can directly register names [modulo some policies]. Some
examples of public suffixes are .com, .co.uk and pvt.k12.ma.us [PSL].
[However, this definition does not adequately address various subtleties in
practice, hence, in part, the [DBOUND] effort. Note that the term "effective
TLD (eTLD)" is closely related, and that the domains listed in [PSL] are a
superset of TLDs.]
subdomain - a child domain of some given domain. E.g., foo.example.org is a
subdomain of example.org.
superdomain - the parent domain of some given domain. E.g., example.org is
the superdomain of foo.example.org.
TLD / Top-level Domain - TLDs are those single-label DNS domains directly
under the DNS root [RFC1591]. See [IANA-TLDs] for the current list of TLDs.
UA - a (web) User Agent, e.g. a web browser.
webapp - a web application, which has both a server-side and client-side
instances. The client-side instances, which are emitted by the server-side
over HTTP, are effectively mobile code (typically composed of
HTML+JavaScript+CSS+etc), and execute within UAs (as "web pages"), and have
an origin derived from the server-side's URI.
2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs:
(a) A server-side webapp, whose origin's host component [RFC6454] (aka
domain name) IS NOT a "public suffix"/eTLD, can "set cookies" (on UAs) for
its own domain name, or for superdomains -- unless the targeted superdomain
is a eTLD. In the latter case, the set-cookie attempt is ignored.
(b) The UA will return cookies set for a given host (aka domain) to only
that host, or, to that host and all subdomains thereof (depending on
server-specified particulars of the cookie itself).
(c) Conversely, a server-side webapp whose origin's host component IS
denoted as a "public suffix"/eTLD (i.e., it appears in [PSL] or similar
compendiums) can set cookies for itself (modulo UA configuration), but its
subdomains can not set cookies for the eTLD domain.
(d) The UA will not return any of the eTLD's cookies to subdomain servers.
Effectively, this depends upon UA configuration -- i.e., a UA might be
configured to not accept cookies from an eTLD server at all.
3. Detailed Cookie-setting and -returning Algorithms wrt eTLDs:
Excerpts from [RFC6265] expressing the specifics underlying the
cookie-setting and -returning algorithms, and in which the effects of
"public suffixes"/eTLDs are specified, are found in the section after this
one. They are referred to (using an "S" prefix) in the following
explanations of the algorithms summarized in the preceding section:
In terms of (a), a server that is NOT a eTLD doing cookie-setting: the 2nd
portion of S 4.1.2.3 describes the cookie-setting semantics, step 5 of S 5.3
handles cookie-setting attempts for "public suffixes", step 6 of S 5.3
defines the determination of the cookie's applicable domain and its notation
in the cookie's cookie store entry, e.g. setting the host-only-flag. The
host-only-flag governs whether the cookie will be returned to the origin
server only, or whether it will be returned to the origin server as well as
its subdomains.
In terms of (b), a UA returning cookies to non-eTLD servers: S 5.4 governs
the construction of the Cookie header for the HTTP request, which depends
directly upon the cookie entry's host-only-flag, and the domain-match
algorithm (S 5.1.3).
In terms of (c), a "public suffix"/eTLD webapp doing cookie-setting: the 2nd
portion of S 4.1.2.3 describes again applies, and refers directly to S 5.3
in this case. S 5.3 steps 5 and 6 apply and the path through them depends on
whether the UA is config'd to reject "public suffixes" or not. If not, and
the domain-attribute is empty, then in step 6 the cookie is stored in the
cookie store with its host-only-flag set to true and its domain set to the
canonicalized request-host.
In terms of (d), a UA returning cookies to a "public suffix"/eTLD server:
if the UA does accept cookies set by eTLD servers, then step 1 of S 5.4 will
gather only such cookies return to ONLY the eTLD server, due to the manner
that they were set in the cookie store.
4. Excerpts from [RFC6265]:
[Note: I've included the hierarchy of [RFC6265] section titles in
order to provide context.]
4. Server Requirements
4.1. Set-Cookie
4.1.2. Semantics (Non-Normative)
4.1.2.3. The Domain Attribute
https://tools.ietf.org/html/rfc6265#section-4.1.2.3
The Domain attribute specifies those hosts to which the cookie will
be sent. For example, if the value of the Domain attribute is
"example.com", the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, www.example.com, and
www.corp.example.com. ... If the server omits the Domain attribute,
the user agent will return the cookie only to the origin server.
...
The user agent will reject cookies unless the Domain attribute
specifies a scope for the cookie that would include the origin
server. For example, the user agent will accept a cookie with a
Domain attribute of "example.com" or of "foo.example.com" from
foo.example.com, but the user agent will not accept a cookie with a
Domain attribute of "bar.example.com" or of "baz.foo.example.com".
NOTE: For security reasons, many user agents are configured to reject
Domain attributes that correspond to "public suffixes". For example,
some user agents will reject Domain attributes of "com" or "co.uk".
(See Section 5.3 for more information.)
...
5. User Agent Requirements
5.1. Subcomponent Algorithms
5.1.3. Domain Matching
https://tools.ietf.org/html/rfc6265#section-5.1.3
A string domain-matches a given domain string if at least one of the
following conditions hold:
o The domain string and the string are identical. (Note that both
the domain string and the string will have been canonicalized to
lower case at this point.)
o All of the following conditions hold:
* The domain string is a suffix of the string.
* The last character of the string that is not included in the
domain string is a %x2E (".") character.
* The string is a host name (i.e., not an IP address).
5.3. Storage Model
https://tools.ietf.org/html/rfc6265#section-5.3
...
5. If the user agent is configured to reject "public suffixes" and
the domain-attribute is a public suffix:
If the domain-attribute is identical to the canonicalized
request-host:
Let the domain-attribute be the empty string.
Otherwise:
Ignore the cookie entirely and abort these steps.
NOTE: A "public suffix" is a domain that is controlled by a
public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
This step is essential for preventing attacker.com from
disrupting the integrity of example.com by setting a cookie
with a Domain attribute of "com". Unfortunately, the set of
public suffixes (also known as "registry controlled domains")
changes over time. If feasible, user agents SHOULD use an
up-to-date public suffix list, such as the one maintained by
the Mozilla project at <http://publicsuffix.org/>.
6. If the domain-attribute is non-empty:
If the canonicalized request-host does not domain-match the
domain-attribute:
Ignore the cookie entirely and abort these steps.
Otherwise:
Set the cookie's host-only-flag to false.
Set the cookie's domain to the domain-attribute.
Otherwise:
Set the cookie's host-only-flag to true.
Set the cookie's domain to the canonicalized request-host.
...
5.4. The Cookie Header
https://tools.ietf.org/html/rfc6265#section-5.4
The user agent includes stored cookies in the Cookie HTTP request
header.
...
If the user agent does attach a Cookie header field to an HTTP
request, the user agent MUST send the cookie-string (defined below)
as the value of the header field.
The user agent MUST use an algorithm equivalent to the following
algorithm to compute the "cookie-string" from a cookie store and a
request-uri:
1. Let cookie-list be the set of cookies from the cookie store that
meets all of the following requirements:
* Either:
The cookie's host-only-flag is true and the canonicalized
request-host is identical to the cookie's domain.
Or:
The cookie's host-only-flag is false and the canonicalized
request-host domain-matches the cookie's domain.
* The request-uri's path path-matches the cookie's path.
...
* If the cookie's http-only-flag is true, then exclude the
cookie if the cookie-string is being generated for a "non-
HTTP" API (as defined by the user agent).
...
6. References:
[DBOUND] https://www.ietf.org/mailman/listinfo/dbound
[IANA-TLDs] https://www.iana.org/domains/root/db
[PSL] Public Suffix List
https://publicsuffix.org/
[RFC1034] DOMAIN NAMES - CONCEPTS AND FACILITIES
https://tools.ietf.org/html/rfc1034
[RFC1591] Domain Name System Structure and Delegation
http://tools.ietf.org/html/rfc1591
see also: https://en.wikipedia.org/wiki/Top-level_domain
[RFC6265] HTTP State Management Mechanism
https://tools.ietf.org/html/rfc6265
[RFC6454] The Web Origin Concept
https://tools.ietf.org/html/rfc6454
end
_______________________________________________
http-state mailing list
http-...@ietf.org
https://www.ietf.org/mailman/listinfo/http-state
state the specification of "cookie processing wrt public suffixes".
It is somewhat difficult to tease this out of the requisite specification(s)
and associated documents, e.g., [RFC6265] and the Public Suffix List [PSL],
and so here it is (corrections/comments welcome).
=JeffH
------
HTTP cookie processing wrt "public suffixes" aka "effective TLDs"
Contents:
1. Terminology
2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs
3. Detailed Cookie-setting and -returning Algorithms wrt eTLDs
4. Excerpts from [RFC6265]
6. References
1. Terminology:
Cookie - a unit of HTTP state management data, sent by the server to the UA
as part of (some) HTTP responses. The UA returns cookie(s) to the server on
all subsequent requests, modulo various rules (some of which are discussed
herein, the full story is given by [RFC6265]).
effective TLD (eTLD) - a term closely related to "public suffix". It is more
general than the term "public suffix" -- i.e., because it implies that the
domain in question ought to be treated as effectively a TLD, but it may
actually not be an official TLD, nor might it allow for "public" subdomain
registrations (as the term "public suffix" specifically implies).
Origin - {scheme, host, port} tuple of a webapp [RFC6454].
Public Suffix - A "public suffix" is a DNS domain [RFC1034] under which
Internet users can directly register names [modulo some policies]. Some
examples of public suffixes are .com, .co.uk and pvt.k12.ma.us [PSL].
[However, this definition does not adequately address various subtleties in
practice, hence, in part, the [DBOUND] effort. Note that the term "effective
TLD (eTLD)" is closely related, and that the domains listed in [PSL] are a
superset of TLDs.]
subdomain - a child domain of some given domain. E.g., foo.example.org is a
subdomain of example.org.
superdomain - the parent domain of some given domain. E.g., example.org is
the superdomain of foo.example.org.
TLD / Top-level Domain - TLDs are those single-label DNS domains directly
under the DNS root [RFC1591]. See [IANA-TLDs] for the current list of TLDs.
UA - a (web) User Agent, e.g. a web browser.
webapp - a web application, which has both a server-side and client-side
instances. The client-side instances, which are emitted by the server-side
over HTTP, are effectively mobile code (typically composed of
HTML+JavaScript+CSS+etc), and execute within UAs (as "web pages"), and have
an origin derived from the server-side's URI.
2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs:
(a) A server-side webapp, whose origin's host component [RFC6454] (aka
domain name) IS NOT a "public suffix"/eTLD, can "set cookies" (on UAs) for
its own domain name, or for superdomains -- unless the targeted superdomain
is a eTLD. In the latter case, the set-cookie attempt is ignored.
(b) The UA will return cookies set for a given host (aka domain) to only
that host, or, to that host and all subdomains thereof (depending on
server-specified particulars of the cookie itself).
(c) Conversely, a server-side webapp whose origin's host component IS
denoted as a "public suffix"/eTLD (i.e., it appears in [PSL] or similar
compendiums) can set cookies for itself (modulo UA configuration), but its
subdomains can not set cookies for the eTLD domain.
(d) The UA will not return any of the eTLD's cookies to subdomain servers.
Effectively, this depends upon UA configuration -- i.e., a UA might be
configured to not accept cookies from an eTLD server at all.
3. Detailed Cookie-setting and -returning Algorithms wrt eTLDs:
Excerpts from [RFC6265] expressing the specifics underlying the
cookie-setting and -returning algorithms, and in which the effects of
"public suffixes"/eTLDs are specified, are found in the section after this
one. They are referred to (using an "S" prefix) in the following
explanations of the algorithms summarized in the preceding section:
In terms of (a), a server that is NOT a eTLD doing cookie-setting: the 2nd
portion of S 4.1.2.3 describes the cookie-setting semantics, step 5 of S 5.3
handles cookie-setting attempts for "public suffixes", step 6 of S 5.3
defines the determination of the cookie's applicable domain and its notation
in the cookie's cookie store entry, e.g. setting the host-only-flag. The
host-only-flag governs whether the cookie will be returned to the origin
server only, or whether it will be returned to the origin server as well as
its subdomains.
In terms of (b), a UA returning cookies to non-eTLD servers: S 5.4 governs
the construction of the Cookie header for the HTTP request, which depends
directly upon the cookie entry's host-only-flag, and the domain-match
algorithm (S 5.1.3).
In terms of (c), a "public suffix"/eTLD webapp doing cookie-setting: the 2nd
portion of S 4.1.2.3 describes again applies, and refers directly to S 5.3
in this case. S 5.3 steps 5 and 6 apply and the path through them depends on
whether the UA is config'd to reject "public suffixes" or not. If not, and
the domain-attribute is empty, then in step 6 the cookie is stored in the
cookie store with its host-only-flag set to true and its domain set to the
canonicalized request-host.
In terms of (d), a UA returning cookies to a "public suffix"/eTLD server:
if the UA does accept cookies set by eTLD servers, then step 1 of S 5.4 will
gather only such cookies return to ONLY the eTLD server, due to the manner
that they were set in the cookie store.
4. Excerpts from [RFC6265]:
[Note: I've included the hierarchy of [RFC6265] section titles in
order to provide context.]
4. Server Requirements
4.1. Set-Cookie
4.1.2. Semantics (Non-Normative)
4.1.2.3. The Domain Attribute
https://tools.ietf.org/html/rfc6265#section-4.1.2.3
The Domain attribute specifies those hosts to which the cookie will
be sent. For example, if the value of the Domain attribute is
"example.com", the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, www.example.com, and
www.corp.example.com. ... If the server omits the Domain attribute,
the user agent will return the cookie only to the origin server.
...
The user agent will reject cookies unless the Domain attribute
specifies a scope for the cookie that would include the origin
server. For example, the user agent will accept a cookie with a
Domain attribute of "example.com" or of "foo.example.com" from
foo.example.com, but the user agent will not accept a cookie with a
Domain attribute of "bar.example.com" or of "baz.foo.example.com".
NOTE: For security reasons, many user agents are configured to reject
Domain attributes that correspond to "public suffixes". For example,
some user agents will reject Domain attributes of "com" or "co.uk".
(See Section 5.3 for more information.)
...
5. User Agent Requirements
5.1. Subcomponent Algorithms
5.1.3. Domain Matching
https://tools.ietf.org/html/rfc6265#section-5.1.3
A string domain-matches a given domain string if at least one of the
following conditions hold:
o The domain string and the string are identical. (Note that both
the domain string and the string will have been canonicalized to
lower case at this point.)
o All of the following conditions hold:
* The domain string is a suffix of the string.
* The last character of the string that is not included in the
domain string is a %x2E (".") character.
* The string is a host name (i.e., not an IP address).
5.3. Storage Model
https://tools.ietf.org/html/rfc6265#section-5.3
...
5. If the user agent is configured to reject "public suffixes" and
the domain-attribute is a public suffix:
If the domain-attribute is identical to the canonicalized
request-host:
Let the domain-attribute be the empty string.
Otherwise:
Ignore the cookie entirely and abort these steps.
NOTE: A "public suffix" is a domain that is controlled by a
public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
This step is essential for preventing attacker.com from
disrupting the integrity of example.com by setting a cookie
with a Domain attribute of "com". Unfortunately, the set of
public suffixes (also known as "registry controlled domains")
changes over time. If feasible, user agents SHOULD use an
up-to-date public suffix list, such as the one maintained by
the Mozilla project at <http://publicsuffix.org/>.
6. If the domain-attribute is non-empty:
If the canonicalized request-host does not domain-match the
domain-attribute:
Ignore the cookie entirely and abort these steps.
Otherwise:
Set the cookie's host-only-flag to false.
Set the cookie's domain to the domain-attribute.
Otherwise:
Set the cookie's host-only-flag to true.
Set the cookie's domain to the canonicalized request-host.
...
5.4. The Cookie Header
https://tools.ietf.org/html/rfc6265#section-5.4
The user agent includes stored cookies in the Cookie HTTP request
header.
...
If the user agent does attach a Cookie header field to an HTTP
request, the user agent MUST send the cookie-string (defined below)
as the value of the header field.
The user agent MUST use an algorithm equivalent to the following
algorithm to compute the "cookie-string" from a cookie store and a
request-uri:
1. Let cookie-list be the set of cookies from the cookie store that
meets all of the following requirements:
* Either:
The cookie's host-only-flag is true and the canonicalized
request-host is identical to the cookie's domain.
Or:
The cookie's host-only-flag is false and the canonicalized
request-host domain-matches the cookie's domain.
* The request-uri's path path-matches the cookie's path.
...
* If the cookie's http-only-flag is true, then exclude the
cookie if the cookie-string is being generated for a "non-
HTTP" API (as defined by the user agent).
...
6. References:
[DBOUND] https://www.ietf.org/mailman/listinfo/dbound
[IANA-TLDs] https://www.iana.org/domains/root/db
[PSL] Public Suffix List
https://publicsuffix.org/
[RFC1034] DOMAIN NAMES - CONCEPTS AND FACILITIES
https://tools.ietf.org/html/rfc1034
[RFC1591] Domain Name System Structure and Delegation
http://tools.ietf.org/html/rfc1591
see also: https://en.wikipedia.org/wiki/Top-level_domain
[RFC6265] HTTP State Management Mechanism
https://tools.ietf.org/html/rfc6265
[RFC6454] The Web Origin Concept
https://tools.ietf.org/html/rfc6454
end
_______________________________________________
http-state mailing list
http-...@ietf.org
https://www.ietf.org/mailman/listinfo/http-state
Adam Barth
Nov 9, 2014, 7:21:04 PM11/9/14
to =JeffH, HTTP State
names that are not in [IANA-TLDs]. For example, inside many corporate
networks, "www" is a single-label DNS name that resolves to a web
server (and many times is interested in setting cookies). It's
unclear whether you mean to include such things in this definition of
TLD.
> UA - a (web) User Agent, e.g. a web browser.
>
> webapp - a web application, which has both a server-side and client-side
> instances. The client-side instances, which are emitted by the server-side
> over HTTP, are effectively mobile code (typically composed of
> HTML+JavaScript+CSS+etc), and execute within UAs (as "web pages"), and have
> an origin derived from the server-side's URI.
>
>
>
> 2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs:
>
> (a) A server-side webapp, whose origin's host component [RFC6454] (aka
> domain name) IS NOT a "public suffix"/eTLD, can "set cookies" (on UAs) for
> its own domain name, or for superdomains -- unless the targeted superdomain
> is a eTLD. In the latter case, the set-cookie attempt is ignored.
> (b) The UA will return cookies set for a given host (aka domain) to only
> that host, or, to that host and all subdomains thereof (depending on
> server-specified particulars of the cookie itself).
>
> (c) Conversely, a server-side webapp whose origin's host component IS
> denoted as a "public suffix"/eTLD (i.e., it appears in [PSL] or similar
> compendiums) can set cookies for itself (modulo UA configuration), but its
> subdomains can not set cookies for the eTLD domain.
> (d) The UA will not return any of the eTLD's cookies to subdomain servers.
> Effectively, this depends upon UA configuration -- i.e., a UA might be
> configured to not accept cookies from an eTLD server at all.
break in corporate networks that use DNS names like "www"...
=JeffH
Nov 13, 2014, 9:07:29 PM11/13/14
to HTTP State
Thanks to Adam Barth for his comments on this.
In terms of the first comment on single-label domain names, I added a
definition for them and updated other related definitions.
wrt..
4.1.2.3. on the Domain Attribute. I've removed that statement from section 2
of the below, and made some other fixups/polishing.
any other comments from anyone?
thanks,
=JeffH
---- updated original msg ----
This is a (draft) community-service posting: The purpose is to unambiguously
state the specification of "cookie processing wrt public suffixes".
It is somewhat difficult to tease this out of the requisite specification(s)
and associated documents, e.g., [RFC6265] and the Public Suffix List [PSL],
and so here it is (corrections/comments welcome).
=JeffH
------
HTTP cookie processing wrt "public suffixes" aka "effective TLDs (eTLDs)"
Contents:
1. Terminology
2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs
3. Detailed Cookie-setting and -returning Algorithms wrt eTLDs
4. Excerpts from [RFC6265]
5. References
1. Terminology:
Cookie - a unit of HTTP state management data, sent by the server to the UA
as part of (some) HTTP responses. The UA returns cookie(s) to the server on
all subsequent requests, modulo various rules (some of which are discussed
herein, the full story is given by [RFC6265]).
eTLD / effective Top Level Domain - a term closely related to "public
Web Origin.
Public Suffix - A "public suffix" is a DNS domain [RFC1034] under which
Internet users can directly register names [modulo some policies]. Some
examples of public suffixes are .com, .co.uk and pvt.k12.ma.us [PSL]. Note
however, this definition does not adequately address various subtleties in
practice (hence, in part, the [DBOUND] effort). Also note that the term
single-label domain name - A DNS name consisting of a single label, e.g.,
"org", "net", "com". Note that on various networks, often in enterprise
deployments, existence of "local" single-label domains is not uncommon,
e.g., "corp", "www". See also eTLD and TLD.
subdomain - a child domain of some given domain [RFC1034]. E.g.,
single-label DNS names are globally-visible TLDs. See also single-label
domain name.
UA / User Agent - A web browser, or other HTTP client implementation, that
implements the HTTP State spec [RFC6265], i.e., accepts cookies sent by HTTP
servers.
webapp - a web application, which has both a server-side and client-side
instances. The client-side instances, which are emitted by the server-side
over HTTP, are effectively mobile code (typically composed of
HTML+JavaScript+CSS+etc), and execute within UAs (as "web pages"), and have
an origin derived from the server-side's URI. Note that this also
encompasses "apps" that are not general purpose web browsers but that meet
the definition of UA.
2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs:
(a) A server-side webapp, whose origin's host component [RFC6454] (aka
domain name) IS NOT a "public suffix"/eTLD, can "set cookies" (on UAs) for
its own domain name, or for superdomains -- unless the targeted superdomain
is a eTLD. In the latter case, the set-cookie attempt is ignored.
(b) The UA will return cookies set for a given host (aka domain) to only
that host, or, to that host and all subdomains thereof (depending on
server-specified particulars of the cookie itself).
(c) Conversely, a server-side webapp whose origin's host component IS
denoted as a "public suffix"/eTLD (i.e., it appears in [PSL] or similar
compendiums) can set cookies for itself (modulo UA configuration), but its
subdomains can not set cookies for the eTLD domain.
(d) The UA will not return any of the eTLD's cookies to subdomain servers.
step 1 of S 5.4 will gather only such cookies and return them to ONLY the
eTLD server, due to the manner that they were recorded in the cookie store.
5. References:
In terms of the first comment on single-label domain names, I added a
definition for them and updated other related definitions.
wrt..
>> (d) The UA will not return any of the eTLD's cookies to subdomain
>> servers. Effectively, this depends upon UA configuration -- i.e., a UA
>> might be configured to not accept cookies from an eTLD server at all.
>
> Are there popular UAs that are configured that way? Presumably they'd
> break in corporate networks that use DNS names like "www"...
oops yeah, you're correct, thx. I'd misread the Note at the end of S
>> servers. Effectively, this depends upon UA configuration -- i.e., a UA
>> might be configured to not accept cookies from an eTLD server at all.
>
> Are there popular UAs that are configured that way? Presumably they'd
> break in corporate networks that use DNS names like "www"...
4.1.2.3. on the Domain Attribute. I've removed that statement from section 2
of the below, and made some other fixups/polishing.
any other comments from anyone?
thanks,
=JeffH
---- updated original msg ----
This is a (draft) community-service posting: The purpose is to unambiguously
state the specification of "cookie processing wrt public suffixes".
It is somewhat difficult to tease this out of the requisite specification(s)
and associated documents, e.g., [RFC6265] and the Public Suffix List [PSL],
and so here it is (corrections/comments welcome).
=JeffH
------
Contents:
1. Terminology
2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs
3. Detailed Cookie-setting and -returning Algorithms wrt eTLDs
4. Excerpts from [RFC6265]
1. Terminology:
Cookie - a unit of HTTP state management data, sent by the server to the UA
as part of (some) HTTP responses. The UA returns cookie(s) to the server on
all subsequent requests, modulo various rules (some of which are discussed
herein, the full story is given by [RFC6265]).
suffix". It is more general than the term "public suffix" -- i.e., because
it implies that the domain in question ought to be treated effectively as a
TLD, but it may actually not be an official TLD, nor might it allow for
"public" subdomain registrations (as the term "public suffix" specifically
implies).
Origin - {scheme, host, port} tuple of a webapp [RFC6454], also known as a
"public" subdomain registrations (as the term "public suffix" specifically
implies).
Web Origin.
Public Suffix - A "public suffix" is a DNS domain [RFC1034] under which
Internet users can directly register names [modulo some policies]. Some
however, this definition does not adequately address various subtleties in
practice (hence, in part, the [DBOUND] effort). Also note that the term
"effective TLD (eTLD)" is closely related, and that the domains listed in
[PSL] are a superset of actual IANA-registered TLDs [IANA-TLDs].
single-label domain name - A DNS name consisting of a single label, e.g.,
"org", "net", "com". Note that on various networks, often in enterprise
deployments, existence of "local" single-label domains is not uncommon,
e.g., "corp", "www". See also eTLD and TLD.
subdomain - a child domain of some given domain [RFC1034]. E.g.,
foo.example.org is a subdomain of example.org.
superdomain - the parent domain of some given domain. E.g., example.org is
the superdomain of foo.example.org.
TLD / Top-level Domain - TLDs are those single-label DNS domains directly
under the global public DNS root [IANA-TLDs] [RFC1591]. However, not all
superdomain - the parent domain of some given domain. E.g., example.org is
the superdomain of foo.example.org.
TLD / Top-level Domain - TLDs are those single-label DNS domains directly
single-label DNS names are globally-visible TLDs. See also single-label
domain name.
UA / User Agent - A web browser, or other HTTP client implementation, that
implements the HTTP State spec [RFC6265], i.e., accepts cookies sent by HTTP
servers.
webapp - a web application, which has both a server-side and client-side
instances. The client-side instances, which are emitted by the server-side
over HTTP, are effectively mobile code (typically composed of
HTML+JavaScript+CSS+etc), and execute within UAs (as "web pages"), and have
encompasses "apps" that are not general purpose web browsers but that meet
the definition of UA.
2. Summarized Cookie-setting and -returning Algorithms wrt eTLDs:
(a) A server-side webapp, whose origin's host component [RFC6454] (aka
domain name) IS NOT a "public suffix"/eTLD, can "set cookies" (on UAs) for
its own domain name, or for superdomains -- unless the targeted superdomain
is a eTLD. In the latter case, the set-cookie attempt is ignored.
(b) The UA will return cookies set for a given host (aka domain) to only
that host, or, to that host and all subdomains thereof (depending on
server-specified particulars of the cookie itself).
(c) Conversely, a server-side webapp whose origin's host component IS
denoted as a "public suffix"/eTLD (i.e., it appears in [PSL] or similar
compendiums) can set cookies for itself (modulo UA configuration), but its
subdomains can not set cookies for the eTLD domain.
(d) The UA will not return any of the eTLD's cookies to subdomain servers.
eTLD server, due to the manner that they were recorded in the cookie store.
Reply all
Reply to author
Forward
0 new messages