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

Hannes Tschofenig <> Sat, 20 October 2012 10:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F09421F855B for <>; Sat, 20 Oct 2012 03:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.404
X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A9TbwcGQfzTI for <>; Sat, 20 Oct 2012 03:17:25 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 28D6B21F84FE for <>; Sat, 20 Oct 2012 03:17:24 -0700 (PDT)
Received: (qmail invoked by alias); 20 Oct 2012 10:17:23 -0000
Received: from (EHLO []) [] by (mp031) with SMTP; 20 Oct 2012 12:17:23 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/po7Rz7gHpj9stSz4JEXeoDlBLxkgX9UnsKsOEhy CZBVxDxxnXX/do
Message-ID: <>
Date: Sat, 20 Oct 2012 13:17:14 +0300
From: Hannes Tschofenig <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Tobias Gondrom <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
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: Sat, 20 Oct 2012 10:17:26 -0000

Is it correct to summarize the proposal in the following way:

  * The server can encrypt and integrity protect a cookie before it 
sends it to the client.
  * No updates are required on the client side, i.e., the client does 
not perform any cryptographic computation


On 10/20/2012 12:29 PM, Tobias Gondrom wrote:
> Hi Thomas,
> thank you for providing the background about this.
> Obviously I didn't know about the IRTF CFRG, as I did not attend that
> IRTF group meeting at the time.
> And I can imagine it can be quite frustrating for you having to explain
> the history and your draft again and again to the different audiences
> and groups over the years. ;-)
> Maybe some thoughts on why I think this would benefit from IETF review:
> I can see the underlying idea and understand the potential use case of
> storing state on the client in an encrypted container.
> However, I see quite a few potential issues that could arise with this
> draft. I am not saying "don't do it", all I am saying is that I really
> think this deserves IETF review (either in saag, or even better an IETF
> WG (not IRTF).
> Just as an example: already the very first sentence in the introduction
> some assumptions are half-true/half-false (like e.g. that cookies would
> be "... un-authenticated and sent in clear text." In many applications
> (though not all of them) cookies are in fact transmitted over HTTPS and
> in an authenticated session and not in clear-text...)
> A number of questions with this drafts make me suggest that IETF review
> is a good thing (including the question whether IETF wants to do this at
> all):
> - is the underlying use case valid for the draft? I am not sure of that.
> - the text of the draft would hint towards status as Experimental, not
> as Informational? Why Informational?
> - Is there the vision of interoperability between different
> implementations for this?
> Please note, that I don't deny at all, that there is a security
> considerations section - and in the case of this draft, I actually like
> that it is quite detailed on security implications compared to some
> other drafts I've reviewed in the past years, but I would question
> whether in fact suggesting to store server state only in a client is a
> good idea at all, as it opens quite a number of security problems.
> All this leads me to the recommendation to apply IETF review for this
> draft to avoid trouble.
> However, this is only IMHO, for you, saag and the ADs to consider. And I
> have the highest regard for Jim and our other reviewers. So consider
> this just as my 5cents and I will hand over to others on saag (including
> Jim) to comment and decide on whether we should give this more IETF
> review or not...
> Best regards, Tobias
> On 19/10/12 15:32, Thomas Fossati wrote:
>> 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.
>> _______________________________________________
>> saag mailing list
> _______________________________________________
> saag mailing list