Intent to Ship: cookie prefixes

[Emily Stark]

+net-dev and security-dev via BCC.

Contact emails

est...@chromium.org, mk...@chromium.org

Spec

https://tools.ietf.org/html/draft-west-cookie-prefixes-05

Summary

This feature adds a set of restrictions upon the names which may be used for cookies with specific properties. These restrictions enable user agents to smuggle cookie state to the server within the confines of the existing "Cookie" request header syntax, and limits the ways in which cookies may be abused.

In a nutshell: `__Secure-*` cookies have to be set from secure origins with the `Secure` flag, and `__Host-*` cookies have to have `Path=/`, can't have `Domain`, and require `Secure`.

Motivation

Cookies are terrible. This proposal makes them slightly less terrible, by addressing the "Weak Confidentiality" and "Weak Integrity" concerns spelled out in RFC 6265. See the Intent to Implement thread for more detail.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/IU5t6eLuS2Y/Uq-7Kat9BwAJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Compatibility Risk

The syntax is backwards compatible with existing cookie syntax and flags. There is a risk that existing sites might already use the __Secure or __Host prefixes on their cookies and those sites would break when we ship this change. Our telemetry from Canary and Dev does not show any uses of those prefixes, though.

We can't implement this on iOS because we don't have control over either the cookie store or the network stack.

OWP launch tracking bug? https://crbug.com/541511

Link to entry on the feature dashboard: https://www.chromestatus.com/features/4952188392570880

[Devdatta Akhawe]

how does this interact with document.cookie? Can a document that has
modified document.domain set __Host cookies? Can an insecure page set
__Secure cookies?

(sorry .. a quick grep didn't find anything in the intent to implement
or in the draft)

> --
> You received this message because you are subscribed to the Google Groups
> "Security-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev...@chromium.org.

[Mike West]

On Tue, Dec 8, 2015 at 8:10 PM, Devdatta Akhawe <dev.a...@gmail.com> wrote:

how does this interact with document.cookie? Can a document that has
modified document.domain set __Host cookies? Can an insecure page set
__Secure cookies?

(sorry .. a quick grep didn't find anything in the intent to implement
or in the draft)

Prefixes have no effect on `document.cookie`, other than requiring that if you set a cookie via `document.cookie` that the flags are set as specified. If the document can set a cookie with `secure; path=/`, it can set a cookie named `__Host-whatever` via `document.cookie`.

I'd have to check the code to be 100% sure, but I'm _pretty_ sure that `document.domain` has no effect on a cookie's domain. We use the actual URL of the document (or of its origin in some weird edge cases).

-mike

[Philip Jägenstedt]

LGTM1

The syntax is ugly, but the spec section Why "__"? quickly removed those doubts :)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

Actually, scratch that, I don't understand the relationship between this and Joel's thread, can they really be considered in isolation, or should we pick one of the threads to cover it all?

[Mike West]

On Wed, Dec 9, 2015 at 3:19 PM, Philip Jägenstedt <phi...@opera.com> wrote:

Actually, scratch that, I don't understand the relationship between this and Joel's thread, can they really be considered in isolation, or should we pick one of the threads to cover it all?

I think they're separate features, but I'm happy for you to just LGTM both at the same time if that's simpler for you. :)

Prefixes place restrictions upon cookies with certain special names, no more no less. Those restrictions are defined in terms of existing behavior, and are completely backwards compatible. The feature is easily shippable in isolation, and doesn't require any changes to any other part of any other cookies' behavior. There's basically zero risk to shipping prefixes.

Joel's thread deals with a change to the existing behavior of the `secure` token. That change will affect prefixed cookies, but only insofar as it effects all cookies with that token, and both prefixes require it. It is less backwards compatible, and has some level of risk associated with it. I believe Joel intends to take it slow with that rollout, gating things on field trials to let us roll the change out incrementally, but I'll defer to him on a discussion of the details.

-mike

[Philip Jägenstedt]

OK, let's see if I understand this. This intent covers the prefixes "__Secure-" and "__Host-", rejecting attempts to set that cookie if the requirements for the prefix are not met.

Joel's intent, on the other hand, is ensuring that cookies with the "Secure" attribute set are entirely isolated from insecure origins? This affects all secure cookies, incidentally including those using the "__Secure-" prefix?

Philip

[Mike West]

Correct.

-mike

[Philip Jägenstedt]

OK, LGTM1-1+1 = LGTM1 to ship cookie prefixes!

[Joel Weinberger]

Just confirming what Mike said about the slow rollout. Based on our measurements, we think Strict Secure should be OK to rollout, but we want to just make sure there isn't any surprise breakage.

[Chris Harrelson]

LGTM2

[Dimitri Glazkov]

__LGTM3