Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06

Martin Thomson <mt@lowentropy.net> Tue, 08 September 2020 02:02 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 BE63D3A0E6F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Sep 2020 19:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level:
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Ur1HxrDM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A9IU/Vsl
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 7R7YOp0AMhUD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 7 Sep 2020 19:02:43 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F333A0E64 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 7 Sep 2020 19:02:42 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kFSvc-0001iP-Ca for ietf-http-wg-dist@listhub.w3.org; Tue, 08 Sep 2020 02:00:12 +0000
Resent-Date: Tue, 08 Sep 2020 02:00:12 +0000
Resent-Message-Id: <E1kFSvc-0001iP-Ca@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mt@lowentropy.net>) id 1kFSvb-0001he-28 for ietf-http-wg@listhub.w3.org; Tue, 08 Sep 2020 02:00:11 +0000
Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mt@lowentropy.net>) id 1kFSvY-0003Ud-Og for ietf-http-wg@w3.org; Tue, 08 Sep 2020 02:00:10 +0000
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 86CC5C18 for <ietf-http-wg@w3.org>; Mon, 7 Sep 2020 21:59:55 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Mon, 07 Sep 2020 21:59:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=T+221RWsxP4WVCW2L7ITMP0NkMIunSG +FjtcOkRWMEg=; b=Ur1HxrDMr6VMkiVjQSrNsMuqrg9GYTwJc6oV3+CsurkY4We y7JPpl4pZTsIPt3QXPNs+WltfA3oESxT+jDUoRS73dsOH9+7EbWQhIsUE7eZ0Szs +LvmXeEnIl2IVnApyd4tL1jOjZCjYMj+0clptfEkXZz6hGf4HtRjxa/HzSvENTWF FHFEr4198SQzmR3xj3tO4iwJ+WwzmYrCGY0neUhTCxb24GnMfk5DnD0U/YwPOvpf Z+e+bIJODIRT/aMzeP0ZCd2cAlDonYIJI+A536n9aSNm26yRU1YPdb1WjjyVs8QB 6FZblxFsheetSNnM82FR3tLf/fX2St1P9lbifVQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=T+221R WsxP4WVCW2L7ITMP0NkMIunSG+FjtcOkRWMEg=; b=A9IU/VslWAYu7U0Mh03wn5 qz+DWAdJzeua1fwvnVyiUJfW8VmP/CRkJ1yYPHHjaRU9MnJtm8t1IT09p2czgwdY zyuLWL+UKe57wMLFw86q+Gxyt/dmZWgyh2sMlo2H0ehXwj+MBtW1rhyIygAsPSTU ot3xKXOpciGoaYtnGO1ajFMLCBxtY6iFNYv+AS3LnjtEBH43KdAj/aNaHraJq5vK 6jqs3eUpmk/yy/k31KPW50r3LbwT9gc2ydd0KjEAsMoy2J6Y71Y/lazzhs9wYVmf EV1Bx/nuBY5QL3qYIYWrHVsczKTEDdZhzklrEa9kulwGIGdhQc3cLIOHuTbaGV8w ==
X-ME-Sender: <xms:muVWXy_EQqSpbhLIy9CfwLMOY8kwBP8YtCK4ltuqMxIT2lZOpqIBHA> <xme:muVWXyve-dGW0Wqex2sMd3T8E9V0sFdYPAfcGKRXV-psEpGLxg0dCwDi0Efc-nOcO f4PxwocVzIWl4JpZbk>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehuddgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgtddufeefjeejgeelgf fgveektddtkefgiedvtdfhudfhgfdvvdetieefudduieenucffohhmrghinhepghhithhh uhgsrdgtohhmpdgrtghmvgdrtghomhdpghhlohgsvgigrdgtohhmpdgtohhnthhoshhord gtohhmpdhhthhtphhonhhlhigtohhokhhivggtqdgrqdgrtggtvghsshhtohhkvghnrdhi nhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmth eslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:muVWX4CSAvb5J1mBGWSkJeqTL8j9V5fw-0sbvGNAMs4ZTlKzXDvJwg> <xmx:muVWX6fMmmFjB3-P4e1UNvNsCqop608nKSJkjATXhL7iip5-rx1CaQ> <xmx:muVWX3Px_loY0TpWW1b_xg_zr7bZI9cnjiyMrv1umf9xpnfPEOipqg> <xmx:m-VWX9blj7zXJzRVUHOlOUlz4gdzl8KyxZgsgyRdseVgGGVSt1AvZA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C3E5E20108; Mon, 7 Sep 2020 21:59:54 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3
Mime-Version: 1.0
Message-Id: <143eab3e-a69e-41c7-87ad-b81a784807ed@www.fastmail.com>
In-Reply-To: <020d097ac6f64e939167d85b0af9e51e@laserfiche.com>
References: <354049fc80094c0cb880d4d780ff0376@laserfiche.com> <2A78A684-72AF-492A-8BF1-B9B6A76B5F99@mnot.net> <020d097ac6f64e939167d85b0af9e51e@laserfiche.com>
Date: Tue, 08 Sep 2020 11:59:35 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: ietf-http-wg@w3.org
Content-Type: text/plain
Received-SPF: pass client-ip=64.147.123.19; envelope-from=mt@lowentropy.net; helo=wout3-smtp.messagingengine.com
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1kFSvY-0003Ud-Og d029cd2c022d281722eae34d6cb209a0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06
Archived-At: <https://www.w3.org/mid/143eab3e-a69e-41c7-87ad-b81a784807ed@www.fastmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38033
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

