Subject: Origin cookies

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Oct 2014 05:29:00 +0200

Just saw this.  It's a laudable goal.  I'd hope that we could move
toward this being a default mode.

I'm concerned that this draft is a little backwards when it comes to
backward compat.  Clients that don't support the restriction will fail
open, spilling the cookie contents all over the place.  Especially so
if the origin attribute is the only attribute and other scope-limiting
attributes are not put in place.

In addition to that failure mode, I don't see any value in having a
signal from the client that a particular cookie is origin-bound.  The
Cookie header should be sufficient for that.

Would it make sense to reverse things: have the Origin-Cookie header
field be the Set-Cookie analogue and then include that data the Cookie
header field of requests

---

From: Mike West <[email-masked]>
Date: Fri, 24 Oct 2014 12:06:59 +0200

> toward this being a default mode.

Glad it looks interesting! I meant to send a proposal to the list earlier
this week, but didn't somehow...
https://tools.ietf.org/html/draft-west-origin-cookies-00 is the document
we're discussing.

> attributes are not put in place.

Per step 6 of http://tools.ietf.org/html/rfc6265#section-5.3, the example
in the document (`SetCookie: id=abcd; Origin`) would be treated as a
host-only cookie by browsers that don't support the proposal. It's not
clear to me what you mean by "failing open" in that case, as it wouldn't be
any more open than it is today.

I agree, however, that the document's examples should be more realistic,
and should set at least the `Secure` attribute.

> field be the Set-Cookie analogue and then include that data the Cookie

If we wish to defend against the kinds of annoyances that GitHub eloquently
documented at https://github.com/blog/1466-yummy-cookies-across-domains,
then we need to offer the website the ability to distinguish between
cookies set by its own origin, and cookies which might have been set by a
subdomain.

Moving origin cookies to a separate header makes this clear in a
backwards-compatible way. It's not clear that there's any way to shoehorn
that information into the existing header without breakage.

Thanks!

-mike

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Oct 2014 09:22:30 -0700

On 24 October 2014 03:06, Mike West <[email-masked]> wrote:
> Per step 6 of http://tools.ietf.org/html/rfc6265#section-5.3, the example in
> the document (`SetCookie: id=abcd; Origin`) would be treated as a host-only
> cookie by browsers that don't support the proposal. It's not clear to me
> what you mean by "failing open" in that case, as it wouldn't be any more
> open than it is today.
>
> I agree, however, that the document's examples should be more realistic, and
> should set at least the `Secure` attribute.

That's only one scope-limiting attribute.  You aren't looking to alter
Path, but there is also HttpOnly.  And then there's the fact that
cookies historically don't consider port number.

My point here is that you can't safely add something that attempts to
limit the scope of applicability if it relies on an attribute that
will be ignored by old implementations.  That means I'm having trouble
reconciling the design with the fact that confidentiality is an
important characteristic of cookies.  You wouldn't be able to rely on
the Origin attribute being honoured, not ever, which makes me sad.

The alternative is to ensure that your new stuff is completely ignored
by old implementations.  There are plenty of options here: you could
add a value to the Origin attribute, or use a new header field to set
the value... I recognize that introduces a pretty dire failure mode
(see Cake).

> then we need to offer the website the ability to distinguish between cookies
> set by its own origin, and cookies which might have been set by a subdomain.

Yeah, maybe we need a way for an origin to block cookies from subdomains.

> that information into the existing header without breakage.

