Subject: [websec] Resuming the cookie discussion

From: Trevor Perrin <[email-masked]>
Date: Mon, 19 Aug 2013 17:44:11 -0700

To pick this up again, it would be great to have:

 (a) Some cryptographic binding for cookies, either using asymmetric
crypto (ChannelID) or symmetric (Smart Cookies), to prevent them being
useable when transferred between browsers.

 (b) Some origin-binding for cookies to prevent them leaking to
subdomains and being forced by other domains (Origin Cookies).

Both (a) and (b) address the threats of cookie-forcing and
cookie-stealing, but neither is a complete replacement for the other:

 (a) Cryptographic binding of cookies would not prevent an attacker
who controls related domains from:
  - deleting cookies
  - stealing a cookie from user A and then forcing it back to A,
later, to roll-back the cookie to an earlier value

 (b) Origin binding of cookies would not protect against a failure in
TLS confidentiality that exposes the cookie's value.

Questions
=========
 * Are both (a) and (b) worth doing?  Should we prioritize one?

 * Regarding ChannelID vs Smart Cookies:  ChannelID provides a
"bindable" identifier that could be used for other things besides
cookies (OAuth tokens? other?).  But it also requires TLS changes and
an additional signing operation on the client.  The Smart Cookie
approach is more efficient but also narrowly scoped to cookies.

Do people have other arguments, or strong feelings, one way or the other?

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Aug 2013 08:39:44 +0000

Hi Trevor. 

I think (a) is definitely worth doing, but I also think that (b) can be done along the way. Is there some reason why (a) and (b) can't be requirements filled by a single mechanism?

Regarding smart cookies vs channel ID: Not changing TLS is a definite advantage of Smart Cookies. Reading that message again ([1]), I'm not sure whether the cookie_binding is necessary, but I get that it protects against passing cookies. The only issue I have with this is that it relies on extractors, and so will break at TLS proxies. While this is good from a security perspective, it's a killer for deployment. I think that Channel ID works in the presence of proxies, assuming the proxies are updated and move the encrypted extension unchanged.

Yoav

[1] http://www.ietf.org/mail-archive/web/websec/current/msg01729.html

On Aug 20, 2013, at 3:44 AM, Trevor Perrin <[email-masked]> wrote:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 20 Aug 2013 11:01:15 -0700

On Tue, Aug 20, 2013 at 1:39 AM, Yoav Nir <[email-masked]> wrote:
> Hi Trevor.
>
> I think (a) is definitely worth doing, but I also think that (b) can be done along the way.

Interesting...  If we were to prioritize them, I'd argue the reverse:
(b) ("Origin Cookies") strikes me as the most economical, since it
fully addresses cookie-forcing and stealing provided TLS is secure.

> Is there some reason why (a) and (b) can't be requirements filled by a single mechanism?

That's exactly what Smart Cookies attempt - they have origin-binding,
*and* cryptographic-binding via MAC.

But I don't know whether that's the best approach.  It might be easier
to push things like ChannelID and Origin Cookies separately.

> Regarding smart cookies vs channel ID: Not changing TLS is a definite advantage of Smart Cookies. Reading that message again ([1]), I'm not sure whether the cookie_binding is necessary,

It's necessary so the transmitted MAC doesn't become a "bearer token"
that could be re-used by anyone.

> but I get that it protects against passing cookies. The only issue I have with this
> is that it relies on extractors, and so will break at TLS proxies. While this is good
> from a security perspective, it's a killer for deployment. I think that Channel ID
> works in the presence of proxies, assuming the proxies are updated and move
> the encrypted extension unchanged.

I assumed that both Smart Cookies and ChannelID would break at TLS
proxies until those proxies are updated to pass some information
downstream.  And then would work.

Since Smart Cookies don't affect the bytes-on-the-wire, whereas
ChannelID modifies the Handshake protocol, I was also assuming Smart
Cookies would be the easier change.

Is that wrong?

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Aug 2013 04:03:05 +0000

> fully addresses cookie-forcing and stealing provided TLS is secure.

(a) addresses the cookie-as-bearer-token issue that makes BEAST and CRIME something that people write "The Internet is broken" blog posts about rather than just a curious result that cryptographers and crypto-geeks can get excited about.

> that could be re-used by anyone.

But you bind the transmitted MAC to the TLS session by getting cookie_key extracted from the session. So what you transmit is not a bearer token, as it can't be used in another session. The cookie_binding protects you against someone stealing the cookie during set-cookie, but that's a one-time thing, although it could be worth it.

> downstream.  And then would work.

If Channel ID becomes part of TLS 1.3, proxies would have to be updated. No question there. But once it is, then the new handshake records can just be passed along by the proxy. 

What the proxy can't do, is to make it so that the master secret on both halves of the connection are the same. The proxy performs a handshake with the client and with the server, and then decrypts and re-encrypts everything. So there is no way that the client and server can calculate the same values for cookie_binding and for cookie_key.

> Cookies would be the easier change.

It is an easier change, but I don't see how you can get it to work through a proxy.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 21 Aug 2013 00:21:38 -0700

> But you bind the transmitted MAC to the TLS session by getting cookie_key extracted from the session. So what you transmit is not a bearer token, as it can't be used in another session. The cookie_…

I think you're reversing "cookie_key" and "cookie_binding"?

It's true that the cookie_key could have been sent explicitly by the
server, instead of "extracting" it from the master secret.  But then
we'd be transmitting auth secrets, which we're trying to avoid.

> What the proxy can't do, is to make it so that the master secret on both halves of the connection are the same. The proxy performs a handshake with the client and with the server, and then decrypts…

The "cookie_key" and "cookie_binding" values for a TLS connection can
also be passed from a TLS-terminating proxy to back-end servers.

Trevor

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 26 Aug 2013 23:27:00 +0100

<no hats>
My feeling is that both (a) and (b) would be worth doing.
Though not sure on the best approach yet.
Best regards, Tobias