Re: Cookie controls?

To answer Yoav's questions:

1.  I stopped working on CSP's cookie controls because I thought it would
be folded into Feature Policy. That didn't happen.
2.  There are no alternatives that I know of which give you the guarantees
you're looking for. Perhaps we should build some.

This seems like a reasonable kind of problem to address, but if we build
something, let's not put it into CSP. I'm very interested in calling CSP3
done, and never touching it again. :) Erik's `Limit-Cookies` header sounds
fine (I'd prefer for it to live in origin policy, actually, but that's
something of a mid-term project in itself).

Dev's suggestion that we lean on prefixes sounds reasonable to me. That is,
the limits we express could be prohibitions against sending/setting
non-prefixed cookies (or setting cookies at all). I'd caution against
saying that we could "constrain cookies to the Origin model", though:
cookies don't respect ports, and given the not-terribly-enthusiastic
response that https://tools.ietf.org/html/draft-west-origin-cookies-01 got,
I expect that `__Host-` is going to be the best that we can do.

-mike


On Fri, Aug 17, 2018 at 6:44 AM Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> Not sure I understand. Javascript can't set a __Host cookie that is
> broader context than the current host either. Do you want to do this for
> applications where changing the application to use __Host cookies is not
> possible (and thus, you want a header that can be added by a proxy in the
> middle)?
>
> Also, slight clarification: if I am not wrong, a __Host cookie is still
> not tied to origins. A __Host cookie on foo.bar.com will also go to
> baz.foo.bar.com.
>
> --dev
>
>
>
> On 16 August 2018 at 19:17, Erik Nygren <erik@nygren.org> wrote:
>
>> I think my primary use-case is covered if we define a way to allow
>> servers and/or origins to force Cookies to conform to the Origin model.
>> (Being able to indicate that cookies are prohibited on an Origin is perhaps
>> a secondary use-case.)
>>
>> Providing an ability to constrain cookies to the Origin model for a given
>> Origin (and/or to prohibit them entirely) would help normalize some of the
>> pain associated with cookies.
>> Defining a simple header focused specifically on this use-case as part of
>> 6265bis might be be one possible path, and that aligns with some of the
>> other goals of 6265bis (eg, the introduction of __Host cookies).  For
>> example, a response header of:
>>
>>     Limit-Cookies: origin
>>     Limit-Cookies: none
>>
>> that would either be a sticky attribute to that origin and/or host
>> (likely up to some expiry) or would apply to any active content resulting
>> from the object associated with that response header.
>>
>> The challenge is that there's no way for a server to constrain all
>> cookies to be __Host cookies (or otherwise be same-origin cookies) as
>> javascript running within that origin context can choose to set cookies on
>> something broader than the Origin.
>>
>>        Erik
>>
>>
>>
>> On Thu, Aug 16, 2018 at 9:37 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
>> wrote:
>>
>>> Hey Yoav
>>>
>>> Would __Host cookies help here? Maybe I am missing something about the
>>> problem but it feels like they should.
>>>
>>> --Dev
>>>
>>> On 16 August 2018 at 01:41, Yoav Weiss <yoav@yoav.ws> wrote:
>>>
>>>> Hello folks!
>>>>
>>>> Akamai has ran into some issues with cookies where Cookie Controls
>>>> <https://w3c.github.io/webappsec-csp/cookies/> would've been extremely
>>>> helpful. Digging up the issues that lead to its obsoletion didn't reveal
>>>> much reasoning, so I'm wondering why is was rendered obsolete, and whether
>>>> there are alternative proposed mechanisms to replace it.
>>>>
>>>> Our use case is providing customers traffic delivery in
>>>> customer-controlled subdomain of an Akamai domain. An example of that would
>>>> be cdnexampledomain.com where foo.cdnexampledomain.com and
>>>> bar.cdnexampledomain.com are customer-controlled.
>>>> The concern is that each of these subdomains can set cookies on the
>>>> cdnexampledomain.com domain, polluting the shared namespace, and
>>>> sending cookies to domains outside their control.
>>>>
>>>> While Akamai can filter header based cookies on those domains, it
>>>> cannot prevent JS from adding such cookies.
>>>>
>>>> We would be interested in a header that we can set, and which can
>>>> prevent those subdomains from setting cookies on the parent domain, while
>>>> enabling them to continue to set whatever cookies they need on the
>>>> subdomain itself.
>>>>
>>>> When mentioning this use-case on the call yesterday, suborigins
>>>> <https://w3c.github.io/webappsec-suborigins> was raised as a potential
>>>> solution for this use-case, but looking at the draft, I'm not sure how it
>>>> would without making those subdomain documents cookie-averse, and make it
>>>> so they can't set cookies from JS at all (which may not be compatible with
>>>> current, non-malicious content on those domains).
>>>> But it's fairly possible that I'm Holding It Wrong™.
>>>>
>>>> I also realize that we want to move away from cookies
>>>> <https://github.com/mikewest/http-state-tokens>, which would be great,
>>>> but in the {short,mid}-term they'd probably still be around, so better
>>>> control mechanisms can be very helpful.
>>>>
>>>> To sum up, my questions are:
>>>> * Why was Cookie Controls obsoleted?
>>>> * Are there any alternatives? Otherwise, can it be revived?
>>>>
>>>> Cheers :)
>>>> Yoav
>>>>
>>>>
>>>>
>>>>
>>>
>>
>