[http-state] Public suffixes (was Re: Security considerations overview)

Adam Barth <ietf@adambarth.com> Wed, 03 March 2010 23:38 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; b=JgA9w8DauhaUMzFV2WNa6SEmgXBYjd7aIjux/a4sbCptM6/EzLRPViBIDw3GsJnB/r kW+UBh+NBBSuWLJ6GGu+FSRKxAYeDMptJRxmA4s7E02vz8xf/G6s/faeBAHiBIjCg59e qdqWsTK6/viF/ZU0YTeTsgD380DkvsPgloMqE=
MIME-Version: 1.0
Sender: abarth@gmail.com
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 03 Mar 2010 15:38:29 -0800
Message-ID: <5c4444771003031538v64f3b7b7u81e2d79242da8db8@mail.gmail.com>
To: Mark Pauley <mpauley@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: http-state <http-state@ietf.org>
Subject: [http-state] Public suffixes (was Re: Security considerations overview)
Precedence: list

On Wed, Mar 3, 2010 at 3:32 PM, Mark Pauley <mpauley@apple.com> wrote:
> Excuse my ignorance, I've just recently joined this list.

Welcome!  Some folks on the list find it helpful if you change the
subject line when bringing up a new topic.

> Is this the correct forum to enquire about what we refer to as the 'Cross Site Acceptance Policy'?

Yes.  We've discussed this previously as part of
<http://trac.tools.ietf.org/wg/httpstate/trac/ticket/3>.  You can
search the archives for emails with "Ticket 3" in the subject to see
some of the previous discussion.

> We (Safari / CFNetwork) by default refuse to set cookies from hosts from a domain tree outside of the current Top Level Domain tree.  That is from a host with name x1.x2.x3...x_k  we'll set a cookie with domain .y1.y2.y3...y_m if and only if y_m == x_k, y_m-1 == x_k-1, etc to y_m-n == x_k-n and y1....y_m-n is not a top level domain.
>
> That is, if the domain is at least a cousin; the target domain shares a common ancestor with the origin domain which is not a Top Level Domain.
>
> We've worked out that this is probably the most restrictive definition that will work given a good enough description of what a Top Level Domain is (which we have thanks to the Mozilla Top Level Domain list project).

The current draft doesn't require this behavior, but recommends that
user agents use a public suffix (such as the one maintained by Mozilla
at <http://publicsuffix.org/>) in the way you describe.

Our thought process was that these restrictions are necessary for
security, but not all user agents will be willing or able to track the
public suffix list (because it's a moving target) and none of the
known heuristics (sort of the full list) provide an attractive
security / functionality trade-off.

Adam

[http-state] Public suffixes (was Re: Security co… Adam Barth