[http-state] Ticket 3: Public Suffixes

[Adam Barth <[e-mail]>]

I'd like to start discussing the issues in the tracker.  Hopefully
we'll be able to resolve them and make progress on the draft.

The first issue I'd like to discuss is what to do with public suffixes:
http://trac.tools.ietf.org/wg/httpstate/trac/ticket/3

I'm not setting any particular deadline to responding to this
proposal, but hopefully we can sort something out relatively soon and
then move on to the next issue.

== Overview ==

When a server sets a cookie, the server tells the user agent which
domains the cookie is for.  The protocol restricts the server to
specifying a suffix of its own host name.  For example, if the server
is foo.example.com, the server can set a cookie for foo.example.com,
example.com, or com.

This behavior turns out to be a security problem because when
attacker.com sets a cookie for com, that cookie is sent to example.com
and can confusing the example.com server.  This attack technique has
had a number of names of the years, but I'm going to call it "cookie
forcing" in this discussion.

Cookie forcing arises because of two design flaws in the cookie
protocol: (1) servers are allowed to set cookies for superdomains and
(2) when receiving a cookie, a server cannot determine the scope of
the cookie.  Unfortunately, fixing these underlying issues is out of
scope for our present work (although cookie2 has some interesting
ideas in this regard).

What user agents actually do is slightly data-intensive.  Essentially,
each user agent has a list of so-called public suffixes (or "registry
controlled" domains).  The user agent then refuses to accept cookies
whose scope is a public suffix.  For example, user agents will not
accept cookies for "com" or for "co.uk".  See, for example,
<http://publicsuffix.org/>, which is the list used by Mozilla and some
other open-source browsers.  Microsoft has it's own list for IE, which
I don't believe is publicly available.  These lists are somewhat long
and dynamic because there are a lot of domain registries in the world
and the rules are different in every province of Japan.

== Proposal ==

I propose that the spec contain a description of the vulnerability and
recommend at the SHOULD level that user agents drop cookies set for
public suffixes.

== Alternatives ==

One alternative is to require that all user agents use a specific
well-known public suffix list.  The problem with this approach is that
the list evolves with time and tracking the list is some amount of
effort.  Not all user agents will want to update when the list
updates.  These user agents will need to make a risk management
decision about how to approximate the list based on their security and
compatibility needs.

Another alternative is to recommend a heuristic that works in many
cases and then further recommend that user agents use the full list.
The problem with this approach is that I don't know of any simple
heuristics that provide reasonable behavior.  In the past, some user
agents have used heuristics based on the length of the top-level
domain (i.e., two characters => ccTLD => foo.cc is a public suffix).
Unfortunately, this heuristic has undesirable consequences for some
small countries that let folks register domains directly in the ccTLD.

A third alternative is to ignore the issue entirely, but this approach
would be a disservice to folks who need to write secure user agents.

Comments?
Adam