Cookie-Attribute request header proposal

David Eckel <dvdckl@gmail.com> Sat, 03 September 2016 08:17 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7475112B018 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 3 Sep 2016 01:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.468
X-Spam-Level:
X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 DFZIk1QmCBlD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 3 Sep 2016 01:17:50 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2F3127A90 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 3 Sep 2016 01:17:49 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bg64y-00065J-2U for ietf-http-wg-dist@listhub.w3.org; Sat, 03 Sep 2016 08:13:32 +0000
Resent-Message-Id: <E1bg64y-00065J-2U@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1bg64r-00064a-6a for ietf-http-wg@listhub.w3.org; Sat, 03 Sep 2016 08:13:25 +0000
Received: from raoul.w3.org ([128.30.52.128]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1bg64m-0001md-O3 for ietf-http-wg@w3.org; Sat, 03 Sep 2016 08:13:24 +0000
Received: from platy.fdn.fr ([80.67.176.7] helo=[192.168.1.41]) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1bg64m-000AKy-6W for ietf-http-wg@w3.org; Sat, 03 Sep 2016 08:13:20 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="us-ascii"
From: David Eckel <dvdckl@gmail.com>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Thu, 01 Sep 2016 22:09:14 +0000
Content-Transfer-Encoding: quoted-printable
Resent-Date: Sat, 03 Sep 2016 10:13:17 +0200
Resent-To: ietf-http-wg@w3.org
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
Message-Id: <d2bfa27c-b5a9-ac53-d864-5f0e61ad062a@gmail.com>
To: ietf-http-wg@w3.org
X-Mailer: Apple Mail (2.3124)
X-W3C-Hub-Spam-Status: No, score=-2.0
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, HK_RANDOM_FROM=0.998, NML_ADSP_CUSTOM_MED=0.9, RP_MATCHES_RCVD=-1.508, W3C_NW=0.5
X-W3C-Scan-Sig: maggie.w3.org 1bg64m-0001md-O3 29e0f0bcb197965ebc5b31a76c311a7d
X-Original-To: ietf-http-wg@w3.org
Subject: Cookie-Attribute request header proposal
Archived-At: <http://www.w3.org/mid/d2bfa27c-b5a9-ac53-d864-5f0e61ad062a@gmail.com>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32373
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

In https://github.com/httpwg/http-extensions/issues/223 the idea of a Cookie-Attribute request header was suggested as a way to inform HTTP servers if a cookie could be trusted or not, without breaking backwards compatibility.  It would work as follows in the hypothetical request to https://example.com/:

   GET / HTTP/1.1
   Host: example.com
   Cookie: tz=America/Los_Angeles;SESSIONID=a1b2c3
   Cookie-Attribute: ;Secure,HttpOnly,SameSite=Strict

The order of the attributes would match the order of the cookies. In the above example, the server could be confident that the SESSIONID cookie was set over a secure connection and was not vulnerable to being set via an XSS attack. It can also infer that the tz cookie may have been set by an untrusted party, and might choose to ignore it.

To accommodate more security and non-security related use cases, the Cookie-Attribute header could also include all of the other attributes, like Domain, Path, Expires.  Due to header size concerns they probably shouldn't be included by default.  Servers could opt-in to receiving these additional attributes by setting a uniquely named cookie that enumerates desired attributes, like "__Cookie-Attribute=Path,Domain". This could be useful when debugging, deleting cookies, and distinguishing between multiple cookies with the same name.  Example:

   GET /index HTTP/1.1
   Host: www.example.com
   Cookie: analyticsId=1;analyticsId=2;__Cookie-Attribute=Path,Domain
   Cookie-Attribute: Path=/,Domain=www.example.com;Path=/index,Domain=.example.com;Path=/,Domain=www.example.com

Known concerns:
   - Sending a new header and attributes increases the request size (per mnot's suggestion, this could be partially mitigated by abbreviating the header to something like "Cookie-A: ;S,H,SS=S" in the first example)
   - Opt-in security means a long road to adoption
   - Overlaps with Secure flag improvements in https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-cookie-alone.md

Thoughts?

David Eckel