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

Thomas Fossati <tho@koanlogic.com> Fri, 19 October 2012 14:32 UTC

Return-Path: <tho@koanlogic.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E5E0721F86E9 for <saag@ietfa.amsl.com>; Fri, 19 Oct 2012 07:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kS26GP29ofnF for <saag@ietfa.amsl.com>; Fri, 19 Oct 2012 07:32:53 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4DCA121F86E6 for <saag@ietf.org>; Fri, 19 Oct 2012 07:32:53 -0700 (PDT)
Received: by mail-qa0-f44.google.com with SMTP id 25so164742qao.10 for <saag@ietf.org>; Fri, 19 Oct 2012 07:32:52 -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:content-type:x-gm-message-state; bh=YS3Q0raSVNjqBALc3I4NgEwtxMH7nce3VqOQ1VOcdMw=; b=gVsqf1Y5d0WY2pTbjbcJeRDqK6HT8rmDpg8wr8XutzRJo2HPbp3YacVdZcCh2X4ktY nr6CCEEiwps+R9VpVJNXcReRJuEzFeXS8H3bwYsOku9EI9WNOmE2P0VOupnkmdo1k4vT gemCkujJwAdTCrGCBrb0RM2PIe66pLKikS6Uwjcscs9/Zjeo6RYv7yNwwdt+mHEZJLGr UFD+6mFXLIWHETMLUiRGdX11eYkdTodVfZdqYaBqkcUWPd0udId/ScPp9oPQ+e3qkKLr tNw1svyYLuLOwext9aUByrVACKU3FHWyn+qXfbzYmCZ92l1CAHuQEq5Nxb+T+8fmlG3m HLgA==
MIME-Version: 1.0
Received: by with SMTP id fx2mr838867qeb.1.1350657172607; Fri, 19 Oct 2012 07:32:52 -0700 (PDT)
Received: by with HTTP; Fri, 19 Oct 2012 07:32:52 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <CAByMhx90Nk+hsw3PUqunP022av1wSYf0OXxKi6Z1U=-zOe5RzQ@mail.gmail.com>
References: <CAByMhx90Nk+hsw3PUqunP022av1wSYf0OXxKi6Z1U=-zOe5RzQ@mail.gmail.com>
Date: Fri, 19 Oct 2012 15:32:52 +0100
Message-ID: <CAByMhx_82B6ApLjOnj3v6BYU90opPs9MR7U-BLpbg91-FnPQAg@mail.gmail.com>
From: Thomas Fossati <tho@koanlogic.com>
To: saag@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlFNk9tr++dwjx847RDxCaoRiGBVx9CF06XSyEaw/fdKsrCMdxxBDlKeCOfGvtEiYUrvOT5
Subject: [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: Fri, 19 Oct 2012 14:32:54 -0000

Hi Tobias,

>> - Should this be handled by an existing working group?  Which one?
> Yes.

A little bit of context, to hopefully give everyone the reasons why
and how we are here.

SCS was presented for the first time (to get expert review/feedback)
to IRTF CFRG in September 2006:


Then after a long pause, I brought it to the IETF (http-state WG) in
February 2011:


where I've tried to propose it as a working group item, with no avail.
(Please note that this pre-dates JOSE BoF which was held in March 2011 IIRC.)

So, the natural outcome was to go through ISE, which I've done in December 2011.

In these years, in different occasions it has received extensive
review by a couple of well known and respected security guys -- David
Wagner and Jim Schaad.

The whole shebang is nothing new, just a simple bearer token format
which is suitable for use in HTTP (in cookies and URIs, or any other
HTTP header value).  With the added value that it can be traced back
to a provably secure authenticated encryption scheme.

I've taken the trouble to publish as I though it could provide a solid
and reusable building block for developers, that, as a bonus, are also
given a reference open-source implementation.

The Security Consideration has plenty of material about the possible
risks and related countermeasures / mitigations.  If there's something
that really needs to be said and it's not already there, please state
it precisely and I'll do the needed editing.

I like to hear solid technical comments, I really like it, and I'm
totally open to modify the I-D as long as the proposed modifications
makes it a better document.  This is the sole purpose of going through
the IETF process, after all.

Thanks, Thomas.