


Network Working Group                                       Y. Pettersen
Internet-Draft                                        Opera Software ASA
Updates: RFC 2965                                          June 15, 2009
(if approved)
Intended status: Experimental
Expires: December 17, 2009


 Enhanced validation of domains for HTTP State Management Cookies using
                                  DNS
                 draft-pettersen-dns-cookie-validate-05

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 17, 2009.

Abstract

   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,



Pettersen               Expires December 17, 2009               [Page 1]

Internet-Draft        DNS Cookie domain validation             June 2009


   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.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


































Pettersen               Expires December 17, 2009               [Page 2]

Internet-Draft        DNS Cookie domain validation             June 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  ABNF for the hostname and domain-attribute . . . . . . . . . .  5
   3.  Domain matching summary  . . . . . . . . . . . . . . . . . . .  6
   4.  Problem description  . . . . . . . . . . . . . . . . . . . . .  7
   5.  A DNS based approach . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Foundations  . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Method for DNS validation of cookie domains  . . . . . . .  9
     5.3.  Incorrect results  . . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Non-normative references . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 14


































Pettersen               Expires December 17, 2009               [Page 3]

Internet-Draft        DNS Cookie domain validation             June 2009


1.  Introduction

   HTTP State Management Cookies are used to maintain a state shared
   between several HTTP resources within a domain.  This state can for
   example be a login ID, a shopping cart, or user configurable
   preference settings.

   Presently, two somewhat compatible Cookie formats exist: Netscape's
   original specification [NETSC], which is currently the most widely
   deployed version, and [RFC2965] cookies.  While syntactically
   similar, these definitions specify different response headers due to
   compatibilty issues, but use the same request header, with some
   modifications mandated by [RFC2965].

   Cookies are usually sent by an HTTP server to the client as one or
   more headers in the response to a request, and the client may permit
   the received cookie(s) to be stored locally on the client machine, so
   that they may later be returned to the server attached as a header to
   future requests for HTTP resources within the domain specified by the
   server, for as long as the cookies are valid.  Alternative mechanisms
   for setting cookies are also available through HTML Meta tags and an
   ECMAScript interface.

   To prevent cookies set by one website from interfering with other,
   independent websites or leaking sensitive information to such
   websites, a number of limitations exist for which websites may
   receive cookies set by a given website.

   The primary limitation is the domain attribute of the cookie.  This
   attribute either defines the name of the website that will receive
   the cookie, or the Internet domain name that must be the suffix of
   all servers that will receive the cookie.  The default is that if no
   domain attribute is specified by the server the coookie can only be
   sent to the server that set the cookie.

   The domain mechanism does however have certain limitations,
   limitations that become obvious when cookies are used in the national
   domains outside the generic top level domains (TLDs): ".com", ".net",
   ".org", ".gov", ".mil", ".edu" and ".int".

   The national domains are organized in various ways, some have a flat
   structure, like the one used by the .com domain, while others have
   one or more hierarchical levels that are used to indicate what kind
   of service the domain is used for, e.g. co.uk is used for commercial
   domains in the UK, while ac.uk is used for academic institutions.
   Many national domains are using a hybrid of these two structures.

   These various namespace structures cause problems when a client is



Pettersen               Expires December 17, 2009               [Page 4]

Internet-Draft        DNS Cookie domain validation             June 2009


   going to decide if a cookie sent by a server can be set.  As national
   domain administrators are free to organize, and name, their domain
   name structures as they wish, there are no general rules available to
   tell a client if a given domain is a valid website domain (e.g.
   example.co.uk or example.no), or one of the hierarchical subTLDs
   (like "co.uk").  Permitting a server to set a cookie for "co.uk"
   could compromise the user's privacy and possibly other issues, such
   as interfering with the functionality of other servers.

   [NETSC] did try to deal with the problem by requiring two internal
   dots in the domain attribute (e.g. example.co.uk) when the TLD is not
   one of the specified generic ones.  Unfortunately, this rule was
   never implemented correctly, and if it had been, it would have made
   it impossible to use cookies in the many flat ccTLD domains.

   [RFC2965] took another approach, by only permitting a server to set
   cookies for its immediate parent domain.  While this takes care of
   most of the problem, it still makes it possible for the server
   "example.co.uk" to set a cookie for the entire co.uk domain.  This
   document presents a method that supplements the existing domain
   matching rules from [NETSC] and [RFC2965] by using the DNS protocol
   to decide whether or not to accept the domain specified by the
   server.


