Re: Cookie controls?

On Wed, Aug 29, 2018 at 8:01 PM Erik Nygren <erik@nygren.org> wrote:

> Two considerations I see:
>
> 1. Adding domains to the public suffix list is operationally scary as
> there's no way to introduce a domain slowly and/or roll things back if
> something goes wrong.  For domains with many thousands of heterogeneous
> production use-cases, adding an existing domain is likely to be
> unacceptably risky in some circumstances.
> 2. The PSL doesn't scale all that well, is an oddly centralized thing, and
> feels like a hack.  This is less pragmatic, but it would be better if we
> had mechanisms to allow getting to safer defaults for cookies without
> relying on the PSL.
>

I think you're perfectly right that the PSL is not scalable, kludgy and
awkward to use ;-) (and I certainly empathize with the deployment concerns
in a complex application ecosystem). The PSL does, however, have the
benefit of already being used in the wild, and I imagine that being able to
reliably depend on any new mechanisms across browsers might take longer
than you're comfortable with -- so I figured I'd at least mention it
because IIRC it didn't come up in the in-person discussion.

When it comes to a more sane design for this, it would kind of make sense
to me if it lived in Feature Policy (e.g. FP: only-host-cookies; or FP:
no-cookies or something of that sort) and could be turned on for the whole
origin by setting a default FP in the Origin Policy.

Cheers,
-Artur


>
> Best, Erik
>
>
>
> On Fri, Aug 17, 2018 at 5:43 PM Artur Janc <aaj@google.com> wrote:
>
>> Regarding alternatives, what are the constraints that prevent you from
>> putting the CDN domain on the public suffix list (
>> https://publicsuffix.org)? AFAIK many sites which have registrable
>> domains with subdomains hosting user-controlled content use the PSL to
>> prevent the cookie clashes you're talking about -- some prominent examples
>> include appspot.com, blogspot.com and github.io.
>>
>> Cheers,
>> -Artur
>>
>> On Fri, Aug 17, 2018 at 12:38 AM Mike West <mkwst@google.com> wrote:
>>
>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>