[http-state] Securing cookie domain handling

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

Hello all,

Now that RFC 6265 have published it may be time to look into the one of  
the problematic parts of cookie security, specifically cookie domains.

Domain permission policies have been through several iterations from  
Netscape's original one internal dot for generic TLDs, two for everything  
else, via RFC 2965 "just the parent domain", various ad-hoc heuristics, to  
the current use of public suffix lists.

At present, RFC 6265 mention public suffix lists as a possible domain  
filtering mechanism, but does not really define them, or how to construct  
a list of them (naturally, since it is out of scope for the document), or  
reference a document doing so (since no normative document exist, although  
I have tried to write one[3]).

Public suffix lists have serveral problems, beside the lack of a normative  
definition, such as requiring extensive research in order to generate the  
list, which can result in significant delays before clients are aware of  
updates.

Even with perfect public suffix lists being used to filter domains, this  
only prevents the client from accepting cookies specifying too wide  
distribution, they do not provide any way for the server to know if the  
cookies it received really are authorized cookies from servers allowed to  
set them (Advanced techniques can limit the problem, but not eliminate it).

IMO servers need better information, and clients need better ways to  
distinguish acceptable domains from unacceptable.

There are in my opinion several possible ways to accomplish this:

  * RFC 2965's $Domain, $Path, $Port attributes will inform the server  
about the reach of the cookies, and it can decide whether to accept  
cookies based on that reach. This does not provide any further information  
to the client, and while it allows the server to filter cookies away, it  
does not provide any information about the source of a cookie that broke  
the rules.

  * Provide origin information to the server, such as using $Origin as  
suggested by my draft-pettersen-cookie-origin [1] drafts. This allows the  
server to discover if the cookie originated from an authorized server,  
even within its own domain, that is not expected to set the cookie.  
Together with $Domain&co. this could provide better information about  
source and distribution.

  * Change how servers specify cookie sharing, by not allowing them to set  
cookies to parent domains, but only allowing them to share with servers  
within the subdomain it is on the top of. This is what I suggested in my  
Cookie-v2 [2] draft (based on RFC 2965), which also suggested a similar  
approach for Paths. This prevents clients from setting cookies with  
too-wide distribution, and combined with $Domain it will also provide  
sufficient origin information, without really requiring the $Origin  
attribute, and it does not actually need a list of public suffixes.

As I recall others have proposed different possibilities, but the above  
mentioned are the ones I think are most likely to work, alone or in  
combination, without too much difficulty.

Should the IETF, through the HTTPState WG, websec, or other WG look into  
this issue, and try to define a method? Are there other ways forward than  
the ones mentioned above that will work equally well, or better?


References:
[1] https://datatracker.ietf.org/doc/draft-pettersen-cookie-origin/
[2] https://datatracker.ietf.org/doc/draft-pettersen-cookie-v2/
[3] https://datatracker.ietf.org/doc/draft-pettersen-subtld-structure/

At present these are all expired, I am working on updating them.

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