2.  ABNF for the hostname and domain-attribute

   NOTE: In this syntax the leading dot of the domain-attribute that is
   required by [NETSC] and [RFC2965] is not included.  Domain names MUST
   be IDNA compliant [RFC3490].  ABNF syntax as defined by [RFC2616]

  hostname = local-server | ip-address | full-hostname
  domain-attribute = full-domain | "local"
  full-hostname = ownername "." full-domain
  full-domain = domainname "." toplevelname
  domainname = namecomponent *( "." namecomponent)
  toplevelname= generic-domain | national-toplevelname; (except "local")

  generic-domain = "com" | "net" | "org" | "gov" | "mil" | "edu" | "int"
  national-toplevelname = flat-national-domainname | hier-nationalname
  hier-nationalname = (1*(subdomain-component ".") national-domainname)
  flat-national-domainname = national-domainname
  national-domainname = <any namecomponent, except those that are
                         part of generic-domain>







Pettersen               Expires December 17, 2009               [Page 5]

Internet-Draft        DNS Cookie domain validation             June 2009


   subdomain-component = namecomponent
   ownername = namecomponent *("." namecomponent)
   local-server = namecomponent
   namecomponent = <[RFC3490] compatible token>
   ip-address = <IP-Literal or IPv4adddress as defined
                 by [RFC3986] sec 3.2.2>


3.  Domain matching summary

   Deciding whether or not to permit a cookie to be set depends on
   matching the hostname of the server setting the cookie with the
   domain-attribute provided by the server.  This domain matching is
   done according to rules laid out in [NETSC] and [RFC2965].

   o  If no domain-attribute is provided by the server the cookie is
      only accepted for the server that set the cookie; it may not be
      sent to any other server.

   o  If the hostname is an IP address, the domain-attribute MUST be an
      exact match of the hostname.

   o  If the hostname is a local-server name, the domain attribute may
      be "local", in which case all local-servers may receive the
      cookie.  Otherwise, if the domain-attribute is an exact match with
      the hostname, it is accepted for the server identified by
      hostname, and only sent to that server.  If there is no match
      between the domain attribute and the hostname, the cookie MUST be
      discarded.

   For all other hostnames and domain-attributes a set of rules exists:

   The primary rule is that the full-domain part of the full-hostname
   MUST match the domain-attribute exactly.

   Second, while [NETSC] does not define any rules for the ownername
   part of a full-hostname, [RFC2965] specifies that it MUST contain
   only a single namecomponent, and a server can therefore only set a
   cookie for its own parent domain, not the grandparent domain or
   higher, as is permitted by [NETSC].

   [NETSC] included as a third rule that all national-toplevelnames must
   be a hier-nationalname.  However, as mentioned above, this rule has
   never been properly implemented by most clients.

   If the cookie's domain-attribute and the host's hostname match
   according to these rules and restrictions, the cookie is accepted and
   will be returned to all servers that are located within the domain-



Pettersen               Expires December 17, 2009               [Page 6]

Internet-Draft        DNS Cookie domain validation             June 2009


   attribute's namespace.


4.  Problem description

   As mentioned above, a national domain namespace can be organized as

   1.  A flat namespace where names are assigned as namecomponent "."
       flat-national-domainname, as is done in the generic domain.

   2.  A hierarchical namespace where names are assigned as
       namecomponent "." hier-national-domainname.

   3.  A combination of both 1 and 2.

   With respect to cookies, the domain-attribute cannot be a name
   classified as a toplevelname domain, as that would permit a server to
   set cookies that can be sent to all servers within the namespace of
   the toplevelname domain, which might result in privacy violations
   such as cross domain tracking of users, or security related problems
   such as improper influence on the function of servers in another
   domain.

   For domains in the generic-domain namespaces it is easy to make this
   distinction as a valid full-domain will always have at least two
   namecomponents, and the rightmost namecomponent (the toplevelname)
   must match one of the generic-domain alternatives.

   Within the national-toplevelname namespace it is not possible to make
   this distiction between a valid full-domain and a national-
   toplevelname solely by examination of the toplevelname, UNLESS a
   detailed list of all names that are part of the hier-nationalname
   namespace is available to the client.

   However, creating a list of all valid hier-nationalnames is an
   immense task.  According to an incomplete list maintained by [GOVCOM]
   at least half of the 250+ national TLDs listed there use a full or
   partially hierarchical namespace organization.  Many of the
   subdomain-components have names based on local naming conventions, as
   well as geographical areas (such as states, provinces, counties, and
   cities).

   While it may be possible for a vendor to assemble such a list,
   assembling it will require massive amounts of time and resources, and
   it will never be complete, and must continually be updated as the
   namespaces are reorganized, or new nations come into existence.

   Asking the user in these cases would become tedious and cause endless



