Re: [saag] Input for conflict review of draft-secure-cookie-session-protocol
Willy Tarreau <w@1wt.eu> Thu, 18 October 2012 06:48 UTC
Return-Path: <w@1wt.eu>
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 2F86F21F85F3 for <saag@ietfa.amsl.com>; Wed, 17 Oct 2012 23:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.034
X-Spam-Level:
X-Spam-Status: No, score=-5.034 tagged_above=-999 required=5 tests=[AWL=-2.991, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
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 fHS4UEO1bFcK for <saag@ietfa.amsl.com>; Wed, 17 Oct 2012 23:48:10 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4BC21F85EF for <saag@ietf.org>; Wed, 17 Oct 2012 23:48:09 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q9I6m5Tj008940 for saag@ietf.org; Thu, 18 Oct 2012 08:48:05 +0200
Date: Thu, 18 Oct 2012 08:48:05 +0200
From: Willy Tarreau <w@1wt.eu>
To: saag@ietf.org
Message-ID: <20121018064805.GI7517@1wt.eu>
References: <CALaySJK5JBo1cbsqcX6hyk0gSkDciZkX3o=o+rg9rgNVqBeRhw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CALaySJK5JBo1cbsqcX6hyk0gSkDciZkX3o=o+rg9rgNVqBeRhw@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
X-Mailman-Approved-At: Thu, 18 Oct 2012 08:03:40 -0700
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: Thu, 18 Oct 2012 06:48:11 -0000
Hello, I just checked the following document and have one main concern : On Wed, Oct 17, 2012 at 10:25:16PM -0400, Barry Leiba wrote: > A document titled "Secure Cookie Sessions for HTTP" has been submitted > to the Independent Stream Editor (ISE): > http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/ Section 3.3.1.1. mandates the use of the Expires field : SCS cookies MUST include an Expires attribute which shall be set to a value consistent with session_max_age. This means that these cookies will necessarily be stored, they're not just session cookies that expire at the end of the browsing session. But later it is clearly stated in section 8.2.1 that nothing is possible to prevent a stolen cookie from being replayed. This is a big concern because with normal cookies where the server owns the state, the user just has to logout when he suspects a cookie disclosure, this causes his session to terminate and the associated cookie cannot be used anymore. With SCS, it looks like when the user knows his cookie has been stolen, all he can do is wait for its maximum life time to expire. Right now stolen cookies are the main security issue on the web. Banking applications have to live with malware which steal user cookies so that other people can remotely browse on their account. Some malware even do the work in parallel with the user, or wait for the user to become idle to do some operations before he closes the browser. With SCS, it looks like the malware will not need to install in the browser anymore, it will just have to steal the stored cookie and use it at any time even when the browser is closed, since the user has no way to revoke it. Hence, I'm failing to see what specific use case this protocol covers, however I see a risk that it is adopted by users who don't completely understand its security implications. The focus is clearly set on how the cookie contents are secured but not that much on what it should or should not be used for. Regards, Willy PS: please CC me in responses, I'm not subscribed to saag@.
- [saag] Input for conflict review of draft-secure-… Barry Leiba
- Re: [saag] [apps-discuss] Input for conflict revi… Barry Leiba
- Re: [saag] [apps-discuss] Input for conflict revi… Manger, James H
- Re: [saag] Input for conflict review of draft-sec… Willy Tarreau
- Re: [saag] Input for conflict review of draft-sec… SM
- Re: [saag] Input for conflict review of draft-sec… Barry Leiba
- Re: [saag] Input for conflict review of draft-sec… Barry Leiba
- Re: [saag] Input for conflict review of draft-sec… Tobias Gondrom
- [saag] Input for conflict review of draft-secure-… Thomas Fossati
- Re: [saag] Input for conflict review of draft-sec… Tobias Gondrom
- Re: [saag] Input for conflict review of draft-sec… Hannes Tschofenig
- Re: [saag] Input for conflict review of draft-sec… Stephen Farrell
- Re: [saag] Input for conflict review of draft-sec… Thomas Fossati
- Re: [saag] Input for conflict review of draft-sec… Stephen Farrell
- Re: [saag] Input for conflict review of draft-sec… Thomas Fossati
- Re: [saag] Input for conflict review of draft-sec… Willy Tarreau
- Re: [saag] Input for conflict review of draft-sec… Willy Tarreau
- Re: [saag] Input for conflict review of draft-sec… =JeffH
- Re: [saag] Input for conflict review of draft-sec… Tobias Gondrom
- Re: [saag] Input for conflict review of draft-sec… Thomas Fossati
- Re: [saag] Input for conflict review of draft-sec… Thomas Fossati
- Re: [saag] Input for conflict review of draft-sec… Mark Nottingham
- Re: [saag] Input for conflict review of draft-sec… Thomas Fossati
- Re: [saag] Input for conflict review of draft-sec… Barry Leiba
- Re: [saag] Input for conflict review of draft-sec… Stephen Farrell
- Re: [saag] Input for conflict review of draft-sec… Mark Nottingham
- Re: [saag] Input for conflict review of draft-sec… Barry Leiba