Hi,

I tried to send this earlier, but I don't think it went through.

Here's an attempt to summarize the main cookie problems and proposals.

I'd be interested if anyone sees thing differently.


Problems
=========

1) Bearer token problem:
Cookies are transmitted frequently, and if a transmitted cookie is
somehow stolen, it could be used by an attacker.

2a) Cookie scoping (confidentiality):
Cookies set on example.com will typically be sent to all subdomains of
example.com.  So the security of example.com can be undermined by
less-secure subdomains.  Even HSTS/HPKP/TACK/DANE for example.com
could be undermined if a hacker can take over test.example.com, or a
MITM can invent badguy.example.com, since the browser would hand these
attackers the example.com session cookie.  There are partial
mitigations for this, but nothing that could work reliably across all
sites and browsers:

  - Omitting the cookie's "Domain" attribute will cause cookies to be
sent only to "example.com" and not its subdomains (RFC 6265), on all
browsers except IE.   IE seems unwilling to change this, presumably
due to legacy web apps.

  - Setting a cookie's "Secure" attribute will require the browser to
only transmit it over SSL/TLS. However, the subdomain may not have the
same HSTS/HPKP/TACK/DANE/etc requirements as its parent.  HSTS and
HPKP provide "includeSubdomains" to address this (RFC 6797, 14.4).
However, it's common for example.com to have subdomains that can't
comply with HSTS or HPKP (for example: mobile.example.com doesn't use
SSL; images.example.com is hosted on a CDN; test.example.com has a
self-signed cert, etc).  In these cases, "includeSubdomains" can't be
used.

2b) Cookie scoping (integrity):
Cookies set on webmail.example.com can be overwritten or deleted by
its subdomains, regardless of the "Secure" or "Domain" attributes.
Also, example.com and its subdomains could set an identically-named
cookie for Domain=example.com, which will get sent to
webmail.example.com.  "Forcing" a cookie on the victim could allow an
attacker to log a victim into the attacker's account.  The victim
might then enter credit card numbers or other data, similar to the
"login CSRF" attacks in [1].

This is harder to mitigate than 2a, as "Domain" and "Secure"
attributes have no effect, and the scope of hostnames that can affect
a victim hostname is not just the victim's subdomains, but everything
sharing the same TLD+1 domain (*.example.com, in this case).


Proposals
==========

1) Origin Cookies:
http://tools.ietf.org/html/draft-abarth-cake-01
http://w2spconf.com/2011/papers/session-integrity.pdf

This adds an "Origin" attribute to cookies.  Such cookies are
backwards-compatible with old browsers.  New browsers would only
return them to the hostname that set them, via an "Origin-Cookie"
header, thus fixing 2a.  To fix 2b, the browser might have to always
send something like "Origin-Cookie-Support: true" as an HTTP header,
so that an Origin Cookie supporting server would know to disregard
old-style cookies that might have been forced on the browser.

This doesn't fix the "bearer token" aspect of cookies, but it seems a
simple, clean fix to the scoping problems.  What happened to this?


2) ChannelID
http://tools.ietf.org/html/draft-balfanz-tls-channelid-01

The browser adds an ECDSA public key and signature to every TLS
handshake.  The server can implement "Channel-bound cookies" which are
associated with the public key.  Such cookies can't be transferred
from one browser to another.

This solves the "bearer token" aspect of cookies.  It also solves a
big part of the scoping problem, since an attacker can't steal usable
cookies, or force her cookies on someone else.  However, since the
same ChannelID public key is used for an entire TLD+1, an attacker who
could hack subdomain hosts or perform MITM could still:
 - Delete cookies
 - Steal a cookie from a user at A.example.com, and force it on the
same user at B.example.com
 - Steal a cookie via a subdomain and then force it later on the same
user to "rollback" to an earlier state

This also modifies the TLS stack, and adds a client-side signature
computation to every TLS session.


3) Session Continuation Protocol
http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00

Instead of cookies, the server can set a symmetric "session key" into
the browser, and specify a range of hostnames to use it for.  The
browser will send a nonce, and a MAC over the nonce, for every
connection to those hostnames.

Since the nonce and MAC, if stolen, would suffice as a bearer token,
this doesn't solve 1.  Since the Host-Scope of the session can be
specified arbitrarily, this solves 2a but not 2b.


4) HTTP Session Management
http://tools.ietf.org/html/draft-hallambaker-httpsession-01

This is similar to (3), except the MAC can optionally be calculated
over "portions of the HTTP message", and the scoping rules are defined
to be identical to cookies as defined somewhere (not specified).  This
might mitigate 1 somewhat, since a MAC, if stolen, could only be used
to replay requests similar to the stolen one.  Cookie scoping problems
don't seem to be addressed.


Trevor


[1] http://seclab.stanford.edu/websec/csrf/csrf.pdf