Intent to Implement: Cookie Prefixes

[Mike West]

+BCC: net-dev@, security-dev@

# Contact emails

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

# Spec

https://tools.ietf.org/html/draft-west-cookie-prefixes-01 # 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 have the `Secure` flag, and `$Origin-*` cookies have to have `Path=/`, can't have `Domain`, and might require `Secure` (depending on the setter).

This seems like the simplest thing that might possibly work.

# Motivation

Cookies are terrible. This proposal _might_ make them slightly less terrible, by addressing the "Weak Confidentiality" and "Weak Integrity" concerns spelled out in RFC 6265.

The syntax is fairly hideous, but practical: 

* No new behavior is defined; the spec is predicated upon enforcement of existing flags.

* No new syntax is defined; the spec is completely backwards compatible.

* No server needs to change anything other than the name of the cookie it sets. Browsers that support the feature will enforce existing flags, browsers that don't support the feature won't.

* The client-side changes to perform the validation checks are fairly small.

# Compatibility Risk
The syntax is completely backwards compatible with the existing cookie syntax and flags. Worst case, we roll all the code back, and the status quo prevails. The only thing we'd lose in that case are the extra guarantees the prefix would provide.

Mozilla folks are cautiously interested, calling the scheme "ugly, but clever" (https://twitter.com/dveditz/status/652228007910764544).

Edge and Safari haven't said anything (which is understandable, since I only shared the spec yesterday).

Web developers are cautiously interested:

* Eric Lawrence has been pushing for this for a million years.

* Dropbox says they'd probably use it (https://twitter.com/frgx/status/651793265285443584)

* Other folks are concerned about stomping on existing cookies (https://twitter.com/mikesherov/status/652091574248210432) (which I think we can easily mitigate by measuring cookie names and picking an unused prefix), and Ryan suggested that it might be bad precedent to set (https://twitter.com/sleevi_/status/652387624548704256) (which I think we can head off by pointing to the fact that this proposal adds zero _new_ functionality that isn't already covered in the spec).

*shrug* I think it's well worth experimenting with.

# Ongoing technical constraints

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 Chrome Platform Status

https://www.chromestatus.com/features/4952188392570880

# Requesting approval to ship

No. I proposed this yesterday, it might be completely nuts. CCing abarth@, who probably can explain why that might be the case. :)

-mike