Hi,

Here's an attempt to combine the benefits of a couple cookie
proposals.  I'm curious what people think...


"Smart cookies"
=============

Rationale
----------
The "Origin Cookie" proposal seems a good solution to cookie scoping.
The "ChannelID" proposal seems a good approach to the "bearer token"
problem, but requires on-the-wire TLS changes and a client signature
for all TLS connections.

Smart cookies combine the benefits of both proposals, and don't
require TLS changes or client signatures.

Smart cookies are bound to the Origin, and cannot be read or written
from other Origins.  Smart cookies are also cryptographically bound to
two TLS connections:
 1)  The TLS connection on which the server set the cookie
 2)  The TLS connection on which the client is returning the cookie

This binding is done by a cryptographic "MAC" sent from browser to
server along with each smart cookie.


The "smart" attribute
----------------------
Smart cookies are set the same way as normal cookies, but have an
additional "smart" attribute:

  Set-Cookie: session=123; secure; smart;

Smart cookies SHALL only be set from HTTPS connections.  The "domain"
attribute MUST be omitted, and the "secure" attribute MUST be present.

Smart cookies are backwards-compatible.  Older browsers ignore the
"smart" attribute, and return it as a regular cookie.  A smart cookie
aware browser does two extra things:

 (1) The smart cookie is bound to the Origin that set it.  The smart
cookie is only returned to that Origin.  The smart cookie can only be
overwritten by that Origin.  If a smart cookie is being returned, any
cookies with the same name stored in parent domains are ignored.

 (2) When returning a smart cookie, the browser returns an associated MAC, e.g.

  Cookie: session=123
  Smart-Cookie-MAC: session=lMVoh17EQNE1Rd6nT+hh6A==


MAC calculation
----------------
The MAC is calculated as follows:

  - cookie_str: HTTP Request line for cookie ("Cookie: session=123")
  - cookie_key: 32 byte secret key derived from the TLS master secret
for the connection on which the server sent the cookie.
  - cookie_binding: 32 byte value derived from the TLS master secret
for the connection on which the client is returning the cookie.

(The key and binding values are derived using RFC 5705 with labels
"smart_cookie_key" and "smart_cookie_binding".)

  MAC = HMAC-SHA256(cookie_key, cookie_binding || cookie_str)[0:16]


Key handling
-------------
The browser can easily calculate the key and binding values for every
TLS connection.  For every smart cookie the browser receives in a TLS
connection, the browser stores the connection's cookie_key with the
cookie.  For every smart cookie returned to the server in a TLS
connection, the browser uses the cookie's key along with the
connection's binding value to calculate the MAC.

The cookie_key values are secrets which the browser MUST never send
over the network, or make accessible to javascript.


Advertising support
--------------------
Browsers MUST advertise support for smart cookies in every HTTP
Request with "Smart-Cookies: true".  This lets the website allow
legacy clients to use old cookies, while requiring smart cookies for
capable clients so they are protected from cookie forcing.


Misc
-----
 * A website can have stateless smart cookies by including the
cookie_key in the cookie, and encrypting the cookie to itself.  On
receiving such a cookie, the website will decrypt it, then check its
MAC.
 * A website could ignore the MAC values, and just use smart cookies
for their origin-binding properties.
 * An attacker who somehow observes a transmitted smart cookie and MAC
can't replay it on a different TLS connection (as it's tied to its
connection's binding value), and can't calculate the MAC for a
different connection without the cookie_key.


Trevor