W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Calls for Adoption -- Cookie-Related Specifications

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 23 Dec 2015 20:03:57 +1100
Message-ID: <CABkgnnX4J=NcxjYKZnV2S2UGKdQ7DWhnhw5zapcG-4Q4GR4Crg@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Remy Lebeau <remy@lebeausoftware.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 23 December 2015 at 18:38, Mike West <mkwst@google.com> wrote:
>> If we have LSCA, then I find the incremental value of __Secure- to be
>> limited.  Unless I'm being daft, isn't __Secure- just a safeguard
>> against forgetting to include the Secure flag when setting the cookie?
> It's also an assurance that the cookie couldn't have been set from a
> non-secure origin. That is, given these two drafts, it's impossible for
> `http://example.com/` to set a `__Secure-*` cookie, so
> `https://example.com/` has a high degree of assurance that such a cookie is
> its own.

Right, that's the hole that Adam pointed out with leave-secure-cookies-alone.

The idea occurs that perhaps it would be possible to avoid making the
same mistake by expressing a origin-wide policy that said "all my
cookies are secure".  The consequence of that being that attempts to
set cookies without Secure fail and only cookies with Secure are sent.

I can also imagine a similar expression being made with respect to
cookies from other names or ports or ....

I'm sure that you've heard that suggestion before.  CSP is one option,
a __Cookie-Policy="" cookie being another possibility.

> Right. It "more or less" obviates origin cookies because the hole it leaves
> is fairly small. That is, the attack scenario is one in which an attacker
> controls a server running on a different port than the application, and can
> assert ownership of the host by negotiating a TLS handshake (because of
> `secure`). The nice thing about prefixes at the moment is that they only
> cement into place behaviors that exist and are widely supported today. It's
> not clear to me that closing that hole is worth adding complexity and
> backwards incompatible behaviors to cookies' implementation.
> Happy to have that discussion though. If I'm missing things, I'm happy to
> revive the draft in one form or another.

I think that I can accept that, if we also accept that origin cookies
are out.  But, I think that the alignment with the web security model
is actually important and I would rather have __Origin- with its
associated changes to the storage model than __Host-.  It just seems
like __Host- is a half-measure.
Received on Wednesday, 23 December 2015 09:04:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC