- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 23 Dec 2015 20:03:57 +1100
- 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