Subject: Re: [websec] Resuming the cookie discussion

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 Sep 2013 12:06:48 -0400

In the light of PRISM we rediscovered the benefit of Forward Secrecy.

Forward Secrecy isn't a perfect defense and if TLS works completely as we
believe it to then it is an unnecessary one. But we know that TLS with
Forward secrecy is worth having because it increases the work factor to the
attacker by several orders of magnitude. Instead of breaking the server
public key the attacker now needs to break one key per cryptographic
session.

Reinforcing Cookies is a similar proposition, TLS should be enough to
secure the cookies but if we can reduce the window of vulnerability to an
attacker from allowing them to compromise any exchange to only being
vulnerable on the first then we vastly increase the work factor.

The part that I now consider to be insufficiently thought out in the
proposal is that it assumes that the only parties involved are the client
and the server. This is not the case. There is also an application layer
within the server and changing that would be painful.

So I am now thinking of a scheme where the client and the server can
conspire to encrypt and authenticate the cookies such that the applications
on the server are unaware this is happening (as per TLS and socket security)

The handshake I am thinking of is

Client:  'I do this new thing, here are some crypto params'
Server: 'why yes, here is the encrypted cookie data and the information to
calculate the secret'

Client: here is your encrypted cookie, re-encrypted under the secret, the
MAC

Bind to the TLS session naturally, also include forward secrecy.