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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Sat, 20 October 2012 10:17 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 6F09421F855B for <saag@ietfa.amsl.com>; Sat, 20 Oct 2012 03:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.404
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9TbwcGQfzTI for <saag@ietfa.amsl.com>; Sat, 20 Oct 2012 03:17:25 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 28D6B21F84FE for <saag@ietf.org>; Sat, 20 Oct 2012 03:17:24 -0700 (PDT)
Received: (qmail invoked by alias); 20 Oct 2012 10:17:23 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp031) with SMTP; 20 Oct 2012 12:17:23 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/po7Rz7gHpj9stSz4JEXeoDlBLxkgX9UnsKsOEhy CZBVxDxxnXX/do
Message-ID: <50827A2A.8000804@gmx.net>
Date: Sat, 20 Oct 2012 13:17:14 +0300
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
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 <tobias.gondrom@gondrom.org>
References: <CAByMhx90Nk+hsw3PUqunP022av1wSYf0OXxKi6Z1U=-zOe5RzQ@mail.gmail.com> <CAByMhx_82B6ApLjOnj3v6BYU90opPs9MR7U-BLpbg91-FnPQAg@mail.gmail.com> <50826EDE.6000509@gondrom.org>
In-Reply-To: <50826EDE.6000509@gondrom.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: 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: 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

Ciao
Hannes

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:
>>
>>    http://www.ietf.org/mail-archive/web/cfrg/current/msg01307.html
>>
>> Then after a long pause, I brought it to the IETF (http-state WG) in
>> February 2011:
>>
>>    http://www.ietf.org/mail-archive/web/http-state/current/msg01227.html
>>
>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag