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

Thomas Fossati <> Mon, 22 October 2012 16:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A601C21F8C58 for <>; Mon, 22 Oct 2012 09:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZlDBCxal8b8P for <>; Mon, 22 Oct 2012 09:02:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3956121F8C46 for <>; Mon, 22 Oct 2012 09:02:09 -0700 (PDT)
Received: by with SMTP id s14so1902921qcg.31 for <>; Mon, 22 Oct 2012 09:02:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=IV2qZX4Bs6uRXbRICVR2u+GXzJzd1A9ZQ73baafR13M=; b=HjfTV/BnKcRI593RrHsbtcpXTaLcCPnkTPcOGfDvg9wREfCYA3QbBFmKJ0y077EipC X1z6NqPP7gRycfYn7pz92kv22PcabzBLYQKlnWEbUnzZ53j7nCZAqtrx9Zd1LIdiTQ5e StBSp7jnCgF0Rp2Cpd88Ac22fPJGCcP+WMdnLQckADfaIti1AEZKhOplmebqAg9YLxns yJ1gzrhkEv/KHforg7rXDWTwaBGbXnEfsl/ml6ee7rb6IbqDs0ZLv12DkgFFnUY2ETUj LPSqrxEzSO3wRlsOyJThjw3XiDKoa2Xkhqan1ttHJgZ2frfKAAnu4HPbAgug8oW8FuKr 52YQ==
MIME-Version: 1.0
Received: by with SMTP id dz1mr4378443qab.0.1350921724977; Mon, 22 Oct 2012 09:02:04 -0700 (PDT)
Received: by with HTTP; Mon, 22 Oct 2012 09:02:04 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 22 Oct 2012 17:02:04 +0100
Message-ID: <>
From: Thomas Fossati <>
To: Willy Tarreau <>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnCpL6pck1oHq2+bq73/u5YLKn50CFtJjfscXWCdPsxa5tqflH6UPzUrPmM/Tnah9XskXks
Cc: Barry Leiba <>,
Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Oct 2012 16:02:11 -0000

Hi Willy,

On Thu, Oct 18, 2012 at 6:41 PM, Willy Tarreau <> 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"