Re: [http-state] Ticket 3: Public Suffixes

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

Comments below:

On Sat, 16 Jan 2010 09:01:00 +0100, Adam Barth <[e-mail]> wrote:

> 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.

Alternative 4: Use a DNS based heuristic by only allowing cookies set to  
domains that have an IP address defined. If there is no IP address, remove  
the domain attribute

    See my draft describing Opera's implementation:  
http://www.ietf.org/internet-drafts/draft-pettersen-dns-cookie-validate-05.txt

Alternative 5: (which require an extensive change of the cookie  
specification) Reverse the domain semantics. Do not allow a site to set  
cookies for a parent domain, only the server itself or its subdomain any  
host with the server's name as the suffix (that is, example.com can set  
cookies either for the server example.com or the entire domain  
example.com; www.example.com cannot set a cookie for the domain  
example.com)

See the following for my suggestion  (the draft is currently expired)

    http://files.myopera.com/yngve/blog/draft-pettersen-cookie-v2-03.txt


Regarding public suffix, see my proposal

    http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-05.txt

and Opera's upcoming system public suffix system (which is already live):

    http://my.opera.com/yngve/blog/2009/06/17/refreshed-subtld-public-suffix-drafts
    http://my.opera.com/rootstore/blog/2009/06/17/swisssign-ev-enabled-and-a-public-suffix-list

And my older articles about the topic

    http://my.opera.com/yngve/blog/show.dml/267415
    http://my.opera.com/yngve/blog/show.dml/388840


-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************