Well, it's a cookie, so presumably there's ways to mark cookies that
were intended to be origin-bound in a way that can be detected by the
origin.  It's disgustingly inefficient, but I've used a MAC in the
past (I'm sure that you are aware of the Macaroon work here).

---

From: Mike West <[email-masked]>
Date: Fri, 24 Oct 2014 21:07:23 +0200

Thanks again for your feedback!

On Fri, Oct 24, 2014 at 6:22 PM, Martin Thomson <[email-masked]>
wrote:

> and

1. I'd contest `Path` having any security value at all. :)
2. HttpOnly is quite often valuable. The current draft sets it by default
for origin cookies.
3. Ports are ignored completely, true. There's no mechanism for restricting
ports in today's world. That's bad, but it's the world we've created.

In short; I agree with you that the examples should be updated to include
`Secure` and `HttpOnly`. Leaving out `domain` was intentional, as that
creates a host-only cookie. I've taken a stab at this in
https://github.com/mikewest/internetdrafts/commit/08af3b106782b399268248685d7a5bd213556c6e.
WDYT?

> will be ignored by old implementations.

I think it's much more difficult to get adoption of a feature that tries to
break substantially new ground, as opposed to that same feature layered on
top of existing infrastructure. I see the fact that this falls back
gracefully to status quo as a benefit, not a cost.

>   That means I'm having trouble

I don't understand this argument: you can rely on cookies being limited to
an origin by user agents that support such a concept. You can distinguish
such user agents by looking for an `Origin-Cookie` header, and _only_ sift
through the `Origin-Cookie` header for those agents.

For all other user agents, you get no change from status quo. That seems
like a reasonable path forward.

> the value... I recognize that introduces a pretty dire failure mode

That would certainly add implementation cost, but it's not clear what the
benefit would be. How would one be more able to rely on origin cookies if
we used `Set-Cake-Key` instead of `Set-Cookie`?

> cookies

Mark Nottingham has proposed a Content Security Policy directive in the
WebAppSec WG. That sounds like a very reasonable thing to consider.

> past (I'm sure that you are aware of the Macaroon work here).

Yes. Individual sites can certainly munge cookie values in various ways in
order to prove to themselves that the cookie's value is theirs and no one
else's. That doesn't help with the various cookie tossing annoyances out
there, but it's a good status quo strategy.

-mike

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Oct 2014 21:29:37 +0200

> through the `Origin-Cookie` header for those agents.

Oh, I have a very different threat model in mind.  That threat model
is the one that Secure addresses, namely that an origin can request
that cookies it gives out are not distributed by the client to other
hosts.  And when you send cookies, you don't necessarily know that
they support origin cookies, so you are taking a risk.

You seem to be more concerned with the converse aspect: that other
domains (subdomains or parent domains, HTTP or JavaScript) can alter
the cookies that you see in requests.

---

From: Mike West <[email-masked]>
Date: Fri, 24 Oct 2014 21:42:03 +0200

On Fri, Oct 24, 2014 at 9:29 PM, Martin Thomson <[email-masked]>
wrote:

> hosts.

Ok. Origin cookies address this concern by locking the cookies to the
origin that set them. An origin cookie set by `example.com` would not be
sent to `subdomain.example.com` and vice versa. I think we're on the same
page here.

> And when you send cookies, you don't necessarily know that

One way of mitigating this risk is to force the user agent to _always_ send
an `Origin-Cookie` header as a feature detection mechanism.

> the cookies that you see in requests.

I'm certainly concerned about `subdomain.example.com`'s ability to set
cookies for `example.com`. And even more about `http://example.com:1999`
setting cookies for `https://example.com:443`. Those are both use cases I
think origin cookies can help with.

--
Mike West <[email-masked]>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Oct 2014 23:15:28 +0200

On 24 October 2014 21:42, Mike West <[email-masked]> wrote:
> Ok. Origin cookies address this concern by locking the cookies to the origin
> that set them. An origin cookie set by `example.com` would not be sent to
> `subdomain.example.com` and vice versa. I think we're on the same page here.
>
>>

Now you get it :)  That seems kludgy, and it's going to hurt a lot
given the size of the name (have you considered calling this 'Cake'
for the sake of brevity?)

Now, if we are paying this price for feature detection, I think that I
would really like to see an entirely new mechanism defined.  Even a
small tweak would mitigate attacks like POODLE considerably.  Imagine
if you could randomly mask the contents of a cookie...

---

From: Mike West <[email-masked]>
Date: Sat, 25 Oct 2014 07:49:38 +0200

On Fri, Oct 24, 2014 at 11:15 PM, Martin Thomson <[email-masked]>
wrote:

> given the size of the name

This is where I wave my hands and say "header compression", and we all nod
wisely, right? :)

