Re: Calls for Adoption -- Cookie-Related Specifications

On Wed, Dec 23, 2015 at 4:32 AM, Martin Thomson <martin.thomson@gmail.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.


> The choices for __Host- are good from a host perspective, but the Path
> restriction doesn't carry any justification and I can't think of any
> justification.
>

You're right; I did a poor job explaining that choice. In short, the set of
flags that `__Host-*` mandates are as close as we can get to aligning
cookies with the web's general same-origin policy without adding new
behaviors. By locking them to a host, ensuring that the secure flag is set,
and ensuring that the path is scoped to the root of the host, we have a
pretty good approximation of an origin-bound cookie, that doesn't attempt
to pretend that there's a defensible security boundary between
`[origin]/path1` and `[origin]/path2`.


> Upthread, Mike states:
> > I think https://tools.ietf.org/html/draft-west-origin-cookies-01 is
> more or less completely obviated by cookie prefixes.
>
> This isn't correct because __Host- doesn't bind to the port number.
> Though maybe it should (or we should define an __Origin- prefix
> instead).
>

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.

-mike