Pettersen               Expires December 17, 2009               [Page 7]

Internet-Draft        DNS Cookie domain validation             June 2009


   irritation for the user.

   A stopgap solution could be to use a list of the most common
   subdomain-component names, but this will leave large areas of the
   namespace unprotected.


5.  A DNS based approach

5.1.  Foundations

   An HTTP client that understands cookies will, as part of its normal
   operation, have access to the DNS name resolution system, which it
   uses to convert a hostname to a network IP address.

   The proposed method uses this DNS system to resolve (or attempt to
   resolve) the domain-attribute specified by the sending server.  If
   the domain-attribute resolves to a valid IP address, we accept the
   domain-attribute as valid; if it does not resolve to a valid IP
   address, we assume that the domain-attribute is not a valid full-
   domain.

   This method is based on the following assumptions:

   1.  It is unlikely that a national-toplevelname will be registered
       with an IP address.  Such domains do however exist.

   2.  It is far more likely, although not certain, that full-domain
       will be registered with an IP address as an alias for www.full-
       domain.  Many services have dispensed with the "www" part of
       their hostname in URIs and are using full-domain as the only
       active name of their service.

   3.  It is also likely that a service that will need to share cookies
       between multiple servers will have so many visitors that the
       administrators will set up full-domain as a valid host to make
       access easier for their visitors, e.g. in case they forget to use
       the www form of the name when entering the site's URL into their
       client.

   Based on this, it should be possible to perform a DNS lookup for the
   domain-attribute's name, and based on the result decide whether or
   not to accept the cookie.  If the DNS lookup succeeds and a valid IP
   address is retrieved, the cookie can be accepted for the given
   domain; if it fails, the cookie can either be discarded or the client
   can remove the domain attribute and continue as if that attribute had
   never been received, and only send the cookie to the server that sent
   the cookie.



Pettersen               Expires December 17, 2009               [Page 8]

Internet-Draft        DNS Cookie domain validation             June 2009


   The primary drawback of this solution is the fact that some sites
   will require domainwide cookies to function properly, but haven't
   defined an IP address for the domain.  In such cases the client may
   encounter problems that can only be solved by user intervention, such
   as by defining override filters or asking the service to define an IP
   address for the domain.

   In some cases a client does not have a DNS service available that
   will properly resolve the domain name, even if it actually is
   registered with an IP address.  This is usually the case when the
   client is located on an isolated network whose only access to the
   outside network is through an HTTP proxy.  In such cases, when the
   client would use a proxy to retrieve resources, the client can use an
   alternative validation method by performing an HTTP HEAD request
   instead of a DNS request to the full-domain in order to determine its
   status as a valid domain.

