Re: Cookies and schemes.

Martin Thomson <> Tue, 10 March 2020 07:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 621943A092B for <>; Tue, 10 Mar 2020 00:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Status: No, score=-2.751 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=jXdogRHg; dkim=pass (2048-bit key) header.b=CElkzGG9
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id siYzbHaPpaf1 for <>; Tue, 10 Mar 2020 00:55:25 -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 A06493A095E for <>; Tue, 10 Mar 2020 00:55:24 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jBZg7-0007Al-Ha for; Tue, 10 Mar 2020 07:51:51 +0000
Resent-Date: Tue, 10 Mar 2020 07:51:51 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jBZg0-00079z-Dh for; Tue, 10 Mar 2020 07:51:44 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jBZfy-0002hI-IX for; Tue, 10 Mar 2020 07:51:44 +0000
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 68D9A63D for <>; Tue, 10 Mar 2020 03:51:30 -0400 (EDT)
Received: from imap2 ([]) by compute2.internal (MEProxy); Tue, 10 Mar 2020 03:51:30 -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=fm1; bh=ePE8FkW8SyGfd1cUBbg/UoRS6yewrdk w8CCvCQvYXxg=; b=jXdogRHgvzGnmlce1uH0TaR/XqCI7HutkbC4Gx7Y66fXiLu S96XwiuetGiVRBCHBtNIiDz/iwguWuTZyBmNCsGoxC8LFov/yBsn5hn8DIlftMIU RypPwIJ8X/YkO+q3Ikv/OU0iWGnaDDtjJWcy2ZmLfiicgcp5vCPlMjUoTtzfsrcn lAW8dLHbpZ4gJYZj1qFxE7+Ng37uKw233lY3X+vENqkS228Ou7SOOuBKhRWaf0KR 2bxBLLWMXX0wnxOwswQEKlnFScrxjE4bt33HQeRQdipB5KgRyEUnffWM5lAsTHJ+ u9ba89EfCT1860uaw40OwU9dAhhXYTNqqACtijw==
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=fm2; bh=ePE8Fk W8SyGfd1cUBbg/UoRS6yewrdkw8CCvCQvYXxg=; b=CElkzGG99piHY8vPBhYoeO gGpUOiQl8jFLiicxaRf/FNmq9VuAydOhXbaQyyuX87oWMAjhqlOtkSUHgVUXXqaN bMf/mCQwoUHxgR+7tovUAWgoAJyvqJtqDEdHXHevU5WAy2LeiDJCFH4PczeFLixb TQfzEmklFzremqOMNqt6kkoFL4h4+j+TluRZHKXFKLurkVVET6fuoX2okWWu1Yuf 4jmZwWfilpwxu+e+m53+nSRoq9aY0t/nw1RTfQcQUlxZt/siBLI5De+EehPTcL0w v+DBWhia/baupFpnAYUR25poCTmJxPIIQfhZnIyYT6GnYfB5DEWidhWnWW5RsmjA ==
X-ME-Sender: <xms:AUdnXtyL2o17KyDgke0MzSQ99dLybtZUM9fJu11lm40RoRcvDr8wKA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudduledgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:AUdnXocooAZYUHLDgloAs58vfTLn0xsT48WvxnHBuT7DaGOSVIDGTw> <xmx:AUdnXmfmJDlpFvUdxpnrrNzUYCB8nkUUsbrSSDEzfNzhQeFDpfWNNQ> <xmx:AUdnXvxhQgLcM3JUj7VrWbuZc5mXFLwo-2fKDIOxBwmRJiRNYpgwyw> <xmx:AkdnXmDPuG7WJq9chAAo4dfiogU66Jt7Bqk2GUj13hvY12aeimRX5w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id C083CE00FE; Tue, 10 Mar 2020 03:51:29 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <>
Date: Tue, 10 Mar 2020 18:51:09 +1100
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, 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: 1jBZfy-0002hI-IX e0f5973fd89181530fb8bcced62adfd3
Subject: Re: Cookies and schemes.
Archived-At: <>
X-Mailing-List: <> archive/latest/37431
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, Mar 10, 2020, at 18:29, Mike West wrote:
> 1. Perhaps we do this kind of thing only for a specific endpoint 
> (`/.well-known/migrate-nonsecure-cookies`, for example)?

Eww.  More seriously, I can't see this fitting with existing needs very well.

> 2. Perhaps we prefix the non-secure cookie names with `__Non-secure-` 
> rather than minting a new header?

That might work.  It's new mechanisms, but not new-header-field new mechanisms.  More below.

> Ideally, the load-balancing case devolves to the LB doing an immediate 
> redirect to HTTPS, and then deciding which backend the user should 
> stick to in that secure context. I don't think we should add new 
> attributes in order to support sites that push users back and forth 
> from HTTPS to HTTP.

Yes. HSTS is the only path that has long-term legs here.  If port 80 wants to do some setup for port 443, that's not terrible, but ultimately I think we need to have servers prepared for the first connection arriving on 443.

I'd like to understand more of why there might be multiple cleartext redirects involved.  Or why it might be desirable to not include cookies in all of those responses.

To that end, anything we do here will apparently cause immediate bustage, with the possible exception of what I proposed (absent multiple redirects being involved).

You might annotate those with tags that indicate their shaky status as a warning, but I expect that anything that isn't bustage will be roundly ignored.  So moving them, either by changing their name or putting them in a new header field, does have the effect of causing sites to pay attention.  But flat-out removing the cookies would also have a similar effect and that is the end goal.

The only value to moving them is that maybe servers can salvage something from this quickly and without a ton of extra engineering.  I think that the prefix is the most likely to be conducive to some form of salvage, but I would want to hear that this is necessary and easy before we get into a multi-stage deprecation process.