<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-pettersen-subtld-structure-05"
     ipr="full3978" updates="RFC 2965">
  <front>
    <title abbrev="SubTLD Structure Protocol">The TLD Subdomain Structure
    Protocol and its use for Cookie domain validation</title>

    <author fullname="Yngve N. Pettersen" initials="Y." surname="Pettersen">
      <organization>Opera Software ASA</organization>

      <address>
        <postal>
          <street>Waldemar Thranes gate 98</street>

          <city>N-0175 OSLO</city>

          <region></region>

          <code></code>

          <country>Norway</country>
        </postal>

        <email>yngve@opera.com</email>
      </address>
    </author>

    <date day="14" month="June" year="2009" />

    <abstract>
      <t>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 .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.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Domain Name System <xref target="RFC1034"></xref> used to name
      Internet hosts allows a wide range of hierarchical names to be used to
      indicate what a given host is, some implemented by the owners of a
      domain, such as creating subdomains for certain tasks or functions,
      others, called subTLDs or registry-like domains, are created by the Top
      Level Domain registry owner to indicate what kind of service the domain
      is, e.g. commercial, educational, government or geographic location,
      e.g. city or state.</t>

      <t>While this system makes it relatively easy for TLD administrators to
      organize online services, and for the user to locate and recognize
      relevant services, this flexibility causes various security and privacy
      related problems when services located at different hosts are allowed to
      share data through functionality administrated by the client, e.g. HTTP
      state management cookies <xref target="RFC2965"></xref> <xref
      target="NETSC"></xref>. Most information sharing mechanisms make the
      process of sharing easy, perhaps too easy, since in many cases there is
      no mechanism to ensure that the servers receiving the information really
      want it, and it is often difficult to determine the source of the
      information being shared. To some extent <xref target="RFC2965"></xref>
      addresses some of these concerns for cookies, in that clients that
      supports <xref target="RFC2965"></xref> style cookies sends the target
      domain for the cookie along with the cookie so that the recipient can
      verify that the cookie has the correct domain. Unfortunately, <xref
      target="RFC2965"></xref> is not widely deployed in clients, or on
      servers. The recipient(s) can make inappropriate information sharing
      more difficult by requiring the information to contain data identifying
      the source and assuring the integrity of the data, e.g. by use of
      cryptographic technologies. These techniques tend, however, to be
      computationally costly. There are two problem areas:<list
          style="symbols">
          <t>Incorrect sharing of information between non-associated services
          e.g. example1.com and example2.com or example1.co.uk and
          example2.co.uk. That is, the information may be distributed to all
          services within a given Top Level Domain.</t>

          <t>Undesirable information sharing within a single service. This is,
          in particular, a problem for services that sell hosting services to
          many different customers, such as webhotels, where the service
          itself has little or no control of the customers actions.</t>
        </list>While both these problems are in some ways similar, they call
      for different solutions. This specification will only propose a solution
      for the first problem area. The second problem area must be handled
      separately. This specification will first define a TLS Subdomain
      Structure Protocol that can be used to discover the actual structure of
      a Top Level Domain e.g. that the TLD have several subTLDs co.tld,
      ac.tld, org.tld, then it will show how this information can be used to
      determine when information sharing through cookies is not desirable.</t>
    </section>

    <section anchor="SSPsection" title="The TLD Subdomain Structure Protocol">
      <t>The TLD Subdomain Structure Protocol is an HTTP service, managed by
      either the application vendor, the TLD owners, or some other trusted
      organization, and located at a URI location that, when queried, returns
      information about a TLD's domain structure. The client can then use this
      information to decide what actions are permitted for the protocol data
      the client is processing. Procedure for use: <list style="symbols">
          <t>The client retrieves the domain list for the Top Level Domain
          "tld" from the vendor specified URI
          https://tld-structure.example.com/tld/domainlist . Multiple
          alternative URI for fallback procedure may be specified</t>

          <t>The Content-Type of the returned list MUST be
          application/subdomain-structure.</t>

          <t>The retrieved specification SHOULD be cached by the client for at
          least 30 days</t>

          <t>The TLD owner SHOULD update the list at least 90 days before a
          new sub-domain becomes active.</t>

          <t>If no specification can be retrieved the user agent MAY fall back
          to alternative methods, depending on the profile.</t>
        </list></t>

      <section title="Securing the domain information">
        <t>Individuals with malicious intent may wish to modify the domain
        list served by the service location to either classify a domain
        incorrectly as a subTLD or to hide a subTLD's classification. Beside
        obviously securing the hosting locations, this also means that the
        content served will have to be secured.</t>

        <t><list style="numbers">
            <t>Digitally sign the specification, using one of the available
            message signature methods, e.g. S/MIME <xref
            target="RFC2311"></xref>. This will secure the content during
            storage both at the client and the server, as well as during
            transit. The drawback is that the client must implement decoding
            and verification of the message format which it may not already
            support, which may be problematic for clients having limited
            resources.</t>

            <t>Using an encrypted connection, such as HTTP over TLS <xref
            target="RFC2818"></xref>, which is supported by many clients
            already. Unfortunately, this method does not protect the content
            when stored by the client.</t>

            <t>Use XML Signatures <xref target="RFC3275"></xref> to create a
            signature over the specification. This method is currently not
            defined.</t>
          </list>This specification recommends using HTTP over TLS, and the
        client MUST use the non-anonymous cipher suites, to secure the
        transport of the specification. The client MUST ensure that the
        hostname in the certificate matches the hostname used in the
        request.</t>
      </section>

      <section title="Domainlist format">
        <t>The domain list file can contain a list of subdomains that are
        considered top level domains, as well as a special list of names that
        are not top level domains. None of the domain lists need specify the
        TLD name, since that is implicit from the request URI. The domain
        names listed MUST be encoded in punycode, according to <xref
        target="RFC3490"></xref>.</t>

        <t></t>

        <section anchor="domainlinst_schema" title="Domainlist schema">
          <t>The domain list is an XML file that follows the following
          schema</t>

          <figure>
            <artwork><![CDATA[
    default namespace = "http://xmlns.opera.com/tlds"

    start =
        element tld {
          attribute levels { xsd:nonNegativeInteger | "all"},
          attribute name { xsd:NCName },
          (domain | registry)*
        }
    registry =
        element registry {
          attribute levels { xsd:nonNegativeInteger },
          attribute name { xsd:NCName },
          attribute all { string "true" | string "false" },
          (domain | registry)*
        }
    domain =
        element domain {
          attribute name { xsd:NCName }
        }]]></artwork>
          </figure>

          <t></t>

          <t>The domainlist file contains a single &lt;tld&gt; block, which
          may contain multiple registry and domain blocks, and a registry
          block may also contain multiple registry and domain blocks.</t>

          <t>Both domain and registry tags MUST contain a name attribute
          identifying the domain or registry. The tld block MAY have a name
          attribute, but this name MUST be ignored by clients, which must
          instead use the name of the TLD used to request the file.</t>

          <t>All names MUST be punycode encoded to make it possible for
          clients not supporting IDNA to use the document.</t>

          <t>The tld and registry blocks MAY contain an attribute, levels,
          specifying how many levels below the current domain are
          registry-like. The default is none, meaning that the default inside
          the current domain level is that labels are ordinary domains and not
          registry-like. If the levels attribute is 1 (one) it means that by
          default all next-level labels within the registry/tld are registry
          like and not normal domains. If the levels attribute is the
          case-insesitive token "all", then all subdomains domains below the
          current domain are registry-like.</t>

          <t>A registry block with attribute "all" set to "true" means that
          all domains in that registry (at the current level) are registries,
          unless there are overrides, and may contain additional registry or
          domain blocks, which then apply to domains x.example.tld, if the all
          block is inside the "example" block of "tld". This allows
          specification of wildcard structures, where the structure for lower
          domains are similar for all domains.</t>

          <t>Implementations MUST ignore attributes and syntax they do not
          recognize.</t>
        </section>

        <section title="Domainlist interpretation">
          <t>For each new registry or domain block within the tld or registry
          the effective domain name the block applies to is the name of the
          block prepended to the ".name" of the effective domain name of the
          containing block.</t>

          <t>For the tld block the effective domain name is the name of the
          TLD the client is evaluating, and for the registry block named
          "example" the effective name becomes example.tld.</t>

          <figure>
            <artwork><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<tld xmlns="http://xmlns.opera.com/tlds" name="tld" levels="1" >
    <registry name="co" levels="0">
      <registry name="state" />
    </registry>
    <registry name="province">
      <registry all level="1">

        <domain name="school" />
      </registry>
    </registry>
    <registry name="example" levels="1" />
    <domain name="parliament" />