The way that browsers are moving here is to partition space based on the top-level browsing context.  That is, the cookie store for requests to A made by B is different to the cookie store for requests to A made by C.  This is governed by browser policy and there are some exceptions for a bunch of legacy reasons, but I believe that there is general agreement that the desired end state is isolation.  The current state is what enables web-based tracking and other abuses.  Moving to partitioned storage should reduce the need for server-based mechanisms.

See https://github.com/privacycg/storage-partitioning for more on this.

That said, you can't rely on clients maintaining any isolation based on a prefix, so if your goal is to prevent C from using B's token, it's probably not wise to put it in a cookie.  Not all clients will understand the prefix and enforce it, even if some do.

On Tue, Sep 8, 2020, at 10:58, Paolo Argentieri wrote:
> Hi Mark,
> Thanks. I understand that adding new features to cookies is a complex 
> process and I welcome an alternative solutions to the use case below.
> AFAIK, for all practical purposes, Secure HttpOnly cookies are the only 
> client side secure persistent store available to web apps today.
> The "__Host-" Prefix does not seem to provide what's needed.
> 
> Consider this use case:
> - (A) : REST Web Service hosted in Acme.com
> - (B) : Web App hosted in Globex.com, issues fetch requests to (A)
> - (C) : Web App hosted in Contoso.com, issues fetch requests to (A)
> - One user agent accessing both Web Apps (B) and (C)
> 
> Step 1: User navigates to (B), (B) connects to (A) and receives a 
> Secure, HttpOnly cookie (B-A-AccessToken).
> Step 2: User navigates to (C), (C) connects to (A) and receives a 
> Secure, HttpOnly cookie (C-A-AccessToken).
> 
> In this use case, we want the user to explicitly grant (C) access to 
> (A), and not hijack the existing (B-A-AccessToken) cookie.
> The solution, that can be implemented today, is for the server (A) to 
> keep track to what "origin", (B) or (C), the AccessToken cookie was 
> first issued to.
> 
> The issue here is that when (C) issues fetch calls to (A) both 
> (B-A-AccessToken) and (C-A-AccessToken) cookies are sent. E.g.
> 
> //JavaScript hosted in (C)
> fetch(uriOf(A)/resource123,
>             {
>                 credentials: "include",  //NOTE: Both (B-A-AccessToken) 
> and (C-A-AccessToken) cookies are included but only (C-A-AccessToken), 
> the one matching the request header Origin: (C), is considered by the 
> server. 
>                 mode: "cors"
>             }) .then(...
> 
> Ideally, the user agent would know to only send the (C-A-AccessToken) 
> cookie in the first place.
> My original proposal is an attempt to define a backwards compatible 
> "Origin locked" cookie: conformant user agent would not set or send 
> "Origin locked" cookies that don't "match" the Origin request header.
> 
> Regards,
> Paolo
> 
> -----Original Message-----
> From: Mark Nottingham <mnot@mnot.net> 
> Sent: Monday, September 7, 2020 12:50 AM
> To: Paolo Argentieri <paolo.argentieri@laserfiche.com>
> Cc: ietf-http-wg@w3.org
> Subject: Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06
> 
> 
> 
> Hi Paolo,
> 
> Are you familiar with the __Host prefix?[1]
> 
> Describing what you want to do in relation to it might be more helpful.
> 
> Also, from a procedural standpoint, we have a pretty high bar for 
> adding new features to cookies in the current work; the proposals that 
> are current in-scope needed to gain consensus for inclusion before we 
> started the work. So, we'd need to see some pretty strong support for a 
> new feature, given the state of the work.
> 
> Cheers,
> 
> 1. 
> https://urldefense.com/v3/__https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html*the-host-prefix__;Iw!!AD8y5q2f9OQ!4Ou-7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olqMau0eg$ [httpwg[.]org]
> 
> 
> 
> > On 5 Sep 2020, at 12:44 pm, Paolo Argentieri <paolo.argentieri@laserfiche.com> wrote:
> > 
> > Hi all, first post here.
> > 
> > I'd like to propose a new "__Origin-" cookie prefix with "origin locked" semantic.
> > While it is possible to implement these cookies today, standardized user agent support would add a layer of optimization and security.
> > 
> > The cookie name begins with prefix "__Origin-" followed by the domain that served the parent page (the origin) and, optionally, a name postfix. Example:
> > 
> > Set-Cookie: __Origin-apps.contoso.com-accessToken=12345; Secure; HttpOnly; SameSite=None
> > 
> > A conformant user agent would ensure that the cookie will have been set with a "Secure" attribute and the domain following "__Origin-" matches the request Origin.
> > In addition, a conformant user agent would not send an "__Origin-" cookie if the domain in the cookie name does not match the Origin, excluding port.
> > 
> > A server should ignore "__Origin-"  cookies whose name doesn't match the Origin request header. This combination yields cookies that are pinned to a specific origin thus well suited to roundtrip session ids or JWTs (immune to XSS session hijacking attack).
> > 
> > Regards,
> > Paolo Argentieri
> > 
> > 
> 
> --
> Mark Nottingham   
> https://urldefense.com/v3/__https://www.mnot.net/__;!!AD8y5q2f9OQ!4Ou-7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olZcXJkUg$ [mnot[.]net]
> 
> 
>