W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

(HTTP Cookie) Domain structure/validation drafts released

From: Yngve N. Pettersen (Developer Opera Software ASA) <yngve@opera.com>
Date: Fri, 27 Oct 2006 04:57:28 +0200
To: ietf-http-wg@w3.org
Message-ID: <op.th17t2i6qrq7tp@nimisha.oslo.opera.com>


Hello all,

I have now submitted updated versions of my drafts describing the HTTP  
Cookie DNS validation procedure and the SubTLD domain structure protocol.

I have also submitted a proposal for how to limit the multiserver  
distribution of HTTP cookies through the use of new domain rules that are  
more restrictive than those used by RFC 2965. This new proposal will not  
work with most current websites with multiserver cookie sharing, and a  
client that only implement the new rules will therefore not function on  
most current websites.

These proposals are intended to limit the distribution of HTTP cookies to  
hosts that are independent of the site setting the cookies but are located  
in the same registry-like/TLD-like domain, such as co.uk, or  
city.state.us. Sharing of cookies among sites located in such domains (e.g  
example1.co.uk and example2.co.uk) is not desirable and may cause both  
privacy problems and interference between independet sites. The currently  
defined domain rules, even when properly implemented (which is not  
possible due to how many TLDs have organized their domain hierarchies),  
are not able to prevent many of these problems.

For more information about the background please see my presentation to  
the DNSOP WG meeting in Montreal and my articles listed below.

  * Montreal presentation <URL:  
http://www3.ietf.org/proceedings/06jul/slides/dnsop-1.pdf >

  * "How to make sure the cookies don't burn your fingers?": <URL:  
http://my.opera.com/yngve/blog/show.dml/267415 >

  * "Time for a new (HTTP) Cookie recipe?": <URL:  
http://my.opera.com/yngve/blog/show.dml/388840 >

I am very much interested in hearing about proposals for alternative  
methods to achieve the necessary limitation of HTTP cookie sharing.

---------------------------------------
	Title		: The TLD Subdomain Structure Protocol and its
                           use for Cookie domain validation
	Author(s)	: Y. Pettersen
	Filename	: draft-pettersen-subtld-structure-01.txt
	Pages		: 14
	Date		: 2006-10-26
	
This document defines a protocol and specification format that can be
    used by a client to discover how a Top Level Domain (TLD) is
    organized in terms of what subdomains are used to place closely
    related but independent domains, e.g. commercial domains in country
    code TLDs (ccTLD) like .uk are placed in the registry-like .co.uk
    subTLD domain.  This information is then used to limit which domains
    an Internet service can set cookies for, strengthening the rules
    already defined by the cookie specifications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-01.txt

---------------------------------------

	Title		: Enhanced validation of domains for HTTP State
                           Management Cookies using DNS
	Author(s)	: Y. Pettersen
	Filename	: draft-pettersen-dns-cookie-validate-01.txt
	Pages		: 13
	Date		: 2006-10-26
	
HTTP State Management Cookies are used for a wide variety of tasks on
    the Internet, from preference handling to user identification.  An
    important privacy and security feature of cookies is that their
    information can only be sent to a servers in a limited namespace, the
    domain.

    The variation of domain structures that are in use by domain name
    registries, especially the country code Top Level Domains (ccTLD)
    namespaces, makes it difficult to determine what is a valid domain,
    e.g. example.co.uk and example.no, which cookies should be permitted
    for, and a registry-like domain (subTLDs) like co.uk where cookies
    should not be permitted.

    This document specifies an imperfect method using DNS name lookups
    for cookie domains to determine if cookies can be permitted for that
    domain, based on the assumption that most subTLD domains will not
    have an IP address assigned to them, while most legitimate services
    that share cookies among multiple servers will have an IP address for
    their domain name to make the user's navigation easier by omitting
    the customary "www" prefix.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pettersen-dns-cookie-validate-01.txt
---------------------------------------

	Title		: HTTP State Management Mechanism v2
	Author(s)	: Y. Pettersen
	Filename	: draft-pettersen-cookie-v2-00.txt
	Pages		: 30
	Date		: 2006-10-18
	

    This document specifies a way to create a stateful session with
    Hypertext Transfer Protocol (HTTP) requests and responses.  It
    describes three headers, Cookie, Cookie2, and Set-Cookie2, which
    carry state information between participating origin servers and user
    agents.  The method described here differs from both Netscape's
    Cookie proposal [Netscape], and [RFC2965], but it can, provided some
    requirements are met, interoperate with HTTP/1.1 user agents that use
    Netscape's method.  (See the HISTORICAL section.)

    This document defines new rules for how cookies can be shared between
    servers within a domain.  These new rules are intended to address
    security and privacy concerns that are difficult to counter for
    clients implementing Netscape's proposed rules or the rules specified
    by RFC 2965.

    This document reflects implementation experience with RFC 2965 and
    obsoletes it.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pettersen-cookie-v2-00.txt

---------------------------------------


-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************
Received on Friday, 27 October 2006 03:28:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:53 GMT