</tld>]]></artwork>
          </figure>

          <t>In the above example, the specification is for the TLD "tld". By
          default any second level domain "x.tld" is a registry-like domain,
          although parliament.tld is not a registry-like domain</t>

          <t>In the example TLD, however, the co.tld registry has a sub
          registry "state.co.tld", while all other domains in the co.tld
          domains are ordinary domains.</t>

          <t>Additionally all school.domain.province.tld domains for all
          "domain" lablels, and that any other domain under
          domain.province.tld are registry-like.</t>

          <t>Also, the registry example.tld has defined all domains
          y.example.tld as registry-like, with no exceptions.s</t>
        </section>
      </section>
    </section>

    <section title="A TLD Subdomain Structure Protocol profile for HTTP Cookies">
      <t>HTTP State management cookies is one area where it is important, both
      for security and privacy reasons, to ensure that unauthorized services
      cannot set cookies for another service. Inappropriate cookies can affect
      the functionality of a service, but may also be used to track the users
      across services in an undesirable fashion. Neither the original Netscape
      cookie specification <xref target="NETSC"></xref> nor <xref
      target="RFC2965"></xref> are adequate in many cases.</t>

      <t>The [NETSC] rules require only that the target domain must have one
      internal dot (e.g. example.com) if the TLD belong to a list of generic
      TLDs (gTLD), while for all TLDS the domain must contain two internal
      dots (e.g. example.co.uk). The latter rule was never properly
      implemented, in particular due to the many flat ccTLD domain structures
      that are in use.</t>

      <t><xref target="RFC2965"></xref> set the requirement that cookies can
      only be set for the server's parent domain.</t>

      <t>Unfortunately, both policies still leave open the possibility of
      setting cookies for a subTLD by setting the cookie from a host name
      example.subtld.tld to the domain subtld.tld, which is by itself legal,
      but not desirable because that means that the cookie can be sent to
      numerous websites either revealing sensitive information, or interfering
      with those other websites without authroization. As can be seen, these
      rules do not work satisfactorily, especially when applied to ccTLDs,
      which may have a flat domain structure similar to the one used by the
      generic .com TLD, a hierarchical subTLD structure like the one used by
      the .uk ccTLD (e.g. .co.uk), or a combination of both. But there are
      also gTLDs, such as .name, for which cookies should not be allowed for
      the second level domains, as these are generally family names shared
      between many different users, not service names. A partially effective
      method for distinguishing servicenames from subTLDs by using DNS has
      been defined in <xref target="DNSCOOKIE"></xref>. However this method is
      not immune to TLD regsitries that uses subTLDs as directories, or to
      services that does not define an IP address for the domainname. Using
      the TLD Subdomain Structure Protcol to retrieve a list of all subTLDs in
      a given TLD will solve both those problems.</t>

      <section title="Procedure for using the TLD Subdomain Structure Protcol for cookies">
        <t>When receiving a cookie the client must first perform all the
        checks required by the relevant specification. Upon completion of
        these checks the client then performs the following additional
        verification checks if the cookie is being set for the server's
        parent, grand-parent domain (or higher):<list style="numbers">
            <t>If the domain structure of the TLD is not known already, or the
            structure information has expired, the client should retrieve or
            validate the structure specification from the server hosting the
            specification, according to <xref target="SSPsection"></xref>. If
            retrieval is unsuccessful, and no copy of the specification is
            known, the client MAY use alternative methods to decide the
            domain's status, e.g. those described in [DNSCOOKIE], or other
            heuristics. Evaluate the specification as specified in section 2.
            If the target domain is part of the subTLD structure the cookie
            MUST be discarded.</t>

            <t>If the target domain is not a subTLD, the cookie is
            accepted.</t>
          </list></t>
      </section>

      <section title="Unverifiable transactions">
        <t>Use of HTTP Cookies, combined with HTTP requests to resources that
        are located in domains other than the one the user actually wants to
        visit, have caused widespread privacy concerns. The reason is that
        multiple websites can link to the same independent website, e.g. an
        advertiser, who may then use cookies to build a profile of the
        visitor, that can be used to select advertisements that are of
        interest to the user.</t>

        <t><xref target="RFC2965"></xref> specified that if the name of the
        host of an included resource does not domain match the domain reach
        (defined as the parent domain of the host) of the URL of the document
        the user started loading, loading the resource is considered an
        unverifiable transcation, and in such third party transactions cookies
        should not be sent or accepted. The latter point is not widely
        implemented, except when selected by especially interested users. This
        means that server1.example.com and server2.example.com can share
        cookies, and either can be referenced automatically (e.g. by including
        an image) by the other without being considered an unverifiable
        transaction, while requests to server3.example2.com would be
        considered an unverifiable transaction. However, like the normal
        domain matching rule for cookies, this rule opens up some holes. If
        the host example.co.uk requests a resource from
        server4.example3.co.uk, the request to example3.co.uk server would not
        be considered an unverifiable transaction because example.co.uk's
        reach is co.uk, which domain matches server4.example3.co.uk, a
        conclusion which is obviously, to a human with some knowlegde of the
        .uk domain structure, incorrect.</t>

        <t>To avoid such misclassifications clients SHOULD apply the procedure
        specified in 3.1 for the reach domain used to decide if a request is
        an unverifiable, and if the reach domain is a subTLD, the reach of the
        original host must be changed to become the same as the name of the
        host itself, and requests that do not domain match the original host's
        name must be considered unverifiable transactions. That is, the reach
        for example.co.uk becomes example.co.uk, not co.uk, and example3.co.uk
        will therefore not domain match the resulting reach.</t>
      </section>
    </section>

    <section title="Examples">
      <t>The following examples demonstrates how the TLD Subdomain Structure
      Protcol can be used to decide cookie domain permissions.</t>

      <section title="Example 1">
        <figure>
          <artwork><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<tld xmlns="http://xmlns.opera.com/tlds" name="tld" levels="1" >
    <domain name="example" />
