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

Thomas Fossati <tho@koanlogic.com> Mon, 22 October 2012 16:02 UTC

Return-Path: <tho@koanlogic.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A601C21F8C58 for <saag@ietfa.amsl.com>; Mon, 22 Oct 2012 09:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlDBCxal8b8P for <saag@ietfa.amsl.com>; Mon, 22 Oct 2012 09:02:09 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3956121F8C46 for <saag@ietf.org>; Mon, 22 Oct 2012 09:02:09 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id s14so1902921qcg.31 for <saag@ietf.org>; Mon, 22 Oct 2012 09:02:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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 10.224.194.193 with SMTP id dz1mr4378443qab.0.1350921724977; Mon, 22 Oct 2012 09:02:04 -0700 (PDT)
Received: by 10.49.26.170 with HTTP; Mon, 22 Oct 2012 09:02:04 -0700 (PDT)
X-Originating-IP: [81.134.152.4]
In-Reply-To: <20121018174113.GA11965@1wt.eu>
References: <CALaySJK5JBo1cbsqcX6hyk0gSkDciZkX3o=o+rg9rgNVqBeRhw@mail.gmail.com> <20121018064805.GI7517@1wt.eu> <CAC4RtVBfZujwVN9NG1YyiCAm0yrV3Ufu+_SXtTJL4ZHC42tN6Q@mail.gmail.com> <20121018171129.GO9392@1wt.eu> <CALaySJ+MDaeYNtNdMX8Qzu55xb_PFm6sup200nRHU2EaioEMhw@mail.gmail.com> <20121018174113.GA11965@1wt.eu>
Date: Mon, 22 Oct 2012 17:02:04 +0100
Message-ID: <CAByMhx-y4VoyDvoRGvJ-zTBpwsygE=JjT=EBwBwMZUE=SxuG_A@mail.gmail.com>
From: Thomas Fossati <tho@koanlogic.com>
To: Willy Tarreau <w@1wt.eu>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnCpL6pck1oHq2+bq73/u5YLKn50CFtJjfscXWCdPsxa5tqflH6UPzUrPmM/Tnah9XskXks
Cc: Barry Leiba <barryleiba@computer.org>, saag@ietf.org
Subject: Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=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 <w@1wt.eu> 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"