Re: Origin cookies, and First-party cookies.

> On Nov 21, 2014, at 6:57 PM, Mike West <mkwst@google.com> wrote:
> 
> Hello, ietf-http-wg folks!
> 
> I posted two cookie-related drafts before the HNL meeting, which I hope some of you took a few moments to skim through: origin cookies[1] (an update of Adam Barth's "Cake"), and first-party cookies[2] (cookies which are sent iff the top-level browsing context would have received them).
> 
> Did you skim through the proposals? Do you have opinions? I hope the answer to both questions is yes! :)
> 
> It's not clear to me whether this group is the right place to work on those concepts, but it seems like a good place to start. Also, I have to admit that I'm an IETF newbie; I don't know the process or procedure for deciding this kind of thing. Mark, can you help out a bit?
> 
> Thanks!
> 
> [1]: https://tools.ietf.org/html/draft-west-origin-cookies-00 <https://tools.ietf.org/html/draft-west-origin-cookies-00>
> [2]: https://tools.ietf.org/html/draft-west-first-party-cookies-00 <https://tools.ietf.org/html/draft-west-first-party-cookies-00>
> 

Hi, Mike

Now I’ve had a chance to go over these more carefully. They are both quite rough (as their text says multiple times), but for me the part that is really too thin is the justification - it’s hard to figure out what the problem that they are trying to solve is. Something like "Harmonizing with the same-origin policy” is a good headline or a sentence in the abstract, but it really needs to spell out what is possible with regular cookies that is not possible with origin (or first party) cookies. I get it, but it should be spelled out.

In previous discussions of why we need “new cookies” several issues were raised:

 1. Cookies are bearer tokens and that makes them a prime target for attacks such as BEAST, CRIME, POODLE. None of those would have had the impact it did if it wasn’t for the fact that they leaked cookies and allowed session hijacking. People wanted a proof of cookie possession as the transmitted value rather than the cookie itself.

 2. Cookie scoping. Cookies are authorization tokens and available for use by any window in the browser. As a horrid example, there was this firewall with an administrative web interface. The web interface had apparently one resource called “mainpage.html”, and whatever the user did was conveyed as query string arguments. So if I pressed the “Shutdown” button, the request would be “GET mainpage.html?button=shutdown”. So if I had an active session with that firewall and in another browser window got a page with a static resource <img src=“https://my.firewall/mainpage.html?button=shutdown”>, the firewall would shut down. Everyone who sees that (real) example laments the cluelessness of those who wrote this web application, but it’s only clueless because the web gives any page the authorization of the user agent.

 3. Lack of cryptographic binding between the cookie and the content of the request makes possible all kinds of attacks where the user agent “blesses” the requests made by another.

Of these issues, both of the draft only address #2. This isn’t a bad thing, because IMO this is the worst part of cookies. I’m wondering if we really need both, because getting two mechanisms implemented on all browsers is hard, and guidance will be needed for applications developers on which to use. Specifically I’m wondering what (if anything) we can do for content in frames, which isn’t helped by first-part.  I’d also like to see solutions to the other issues.

That said, I am very much in favor of adoption first-party cookies as a starting point, and working on it to provide a (singular!) new mechanism for session management.

Yoav