Re: draft-west-leave-secure-cookies-alone

Mike West <> Thu, 22 October 2015 11:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7F83E1A1BED for <>; Thu, 22 Oct 2015 04:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.39
X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R4rbbE8-R3z9 for <>; Thu, 22 Oct 2015 04:31:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16D541A1BEC for <>; Thu, 22 Oct 2015 04:31:12 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZpE24-0007LE-An for; Thu, 22 Oct 2015 11:27:44 +0000
Resent-Date: Thu, 22 Oct 2015 11:27:44 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZpE1z-0007Jn-AC for; Thu, 22 Oct 2015 11:27:39 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZpE1u-0008KZ-Qk for; Thu, 22 Oct 2015 11:27:37 +0000
Received: by lfaz124 with SMTP id z124so44024832lfa.1 for <>; Thu, 22 Oct 2015 04:27:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sRiTNsDFsoIY8s29vL44NunT9OlR0iZhnLhq7L+feXE=; b=NLt7IB7CP8tTb9wGssBI67goV25p3VeqwjBvU0cb0255meosazU2BkAob5FKcDTCEE rj5WX4sdLCP8OKnyPL+JMNgjkiS71W+1cTrRJ3jPEYLmOXFau9zX4ji7g5eM3eF63tY2 3QCI2cz0LNjFApd0Kn7vk5WVjS12prlRtONgNoVyo4M+9fzwORaWTyYEICT2NXzt5bc6 SJv9UzMXA0ZniOjWCVL6TsBdQkjxA7KPcsZAowF/BG9F1v9Tf8wTJds8Srbm9wftXzv0 Wktxz82HmdnZ75SxtTjbNm6p0H1qzTUjThKAHJzncVwwQ56sxBBBmmTMJDJpnzRrh2Jy oHDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sRiTNsDFsoIY8s29vL44NunT9OlR0iZhnLhq7L+feXE=; b=DYPsYQPmbQE6aCbSovDG2Rs+PrPnbwnG9zcrkULeO5VhgLOBj9d7ZKiRWmbHD+et7w 9YDCJGy+IvQUXiUF+FW9vXHNnZs8UVCX+1pz85bGUHm/+yU/Q1BIX1xC/Ys46QgV7R8v T7gPn/IMkcWzclOGZLLz/xhfhM4BDs2923bF2x4e6jVq8rXUnALJzqhF/jECFHb0cB2h Lb9g9IQYndvuIP0H6dkCrd1ADhctzJtj5G+ujJ6aq0aZXRFkmLKaMJmCrlU6cudZM4Kc eG3m2aZ7/Q1lIxB51cMvy8NoLahEuXjMH6NwZb16VG0vcEOLuzisCTf2YMlgwO2PkDBB rXOg==
X-Gm-Message-State: ALoCoQnXAn2061xJJq0bT+AJ85/9brTVy8BJmNe6eCjAkj7H68XGa32ElnLK3BYyey6vrwGflaik
X-Received: by with SMTP id up5mr7986537lbc.96.1445513227395; Thu, 22 Oct 2015 04:27:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 22 Oct 2015 04:26:47 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Mike West <>
Date: Thu, 22 Oct 2015 13:26:47 +0200
Message-ID: <>
To: Martin Thomson <>,
Cc: HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: AWL=1.844, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=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: 1ZpE1u-0008KZ-Qk d5f59fe8b48d574a1ee2beb24fd9ad7f
Subject: Re: draft-west-leave-secure-cookies-alone
Archived-At: <>
X-Mailing-List: <> archive/latest/30392
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks for noting this, Martin. I somehow didn't think to ping these
drafts to the list.

On Thu, Oct 22, 2015 at 12:05 AM, Martin Thomson
<> wrote:
> I realize that we haven't discussed this at all, but it seems like a
> no-brainer to me.  That is, if someone (Mike?) has a satisfactory
> answer to this question: do you know what level of breakage is this
> going to cause?  I have heard that this misfeature is relied upon by
> some non-trivial number of sites.

Chrome sees something like 0.01% of `Set-Cookie` operations fall into
the category that this draft suggests ignoring.

Mozilla has similar metrics hovering around 0.02%.

> For me, as long I can be satisfied that the breakage is extremely low,
> or that it will soon be, then that's sufficient.  However, a
> non-trivial amount of bustage will likely prevent us from deploying a
> change like this.

I think we can mitigate the impact by rolling this kind of change out
in a somewhat coordinated fashion, and announcing it beforehand. The
current cipher-suite deprecations seem like a reasonable model to

On Thu, Oct 22, 2015 at 7:44 AM, Willy Tarreau <> wrote:
> I think in fact that what we're missing is the ability for the
> browser to tell the server how it considers the cookie (secure or
> not). The servers could then decide to ignore non-secure cookies
> in this case and that would protect much better, including against
> cookie injection. That would require updating the cookie syntax and
> spec though since we can't pass attributes with cookies :-/

About that...
is one approach. is another
(and has the advantage of being trivial to implement). Chrome's
implemented the latter (at least the `$Secure-*` prefix) behind a flag
for folks to start playing with.