Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol

[Thomas Fossati <[e-mail]>]

Hi Willy,

On Thu, Oct 18, 2012 at 6:41 PM, Willy Tarreau <[e-mail]> wrote:
> Basically if used as general purpose cookies, the impossibility to ensure
> non-replay would be a no-go for me as it goes against the principles of
> RFC6265, hence #3.

I beg to disagree.  6265 states:
  "Servers SHOULD encrypt and sign the contents of cookies (using
   whatever format the server desires) when transmitting them to the
   user agent (even when sending the cookies over a secure channel)."
which is the very essence of what SCS does (adding a timestamp too).

No imposition is made by SCS on storing the whole application state in
the cookie, it is just left as a possibility, which comes in handy in
some specific scenarios -- e.g. the home router that can reboot
without asking the admin to re-authenticate.

In fact, if the server wants, it can use the DATA atom to just store a
session id which points to state archived server side, and use SCS to
just "encrypt and sign the contents of cookies"