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@.