5.2.  Method for DNS validation of cookie domains

   After the normal domain rules specified by the relevant specification
   (as discussed in Section 3) have been applied, the proposed method
   works as follows:

   When to test:

   o  The domain-attribute and hostname syntax rules defined in the
      above rules must be obeyed.

   o  A domain-attribute that matches the hostname is accepted without
      testing.

   o  The rules for local-server names and IP-addresses are enforced as
      above, and if the cookie is acceptable by those rules the cookie
      can be accepted, otherwise it must be discarded.

   o  It is not necessary to apply the test to domain-attributes that
      are in the namespace of the generic-domains.

   o  While it is recommended that all domains that are left are tested,
      as a minimum the domain MUST be tested if

      A.  The domainname part of the full-domainname and the
          toplevelname each have only one namecomponent (that is, it is
          a flat-national-domainname), or

      B.  The ownername has at least one internal dot (i.e. there are
          multiple namecomponents in the ownername, and thus full-
          domainname is not the host's parent domain)



Pettersen               Expires December 17, 2009               [Page 9]

Internet-Draft        DNS Cookie domain validation             June 2009


   How to test the domain attribute:

   o  Testing is done by performing a DNS lookup for the domain-
      attribute.  If the lookup succeeds, and returns a valid IP
      address, the cookie is accepted for the given domain.  If, on the
      other hand, the lookup fails, or returns an invalid address, the
      cookie is either rejected or the domain-attribute is removed from
      the cookie, and processing continues as if the domain attribute
      had never been specified - the cookie is thus only accepted for
      the server sending the cookie.

   o  If general DNS lookup is not available (e.g because the client is
      located in an isolated network and has to work through a proxy/
      gateway that is the sole access point to the Internet) the client
      should send HTTP HEAD requests for one or more of the following
      URLs:

      1.  Only if the original URL was an HTTPS URL:
          https://domain:port/

      2.  Only if the original URL was an HTTP URL: http://domain:port/

      3.  Only if the original URL was an HTTPS URL: https://domain/

      4.  http://domain:port/

   The port variations should only be used if a non-standard port is
   used.  If one of these requests results in a 200- or 300-series
   response code, or a 401 response code (407 proxy authentication
   response codes are handled as they normally would have been) the
   lookup is considered successful, and the cookie can be accepted for
   the specified domain-attribute.  If none of the accepted response
   codes are returned for any of the requests, the lookup is considered
   to have failed, and the domain-attribute is removed from the cookie
   parameters and the processing continues as mentioned in the previous
   step.

   A user agent should not repeat this test for an alleged domain more
   than once every 24 hours, but it need not keep the information about
   failed and successful lookups between individual runs of the user
   agent.

5.3.  Incorrect results

   There are primarily two types of incorrect results that can be
   encountered with this method:





Pettersen               Expires December 17, 2009              [Page 10]

Internet-Draft        DNS Cookie domain validation             June 2009


   1.  The domain-attribute is a valid full-domain, i.e. it is not a
       national-toplevelname, but fails the test because no IP address
       has been registered for the domain-attribute.  In many cases this
       will not cause any problem, but when it does, the owner of the
       domain can easily fix this by adding an IP address for the full-
       domain in his or her DNS database, usually the same IP-address as
       the main server of the domain.  This is a common practice among
       many domain owners.

   2.  The domain-attribute is actually a hier-nationalname, but passes
       the test because an IP address has been defined for the domain.
       This possibility may occur because a network provider or TLD
       registry wants to provide user friendly "unknown host" messages,
       or a directory service.  This could be a serious problem for the
       visitors and website owners in the top level domain, and can only
       be solved by removing the DNS IP-address entry for the domain.

   A third incorrect result also exists, where the full-domain is shared
   between many different website owners who do not want to set up, or
   cannot afford, a website with a full-domain owned by the website
   owner with all the associated administrative problems.

   The method described in this document is not able to handle the
   second or third possibilities.  Handling these cases would require
   that the domain owner is able to specify a policy for which servers
   or subdomains within the domain may set which kind of cookies.  Such
   a policy could limit which domains or paths a given server can set
   cookies for.  The specification of this is outside the scope of this
   document.


6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


7.  Security Considerations

   The methods discussed in this document rely on the DNS system for
   information, and are vulnerable both to misleading information
   entered into the DNS system by well-meaning service providers, and to
   various forms of DNS related attacks, like DNS poisoning.

   A DNS resolution that incorrectly permits a cookie to be set, could
   result in a privacy problem for the user, or a security problem on



Pettersen               Expires December 17, 2009              [Page 11]

Internet-Draft        DNS Cookie domain validation             June 2009


   servers receiving the incorrectly set cookie.  This situation is,
   however, no worse than it would have been without the DNS validation
   routine.

   The DNS lookups may reveal to attackers analyzing traffic data that
   the client may have received a cookie from a server in domain, and
   what the domain is, but will reveal no further information about the
   cookie, and the revealed information is ambiguous.


8.  References

8.1.  Normative References

   [NETSC]    "Persistent Client State HTTP Cookies",
              <http://wp.netscape.com/newsref/std/cookie_spec.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2965, October 2000.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

8.2.  Non-normative references

   [GOVCOM]   "http://www.govcom.org/", 2005.













Pettersen               Expires December 17, 2009              [Page 12]

Internet-Draft        DNS Cookie domain validation             June 2009


Author's Address

   Yngve N. Pettersen
   Opera Software ASA
   Waldemar Thranes gate 98
   N-0175 OSLO,
   Norway

   Email: yngve@opera.com










































Pettersen               Expires December 17, 2009              [Page 13]

Internet-Draft        DNS Cookie domain validation             June 2009


Full Copyright Statement

   Copyright (C) The IETF Trust (2009).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Pettersen               Expires December 17, 2009              [Page 14]


