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

Paolo Argentieri <> Thu, 10 September 2020 00:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B3BF3A0963 for <>; Wed, 9 Sep 2020 17:25:56 -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)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8modpUdMiP07 for <>; Wed, 9 Sep 2020 17:25:54 -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 04CE93A0962 for <>; Wed, 9 Sep 2020 17:25:52 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kGAMn-0007xf-VG for; Thu, 10 Sep 2020 00:23:10 +0000
Resent-Date: Thu, 10 Sep 2020 00:23:09 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kGAMi-0007wo-PC for; Thu, 10 Sep 2020 00:23:04 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kGAMf-0006e0-SZ for; Thu, 10 Sep 2020 00:23:04 +0000
Received: from pps.filterd ( []) by ( with SMTP id 08A0AWJP015214 for <>; Wed, 9 Sep 2020 17:22:49 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pps1; bh=4ATCTdADjRdwVegrTF7Cb+xvP9qYoYxAhMe9/ULG9f8=; b=k7JD2enYXoALE3MMpHuoQxviq8xEOODW0d4IaF6WUJMBjVQIDYluffqaltlLV0JkP6/2 DDptd7qfUBtUrv+iMWum6D7XO7n3+nCjeYDKvVlBzMcIcYwg3nC/SOJ2nrZHx6r1qmEU RDfryDjYuGegxtoYhRCwFctFpRfb5oiL4Mtr7j4Fsph4yop54s2cherDEGdHQqn5ImSV yHi6xA5M8wrZ+AlUociBx/bq/06+v+9oRYa1doNIDZhM12jAPkydSlZjn/Y98g+2vV0G CMU+HRdZkY57JnMI7qi7ZdaHjisKclVHAzTZvX4RawFMtM7Q01Yc7zm3PCTQjdvT2V8c vA==
Received: from ( []) by with ESMTP id 33c6dmkfmv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <>; Wed, 09 Sep 2020 17:22:49 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Wed, 9 Sep 2020 17:22:49 -0700
Received: from ([fe80::ede2:6391:7f33:ef66]) by ([fe80::ede2:6391:7f33:ef66%4]) with mapi id 15.01.2044.004; Wed, 9 Sep 2020 17:22:48 -0700
From: Paolo Argentieri <>
To: "" <>
Thread-Topic: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06
Thread-Index: AdaDLhITApZ9D9QiQsGQE9kbe964WwB+AliAAAaH+CAAH4kYgABB2F+g
Date: Thu, 10 Sep 2020 00:22:48 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-c2processedorg: 96cc0e5e-91aa-499a-88f5-5c9e71ddb7d5
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-09-09_17:2020-09-09,2020-09-09 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 suspectscore=0 spamscore=0 bulkscore=0 priorityscore=1501 mlxlogscore=999 impostorscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 mlxscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009100000
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1kGAMf-0006e0-SZ d234316d10236c97deaa0522db5d6081
Subject: RE: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06
Archived-At: <>
X-Mailing-List: <> archive/latest/38038
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Martin,
Thanks for the link. The "Top-level origin" concept is useful in this discussion.

Currently, storing secrets (e.g. bearer token) in httponly cookies seems to be the only practical local store solution for keeping it safe from code injected in a page.
I agree: the server should independently verify cookies origin regardless.

The value added of a "__Origin-" cookie prefix with " top-level origin locked" semantic would be:
- Backwards compatible. 
- Conformant user agents would add a layer of security and enable scalability:
 1) E.g., "Set-Cookie" header would be accepted only if FQDN matches the FQDN of top-level browsing context origin
         Set-Cookie __Origin-FQDN; Secure; HttpOnly;

 2) Cookie "__Origin-FQDN" would be included in the request only if FQDN matches the FQDN of top-level browsing context origin
     Since only the FQDN matching cookies would be included in the request, it enables scalability when many "top-level browsing context web apps" interact with same web service.

I'll admit that this proposal is not particularly elegant. If a new cookie prefix is just not in the future the specification, let me know!


-----Original Message-----
From: Martin Thomson <> 
Sent: Monday, September 7, 2020 7:00 PM
Subject: Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06

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;!!AD8y5q2f9OQ!9fBZA4O8qjQRnLM_a4XDijQ0wA2PnI5P8McKlDY14BMZOzsvB537FmlWMjQ37lWCguA6Aco$ [github[.]com] 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. 
> etf-httpbis-rfc6265bis.html*the-host-prefix__;Iw!!AD8y5q2f9OQ!4Ou-7lGJ
> NdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_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   
> 7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olZcXJkUg$ 
> [mnot[.]net]