Re: [TLS] Session Lifetime

Martin Rex <mrex@sap.com> Mon, 29 November 2010 22:32 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9DCB28C134 for <tls@core3.amsl.com>; Mon, 29 Nov 2010 14:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.103
X-Spam-Level:
X-Spam-Status: No, score=-10.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1lXy77Ef3sg for <tls@core3.amsl.com>; Mon, 29 Nov 2010 14:32:07 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 6FD1F28C10F for <tls@ietf.org>; Mon, 29 Nov 2010 14:32:07 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oATMXCw1004704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Nov 2010 23:33:12 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201011292233.oATMXA7H023574@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Mon, 29 Nov 2010 23:33:10 +0100 (MET)
In-Reply-To: <AANLkTinHOsywLxh3c-RSWVoqQE9rMKz-nGgqzuJM9gk-@mail.gmail.com> from "Eric Rescorla" at Nov 29, 10 10:45:20 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Session Lifetime
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Nov 2010 22:32:08 -0000

Eric Rescorla wrote:
> 
> Seth David Schoen wrote:
> 
> > Eric Rescorla wrote:
> >
> > > The upper limit is just a suggestion anyway.
> > >
> > > I'm unaware of any reason why weeks to months isn't acceptable.

Well, it spoils "Perfect Forward Secrecy" (for TLS cipher suites that
are capable of PFS) if the Server hangs on the the master secrets of
TLS sessions for weeks.

In general I'm very pro "pinning certs", but if there are PKI credentials
involved in a TLS authentication, some may want to perform a re-validation
of those PKI credentials every once in a while, and and in some software
architectures, that validation might be limited to the PKI code of
the certificate path validation that is performed during a full TLS
handshake only.

In some environments, PKI credentials might be lifetime-limited for
reasons other than ensuring the business model of third-party CAs.


>
> > One concern is that resumed sessions work like cookies to identify
> > users, but users may not have convenient ways to control them as
> > they can control cookies.  There has been recent concern about
> > browser functionality that is equivalent to HTTP cookies but not
> > subject to user control like cookies.
> 
> Rather, the same mechanisms that blow away all other browser state
> (e.g., private browsing mode,, clear cookies,etc.) should also blow away
> session state.

Full ack.  But privacy issues associated with the client-side TLS session
cache might be non-obvious to _some_ app folks calling TLS, so sensible
defaults on the session lifetime wouldn't hurt.


> 
> If the client just keeps session state as long as is convenient,
> then the server can extract close-to-optimal performance with no
> additional protocol effort.

Full ack.

While the server may be trying to optimize for CPU overhead,
round-trips & network bandwidth and memory consumption of cached sessions,
a client may have slightly different objectives.  If client certs are
involved, and the access to the client credentials requires an
interactive query to a user, some client may have a higher interest
in long use of cached sessions.


-Martin