Re: [http-state] HTTP cookie processing wrt "public suffixes"

Zhong Yu <zhong.j.yu@gmail.com> Mon, 18 May 2015 14:44 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2591A909F for <http-state@ietfa.amsl.com>; Mon, 18 May 2015 07:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.3
X-Spam-Level: *
X-Spam-Status: No, score=1.3 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, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXtv6jAdtcg8 for <http-state@ietfa.amsl.com>; Mon, 18 May 2015 07:44:03 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (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 E57161A903F for <http-state@ietf.org>; Mon, 18 May 2015 07:44:02 -0700 (PDT)
Received: by ieczm2 with SMTP id zm2so100486378iec.1 for <http-state@ietf.org>; Mon, 18 May 2015 07:44:02 -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=5NbNjnfMlmavR04nBVkg/0kVsw7+ymI+3tVFSdsQZ9Q=; b=0wZ4tY448vlgUqDUS+TOz54X1oPg7MU540Tl6jieiiVdja8TtpVAR4ka0eku4Hr3ix /xCnjQXJZdUJ4rhmmj7cKHlL1mzxqXHkoUfOLzhTRBGV3jG/T4my4G0dSvUqOMkdi1aF VUSp1hIbImqhbpO7qi9sRgglfXwQi3IwL32QQpyrBAdmrftuZsYzVd8ay8Z+bUIDfzUA u/jOgQe5VnPZ6x7DA24NLkilSML8TCMpjCHcekYpW4Oa54N0JAqYHr1H0NikKQMFAitV Yf2S8o5bCRsLqpNXHL98yVJYan0HeeKeV8cVa6/KFmqYZM+sDZjtHvYkoDDXW9bnTtmI mDoA==
MIME-Version: 1.0
X-Received: by 10.42.43.199 with SMTP id y7mr34950340ice.12.1431960242401; Mon, 18 May 2015 07:44:02 -0700 (PDT)
Received: by 10.64.103.106 with HTTP; Mon, 18 May 2015 07:44:02 -0700 (PDT)
Date: Mon, 18 May 2015 09:44:02 -0500
Message-ID: <CACuKZqGu9vFnQMtkpbG=g3iK6XHKAeOsnsaBxkXYJVqxvzbRRg@mail.gmail.com>
From: Zhong Yu <zhong.j.yu@gmail.com>
To: http-state <http-state@ietf.org>, team@publicsuffix.org
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-state/lzVC9Gm-X6JgzUkw0YVbX2egA2U>
Subject: Re: [http-state] HTTP cookie processing wrt "public suffixes"
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, 18 May 2015 14:44:04 -0000

There is a complication that is neither addressed in the RFC nor in
Jeff's document:

   - it's possible that the parent of a public suffix is not a public
suffix itself.

For example:  compute.amazonAws.com is a public suffix; but its
parent, amazonAws.com, is not a public suffix.

Obviously, we cannot allow `foo.compute.amazonAws.com` to set
cookie.domain=amazonAws.com, even though `amazonAws.com` is not a
public suffix.

To be fair, this situation should not have existed; it's bad enough
that companies spam the public suffix list with no discipline and
consideration; it's unconscionable that they introduce unnecessary
complications like this. /rant

Anyways, how do we handle this situation? The simplest solution is to
declare that all parents of a public suffix are public suffixes too.
However this might break existing deployments where a parent is a
"normal" website.

If we accept the reality that a parent of a public suffix may not be a
public suffix, the cookie domain algorithm needs to be a little more
sophisticated. We want to achieve the following effect:

1.  foo.compute.amazonAws.com cannot set a cookie for
compute.amazonAws.com or higher domains

2. w1.amazonAws.com can set a cookie for amazonAws.com, which affects
w2.amazonAws.com.
    however the cookie must not affect compute.amazonAws.com and its subdomains.

Zhong Yu
bayou.io