[http-state] Browser Behaviors on Cookie Domain and Public Suffix

Zhong Yu <zhong.j.yu@gmail.com> Mon, 25 May 2015 01:42 UTC

Return-Path: <zhong.j.yu@gmail.com>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 86EEE1A8915 for <http-state@ietfa.amsl.com>; Sun, 24 May 2015 18:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.301
X-Spam-Level: *
X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1yUmjY22ES7M for <http-state@ietfa.amsl.com>; Sun, 24 May 2015 18:42:27 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F8D1A88A4 for <http-state@ietf.org>; Sun, 24 May 2015 18:42:27 -0700 (PDT)
Received: by igbsb11 with SMTP id sb11so24552493igb.0 for <http-state@ietf.org>; Sun, 24 May 2015 18:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EREfKgQ7K9Oz0zlxNJWoREVzTQgSUBDUwWB+Efzgsfo=; b=R2rL2+6Nt8B2du8bMv0MPPDSZWXDqdbffCZPAA+rzjxGNoGJKTM+lwvdG3hSpp9b6v tSODtENsZw85YLyw8NFV+AdvQMSLMUBcuDqxnxx0hf8aPcPF1tJTR89RjznVNVo2rrge K5FJJdr0Eq9i1WKfPceu/gkxCL7fsPqoCMa/hWs24gkO3LtCuEbW+i6OzPH5pujb0cAv aqAiYvwTX0dSdJh32FicaBvXebLXH7VD4It9mzdvjpQTXVXO2Wfjf/wlhM4b49z5oAiM FVtcU78/fYAQyQhpJ2NnhSyhN492dr37AiVIXde+zzzX9J1jSC2vO2bUYFhrFBx/u0QO uxww==
MIME-Version: 1.0
X-Received: by with SMTP id kx12mr21286043icc.51.1432518146545; Sun, 24 May 2015 18:42:26 -0700 (PDT)
Received: by with HTTP; Sun, 24 May 2015 18:42:26 -0700 (PDT)
Date: Sun, 24 May 2015 20:42:26 -0500
Message-ID: <CACuKZqF_i9vSBeX54n9QV4tJhOgqiUjBWL4oVfv66WjXsWihUg@mail.gmail.com>
From: Zhong Yu <zhong.j.yu@gmail.com>
To: http-state <http-state@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c2ce72425fb10516de1fea
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-state/TPAIg769WRpZsQVkKOCFpQNqFmE>
Subject: [http-state] Browser Behaviors on Cookie Domain and Public Suffix
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state/>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2015 01:42:29 -0000

This is a survey of how browsers handle cookie domains with regard to
public suffixs.

5 major browsers are tested: Chrome/Opera, IE, Firefox, Safari; latest
versions on Windows 7. Note that Opera behaves exactly like Chrome in all
tests, so it won't be mentioned again.


First, some references:

    If ... the [cookie] domain-attribute is a public suffix ... ignore the
cookie entirely

    A "public suffix" is one under which Internet users can (or
historically could)
    directly register names.

    The list of public suffixes:


>From these specs, there's an obvious complication - what if a public suffix
has a parent that's not a public suffix?

As an example, <compute.amazonaws.com> is a public suffix, but <
amazonaws.com> is not.

# Firefox/Chrome: <s1.amazonaws.com> can set a cookie for <amazonaws.com>;
the cookie is applicable to <amazonaws.com>, <s2.amazonaws.com>, etc, but
not to <compute.amazonaws.com> and its child domains.

# Safari: nobody can set a cookie for <amazonaws.com>; the domain is
probably treated as a public suffix.

# IE: IE apparently doesn't recognize <compute.amazonaws.com> as a public
suffix; it's treated as a normal domain. IE doesn't even recognize
Microsoft's own public suffixes like <azurewebsites.net>. I'm unable to
find domains to conduct this particular teston IE.


One one hand, Firefox/Chrome conforms to rfc6265#5.3 by accepting cookie
domain <amazonaws.com> which is not a public suffix; on the other hand,
Firefox/Chrome must violate rfc6265#5.4 so that the cookie is not delivered
to public suffix <compute.amazonaws.com> and its child domains.

The behavior of Firefox/Chrome is reasonable and defensible, but it's quite
complicated, and the benefit is dubious:
  - only a few companies could benefit from it;
  - they probably do not need to share client state among sites like <s1/
  - if they do need to share client state, they have enough resources to
accomplish it through other methods
  - they cannot reliably share client state through cookie domain anyway,
because of Safari.
  - Firefox/Chrome fails to demonstrate the same behavior when wildcard
rules are involved, see below.


The public suffix list contains wildcard rules like <*.nom.br>. It means
that any <foo.nom.br> is a public suffix, but <nom.br> is not ( the public
cannot directly register names under <nom.br> ).

Semantically we would expect that the wildcard rule is equivalent to the
expansion of all child domains - <a.nom.br>, <aa.nom.br> .... And we would
expect that a browser handles <foo.nom.br>/<nom.br> the same way it handles
<compute.amazonaws.com>/<amazonaws.com>. Unfortunately that's not the case.

# Firefox/Chrome/Safari: both <foo.nom.br> and <nom.br> are treated as
public suffixes; nobody can set a cookie for <nom.br>

# IE: IE apparently misunderstands wildcard rules; <nom.br> is treated as
public suffix, but <foo.nom.br> is treated as not - <s1.foo.nom.br> can set
a cookie for <foo.nom.br> that's applicable to <s2.foo.nom.br>


All TLDs are treated by all browsers as public suffixes w.r.t. cookie
domain, with 1 exception. The following TLDs are tested:

    com  jobs  bd  il
    test   example   invalid   local   localhost   arpa

The only exception is <localhost> on Safari - <s1.localhost> can set a
cookie domain <localhost> that's applicable to <s2.localhost>

Note that <bd> and <il> are not public suffixes per se - they appear in the
public suffix list only as <*.bd> and <*.il>.


Another detail in rfc6265#5.3 - if both cookie domain and request host are
the same public suffix, accept the cookie, but ignore the cookie domain.

Firefox is the only browser that implements it - if a public suffix site
<foo> sets a cookie with domain <foo>, the cookie is accepted with domain
erased; the cookie is applicable to only <foo>, not to any other sites.
"foo" could be "test/faketld/com/uk/co.uk/foo.nom.br/compute.amazonaws.com"

On other browsers, such a cookie is simply discarded, if its domain is
considered a public suffix.

The benefit of this feature of rfc/firefox is dubious
  - this feature intends to tolerate a programming mistake that sets a
cookie domain where it shouldn't. we do not need to exercise such tolerance
on public suffix operators.
  - it's unlikely that any operator of a public suffix needs this feature
  - this feature cannot be relied upon anyway, since only Firefox does it.


Zhong Yu