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

Martin Thomson <> Tue, 08 September 2020 02:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE63D3A0E6F for <>; Mon, 7 Sep 2020 19:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
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: (amavisd-new); dkim=pass (2048-bit key) header.b=Ur1HxrDM; dkim=pass (2048-bit key) header.b=A9IU/Vsl
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7R7YOp0AMhUD for <>; Mon, 7 Sep 2020 19:02:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06F333A0E64 for <>; Mon, 7 Sep 2020 19:02:42 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kFSvc-0001iP-Ca for; Tue, 08 Sep 2020 02:00:12 +0000
Resent-Date: Tue, 08 Sep 2020 02:00:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kFSvb-0001he-28 for; Tue, 08 Sep 2020 02:00:11 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kFSvY-0003Ud-Og for; Tue, 08 Sep 2020 02:00:10 +0000
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 86CC5C18 for <>; Mon, 7 Sep 2020 21:59:55 -0400 (EDT)
Received: from imap10 ([]) by compute2.internal (MEProxy); Mon, 07 Sep 2020 21:59:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=; 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: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <>
Date: Tue, 08 Sep 2020 11:59:35 +1000
From: "Martin Thomson" <>
Content-Type: text/plain
Received-SPF: pass client-ip=;;
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: 1kFSvY-0003Ud-Og d029cd2c022d281722eae34d6cb209a0
Subject: Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06
Archived-At: <>
X-Mailing-List: <> archive/latest/38033
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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 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
> - (B) : Web App hosted in, issues fetch requests to (A)
> - (C) : Web App hosted in, 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 <> 
> Sent: Monday, September 7, 2020 12:50 AM
> To: Paolo Argentieri <>
> Cc:
> 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. 
>*the-host-prefix__;Iw!!AD8y5q2f9OQ!4Ou-7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olqMau0eg$ [httpwg[.]org]
> > On 5 Sep 2020, at 12:44 pm, Paolo Argentieri <> 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:; 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   
>;!!AD8y5q2f9OQ!4Ou-7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olZcXJkUg$ [mnot[.]net]