</tld>

]]></artwork>
        </figure>

        <t>This specification means that all names at the top level are
        subTLDs, except "example.tld" for which cookies are allowed. Cookies
        are also implicitly allowed for any y.x.tld domains.</t>
      </section>

      <section title="Example 2">
        <figure>
          <artwork><![CDATA[<?xml version="1.0" encoding="UTF-8"? >
<tld xmlns="http://xmlns.opera.com/tlds" name="tld" >
    <registry name="example1" levels="1" />
    <registry name="example2" levels="1" />
</tld>

]]></artwork>
        </figure>

        <t>This specification means that example1.tld and example2.tld and any
        domains foo.example1.tld and bar.example2.tld are registry-like
        domains for which cookies are not allowed, for any other domains
        cookies are allowed.</t>
      </section>

      <section title="Example 3">
        <figure>
          <artwork><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<tld xmlns="http://xmlns.opera.com/tlds" name="tld" >
    <registry name="example1" levels="1" />
    <registry name="example2" levels="1" >
       <domain name="example3" />
    </registry>
</tld>

]]></artwork>
        </figure>

        <t>This example has the same meaning as Example 2, but with the
        exception that the domain example3.example2.tld is a regular domain
        for which cookies are allowed.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This specification also requires that responses are served with a
      specific media type. Below is the registration information for this
      media type.</t>

      <section title="Registration of the application/subdomain-structure Media Type">
        <t>Type name : application</t>

        <t>Subtype name: subdomain-structure</t>

        <t>Required parameters: none</t>

        <t>Optional parameters: none</t>

        <t>Encoding considerations: The content of this media type is always
        transmitted in binary form.</t>

        <t>Security considerations: See <xref target="Security"></xref></t>

        <t>Interoperability considerations: none</t>

        <t>Published specification: This document</t>

        <t>Additional information:</t>

        <t>Magic number(s): none</t>

        <t>File extension(s):</t>

        <t>Macintosh file type code(s):</t>

        <t>Person &amp; email address to contact for further information:
        Yngve N. Pettersen</t>

        <t>Email: yngve@opera.com</t>

        <t>Intended usage: common</t>

        <t>Restrictions on usage: none</t>

        <t>Author/Change controller: Yngve N. Pettersen</t>

        <t>Email: yngve@opera.com</t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Retrieval of the specifications are vulnerable to denial of service
      attacks or loss of network connection. Hosting the specifications at a
      single location can increase this vulnerability, although the exposure
      can be reduced by using mirrors with the same name, but hosted at
      different network locations. This protocol is as vulnerable to DNS
      security problems as any other <xref target="RFC2616"></xref> HTTP based
      service. Requiring the specifications to be digitally signed or
      transmitted over a authenticated TLS connection reduces this
      vulnerabity.</t>

      <t>Section 3 of this document describe using the domain list defined in
      section 2 as a method of increasing security. The effectiveness of the
      domain list for this purpose, and the resulting security for the client
      depend both on the integrity of the list, and its correctness. The
      integrity of the list depends on how securely it is stored at the
      server, and how securely it is transmitted. This specification
      recommends downloading the domain list using HTTP over TLS, which makes
      the transmission as secure as the message authentication mechanism used
      (encryption is not required), and the servers should be configured to
      use the strongest available key lengths and authentication mechansims.
      An alternative approach would be to digitally sign the files.</t>

      <t>The correctness of the list depends on how well the TLD registry
      defined it. A list that does not include some subTLDs may expose the
      client to potential privacy and security problems, but not any worse
      than the situation would be without this protocol and profile, while a
      subdomain incorrectly classified as a subTLD can lead to denial of
      service for the affected services. Both of the problems can be prevented
      by careful construction and auditing of the lists, both by the TLD
      registry, and by interested thirdparties.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Anne van Kesteren assisted with defining the XML format in <xref
      target="domainlinst_schema"></xref>.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="NETSC"
                 target="http://wp.netscape.com/newsref/std/cookie_spec.html">
        <front>
          <title>Persistent Client State HTTP Cookies</title>
        </front>
      </reference>

      <?rfc include='reference.RFC.2965'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.3275'?>

      <?rfc include='reference.RFC.2616'?>

      <?rfc include='reference.RFC.3490'?>

      <?rfc include='reference.RFC.1034'?>

      <?rfc include='reference.RFC.2818'?>

      <?rfc include='reference.RFC.2311'?>
    </references>

    <references title="Non-normative references">
      <reference anchor="DNSCOOKIE"
                 target="draft-pettersen-dns-cookie-validate-05.txt">
        <front>
          <title>Enhanced validation of domains for HTTP State Management
          Cookies using DNS. Work in progress.</title>

          <author fullname="Yngve N. Pettersen" initials="Y"
                  surname="Pettersen">
            <organization></organization>
          </author>

          <date day="3" month="November" year="2008" />
        </front>
      </reference>

      <reference anchor="PUBSUFFIX" target="http://publicsuffix.org/">
        <front>
          <title>The Homepage of the Public Suffix List, a list of
          registry-like domains (subTLDs) gathered by volunteers.</title>

          <author>
            <organization></organization>
          </author>

          <date year="" />
        </front>
      </reference>
    </references>

    <section title="Collection of information for the TLD structure specification">
      <t>This document does not define how the information encoded in the TLD
      Structure Specification is gathered.</t>

      <t>There are several methods available for collecting the information
      encoded in the TLD Structure Specification, the two main ones being:</t>

      <t><list>
          <t>Data provided by the TLD registry owner through a machine
          readable repository at wellknown locations.</t>

          <t>Data gathered by one or more application vendors based on
          publicly available information, such as the Mozilla Project's Public
          Suffix <xref target="PUBSUFFIX"></xref> List.</t>
        </list></t>

      <t></t>
    </section>

    <section title="Alternative solutions">
      <t>A possible alternative to the format specified in <xref
      target="SSPsection"></xref>, encoding the information directly in the
      DNS records for the registry -like domain, using a DNS extensions.</t>

      <t>Accessing this type of information require that the client or its
      environment is able to directly access the DNS network. In many
      environments, e.g. firewalled systems. Not all runtime environments can
      provide this information, which may lead to a DNS client embedded
      directly in the client.</t>

      <t>For some applications it may be necessary, due to system limitations,
      to access this information through an online Web Service in order to
      provide the necessary information for each hostname or domain visited. A
      Web service may, however, introduce unnecessary privacy problems, as
      well as delays each time a new domain is tested.</t>
    </section>

    <section title="Open issues">
      <t><list style="symbols">
          <t>Download location URI for the original domain lists</t>

          <t>Should Digital signatures be used on the files, instead of using
          TLS?</t>
        </list></t>
    </section>
  </back>
</rfc>