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.
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