There are two ways I see for doing feature detection: UA sniffing, which is
terrible, or a request header. Reusing the same header seems like a
reasonable way of doing things, but a dedicated (short) hint-style header
might be better. I'd love suggestions.

> (have you considered calling this 'Cake'

Happy to. Cake is tastier than cookies, in any event.

> if you could randomly mask the contents of a cookie...

Hrm. I'm _totally_ on board with exploring a replacement for cookies
entirely (and I think channel ID, origin certs, etc. are already good steps
in that direction). I think we can (and should) do that in parallel with
baby steps towards sanity in the current implementation.

I see some distinct problems with the way cookies work. I think harmonizing
cookies with the same-origin policy is a nicely minimal way to offer
servers the ability to avoid those problems. I suspect that minimal changes
will be significantly easier to come to agreement on and deploy.

-mike

---

From: Martin Thomson <[email-masked]>
Date: Sat, 25 Oct 2014 00:00:24 -0700

> This is where I wave my hands and say "header compression", and we all nod

It's been watered down enough that a big header still does some
damage.  And your new mechanism won't be in the static table, so you
still want a short name.  Request header fields are still expensive :(

> cookies with the same-origin policy is a nicely minimal way to offer servers
> the ability to avoid those problems. I suspect that minimal changes will be
> significantly easier to come to agreement on and deploy.

That's true.  But this is just disruptive enough that I think we can
at least lay the groundwork for further incremental changes.  But I'm
concerned that this is already a fairly big change.  Either that, or
it's not going to do that much good.

Anything that requires support from both peers to work might as well
be a little more ambitious.

I don't think we're talking about making a fundamental change to how
server developers interact with this stuff.  That's where things like
channel bindings and origin certs tend to break down.  That suggests
that a name change or new attribute is probably OK, but it might be
too much to force them to say, remove randomized masking, which would
poodle- or beast-proof cookies.  But if we're using new fields, new
protections are possible, or, more specifically, we could structure
those new fields to enable new protections.

A simple change would be to require that origin cookies that are set
with an attribute the client didn't understand must be ignored.  That
would make it possible to develop new protections without the risks
I'm concerned about (new scopes of applicability, or things like the
randomized masking).  That's a modest improvement that could enable
incremental fixes later.  Those sorts of things aren't really possible
with Cookie/Set-Cookie, though it might be with Cake/Bake.

New header fields would also allow us to jettison that awful
[Set-]Cookie syntax, which doesn't play nice with the protocol.

I think that's all I'm asking for: new names and some very minor
tweaks to the grammar and semantics.

---

From: Zhong Yu <[email-masked]>
Date: Sat, 25 Oct 2014 17:11:44 -0500

Set-Cookie3? Just kidding.

Although, is it a serious problem that cookies can be set from
different origins within a domain? Typically, a domain and its
subdomains run code written by the same people. The ability to set
cookies across subdomains, ports, and schemes is a useful feature for
the people.

The problem github faces is not a typical one - there are not very
many companies that host user code on subdomains. And it's not too
much trouble for these companies to solve the problem with existing
devices.

Zhong Yu
bayou.io

---

From: Martin Thomson <[email-masked]>
Date: Sat, 25 Oct 2014 16:01:50 -0700

On 25 October 2014 15:11, Zhong Yu <[email-masked]> wrote:
> The ability to set

This is a feature that can be provided rather simply through the use
of mechanisms like postMessage, and that doesn't just allow
x.example.com to arrange for y.example.com to have cookies.

But then I'm being disingenuous.  The fact that alternative mechanisms
exist hasn't contributed to the demise of Cookies.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 26 Oct 2014 15:06:49 +0200

> On Oct 26, 2014, at 1:11 AM, Zhong Yu <[email-masked]> wrote:
> 
> subdomains run code written by the same people. 

I think this one is a common case, but I don’t think it’s true in most cases. Definitely not the case for companies (as opposed to content providers).

For example, my company has a public web site checkpoint.com, that is pretty much a “storefront” type website. It’s probably running on Apache or nginx and written by website designers. We have a supportcenter.checkpoint.com that has support articles, price lists and the like, and written by different website designers. Then we have exchange.checkpoint.com that is a Microsoft server, A SAP portal written by SAP, and even sslvpn.checkpoint.com (now disabled) that runs (not surprisingly) an SSL-VPN solution written by us. 

So no, you can’t assume that subdomains are written by the same people.

Yoav

---

From: Mike West <[email-masked]>
Date: Mon, 27 Oct 2014 08:40:55 +0100

On Sun, Oct 26, 2014 at 2:06 PM, Yoav Nir <[email-masked]> wrote:

> For example, my company has a public web site checkpoint.com, that is
> pretty much a “storefront” type website. It’s probably running on Apache or
> nginx and written by website designers. We have a
> supportcenter.checkpoint.com that has support articles, price lists and
> the like, and written by different website designers. Then we have
> exchange.checkpoint.com that is a Microsoft server, A SAP portal written
> by SAP, and even sslvpn.checkpoint.com (now disabled) that runs (not
> surprisingly) an SSL-VPN solution written by us.
>

Note also that in the presence of an active network attacker with control
of DNS (e.g. your local coffee shop), _every_ origin has attacker
controlled subdomains served over HTTP.

-mike

---

From: Mike West <[email-masked]>
Date: Mon, 27 Oct 2014 08:39:36 +0100

Thanks again for your feedback, Martin!

> still want a short name.  Request header fields are still expensive :(

I'm sure we can come up with an alternate syntax. `OC: 1` is probably too
terse, but it would be a minimal example to bikeshed around, if we agree
that such a mechanism is necessary.

> be a little more ambitious.

That proves a bit too much, doesn't it? I can't think of a meaningful
change that wouldn't require some level of support from both clients and
servers.

> incremental fixes later.

Hrm. Incremental fixes are enabled by adding explicit support for
as-yet-unknown extensions, as RFC6265 does in the `extension-av` grammar.
In fact, the reason we need a separate header here is that RFC6265 isn't
extensible enough: the `Cookie` header has no provision for metadata.

I see that as an argument for poking a bit at the `Origin-Cookie` header
grammar. It sounds like you might be suggesting that as well?

Those sorts of things aren't really possible
> with Cookie/Set-Cookie, though it might be with Cake/Bake.

I would be happy (really!) to devise a new scheme for HTTP state management
with you folks. I think there's lots of room for improvement, and good
ideas floating around.

I'm worried that it will turn into a multi-year slog towards consensus,
however. I believe we'll have more practical impact by defining small steps
towards something better.

That said, your argument that we design those steps in such a way as to
actually lead to something better is well-taken. So let's do that.

> tweaks to the grammar and semantics.

Can you be a little more concrete here? What names and grammatical/semantic
tweaks would you like to see in this proposal?

---

From: Zhong Yu <[email-masked]>
Date: Mon, 27 Oct 2014 13:40:02 -0500

> So no, you can’t assume that subdomains are written by the same people.

Sorry, I meant they are controlled by the same people, therefore
presumably there's no malicious code running on one subdomain
attacking another subdomain or the parent domain.

Cookie chose non-public-suffix domain as the isolation unit, which is
looser (with no regard to subdomain, port, scheme) that same-origin
policy. But the "same-domain" policy is not without reason or merit
either.

Zhong Yu
bayou.io

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Oct 2014 11:45:03 +0200

> On Oct 27, 2014, at 8:40 PM, Zhong Yu <[email-masked]> wrote:
> 

That’s presumed, but when IT departments install mail servers (with a web interface), firewalls, CRM and ERP software, they have limited control on what these servers do with cookies. Sure, hopefully they install software from reputable vendors who do not include malicious code, but the level of control is not what we would like.

Yoav