Re: [http-state] HTTP cookie processing wrt "public suffixes"

Zhong Yu

unread,

May 18, 2015, 10:44:07 AM5/18/15

to http-state, te...@publicsuffix.org

There is a complication that is neither addressed in the RFC nor in
Jeff's document:

- it's possible that the parent of a public suffix is not a public
suffix itself.

For example: compute.amazonAws.com is a public suffix; but its
parent, amazonAws.com, is not a public suffix.

Obviously, we cannot allow `foo.compute.amazonAws.com` to set
cookie.domain=amazonAws.com, even though `amazonAws.com` is not a
public suffix.

To be fair, this situation should not have existed; it's bad enough
that companies spam the public suffix list with no discipline and
consideration; it's unconscionable that they introduce unnecessary
complications like this. /rant

Anyways, how do we handle this situation? The simplest solution is to
declare that all parents of a public suffix are public suffixes too.
However this might break existing deployments where a parent is a
"normal" website.

If we accept the reality that a parent of a public suffix may not be a
public suffix, the cookie domain algorithm needs to be a little more
sophisticated. We want to achieve the following effect:

1. foo.compute.amazonAws.com cannot set a cookie for
compute.amazonAws.com or higher domains

2. w1.amazonAws.com can set a cookie for amazonAws.com, which affects
w2.amazonAws.com.
however the cookie must not affect compute.amazonAws.com and its subdomains.

Zhong Yu
bayou.io

_______________________________________________
http-state mailing list
http-...@ietf.org
https://www.ietf.org/mailman/listinfo/http-state

Zhong Yu

unread,

May 19, 2015, 12:36:26 PM5/19/15

to Gervase Markham, te...@publicsuffix.org, http-state

Thanks Gerv, but we are talking about different things. In this
discussion, there is no dispute that "amazonaws.com" is-not a public
suffix, and "computer.amazonaws.com" is.

The question is, whether "foo.computer.amazonaws.com" can set a cookie
with domain "amazonaws.com". Obvious it should not be able to. And all
major browsers will deny it.

However, the letter of RFC6265 would have permitted it, because the
cookie domain "amazonaws.com" is not a public suffix.

There are two ways to address this problem:

1. fix RFC
2. fix PSL so that a parent of a public suffix is implicitly a public
suffix. (this is a little different from the discussion of "*" rules)

I think (2) is pretty reasonable. Domain names are cheap, a company
should just get a new domain for public suffix, instead of use a
subdomain.

Zhong Yu
bayou.io

On Tue, May 19, 2015 at 4:58 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 18/05/15 15:44, Zhong Yu wrote:
>> There is a complication that is neither addressed in the RFC nor in
>> Jeff's document:
>>
>> - it's possible that the parent of a public suffix is not a public
>> suffix itself.
>

> See https://bugzilla.mozilla.org/show_bug.cgi?id=1139842 for the
> discussion of the PSL team on how to deal with the current ambiguous
> situation in the PSL.
>
> Gerv

Zhong Yu

unread,

May 19, 2015, 12:37:47 PM5/19/15

to Gervase Markham, te...@publicsuffix.org, http-state

Zhong Yu

unread,

May 19, 2015, 12:46:38 PM5/19/15

to Gervase Markham, te...@publicsuffix.org, http-state

On Tue, May 19, 2015 at 11:37 AM, Zhong Yu <zhong...@gmail.com> wrote:
> Here is a list of public suffix which has a parent that's not a public suffix:

So the problem is quite limited at current time.

We can probably convince amazonaws.com/cn be a public suffix.

forgot.her/his.name seems defunct.

fastly.net seems defunct.

not sure about .no domains.

Zhong Yu
bayou.io

Zhong Yu

unread,

May 21, 2015, 7:30:29 PM5/21/15

to http-state, te...@publicsuffix.org

After more thoughts on the matter, it seems not uncommon that a parent
of a public suffix is not a public suffix. Besides the domains listed
in my previous email, all "*" rules in PSL imply a public suffix with
a non-public-suffix parent. For example, rule "*.bd" means that any
"foo.bd" is a public suffix, but the parent, "bd", is not a public
suffix (because the public cannot directly register child domains of
"bd")

With this clarified, we'll have to fix RFC6265. Currently it allows
"bar.foo.bd" to set a cookie for domain "bd". That is incorrect; and
it is not how browsers behave. I'll see if I can find a simple
algorithm to address the problem.

Gervase Markham

unread,

May 22, 2015, 5:46:01 PM5/22/15

to Zhong Yu, http-state, te...@publicsuffix.org

On 18/05/15 15:44, Zhong Yu wrote:

> There is a complication that is neither addressed in the RFC nor in
> Jeff's document:
>
> - it's possible that the parent of a public suffix is not a public
> suffix itself.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1139842 for the
discussion of the PSL team on how to deal with the current ambiguous
situation in the PSL.

Gerv

Zhong Yu

unread,

Jun 5, 2015, 6:28:32 PM6/5/15

to http-state, te...@publicsuffix.org

I've written an article explaining cookie domain and public suffix, in which I propose a simple mode that seems very sensible -

A cookie domain's coverage set is defined as:
- the set contains the cookie domain
- if the set contains x, and x is not a public suffix, the set contains all direct subdomains of x.

Testing the coverage - A cookie domain must cover the request domain
- when the cookie is received
- when the cookie is applied to a request

Basically, a cookie domain can bet set by any domain in the coverage set; and the cookie is applicable to all domains in the coverage set.

See http://bayou.io/draft/cookie.domain.html#Coverage_Model

Zhong Yu
bayou.io

Reply all

Reply to author

Forward