Subject: [TLS] Session Lifetime

From: Michael D'Errico <[email-masked]>
Date: Wed, 17 Nov 2010 17:44:17 -0800

Can someone point me to a document that explains why TLS
sessions should expire within minutes of creation, as is
the current practice (that I'm aware of)?

Mike

---

From: Martin Rex <[email-masked]>
Date: Thu, 18 Nov 2010 03:51:23 +0100 (MET)

> the current practice (that I'm aware of)?

I am only aware of an upper lifetime limit of 24h for cached TLS session
in the SSLv3 and TLS specs, e.g. here:

http://tools.ietf.org/html/rfc5246.txt#appendix-F.1.4

For our apps I'm currently shipping a default session cache lifetime
of 15 minutes for the server and 30 minutes for the client.
Although this is a fairly short lifetime, it is perfectly sufficient
to achieve an acceptable ratio of full-HS/resume-HS.
Customers can finetune session cache size and cache lifetime.

I don't know what other implementations and apps are using.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Nov 2010 08:58:38 -0800

The upper limit is just a suggestion anyway.

I'm unaware of any reason why weeks to months isn't acceptab;e.

-Ekr

On Wed, Nov 17, 2010 at 6:51 PM, Martin Rex <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Seth David Schoen <[email-masked]>
Date: Mon, 29 Nov 2010 09:59:12 -0800

> I'm unaware of any reason why weeks to months isn't acceptab;e.

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.

https://www.isecpartners.com/files/iSEC_Cleaning_Up_After_Cookies.pdf
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1446862

Session resumption can have this effect too.

Of course, this concern is attenuated for sites where users have
to log in and have only one account, but it could be meaningful on
HTTPS sites where users have no account or have multiple accounts.

A separate performance consideration is that ideally the client
and server should have matched expectations about how long to
expect sessions to persist -- whether that's "not at all" or "a
year".

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 29 Nov 2010 11:05:42 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Seth
> David Schoen
> 
> 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.

Isn't this implementable purely as a client-side control though?  It isn't a question for the spec, and isn't something that the client and server should really negotiate.  Now, being transparent as a policy choice, ok, and maybe that is all you were answering?

- Andy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Nov 2010 10:45:20 -0800

> HTTPS sites where users have no account or have multiple accounts.

So, that's certainly true (and of course CSSC offers an even more powerful
mechanism
in this respect), but I don't generally feel that lifetime is that useful a
way to control this.
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.

> expect sessions to persist -- whether that's "not at all" or "a

It's not clear to me that that's that useful. 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.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Mon, 29 Nov 2010 15:20:12 -0600

> subject to user control like cookies.

I agree that this is important. An unauthenticated active attacker can 
query your browser to find out if you've contacted specific servers 
recently. It reveals information in-the-clear.

I'm not aware of any client implementations that persist sessions across 
a browser restart. (Scratch that - testing with a friend who has one of 
those phones that start with a lower-case letter showed that even 
"exiting" the browser, locking the phone, etc. would not clear session 
cookies.) With all the trouble can takes to get session resumption to 
happen effectively in application code, it never seemed like a big deal 
in practice. An https site was one that you probably wanted to 
authenticate to anyway.

But things have changed. TLS clients are on phones now and may stay 
running in the background for long periods. Unlike computers of old 
(battery^network), mobiles may initiate a session from a trusted network 
and then later connect to an untrused network.

Say an attacker wishes to penetrate example.com. He hangs out in a 
coffee shop across the street with a wifi device in his pocket. He 
conducts an active attack on random nearby wifi devices using 
established techniques. An example.com at the coffee shop loads an 
unencrypted web page. Attacker inserts innocuous resource load from the 
target server "https://bugzilla.example.com", attacker observes TLS 
Client Hello offering resumption. The attacker has strong evidence that 
this computer belongs to a targeted user and the browser probably has 
session cookies for internal applications. If bugzilla hasn't set its 
session cookie to secure, the attacker can obtain it by injecting a 
request for a resource from the unencrypted http://bugzilla.example.com/ .

This is not really a new attack, and there are other ways to fingerprint 
the target machine (it's probably broadcasting around for 
exchange.example.com anyway). But the resumption is a contributing 
factor. Note that neither the user nor the network firewall sees any 
suspicious packets in this attack.

Perhaps the only fix would be for clients to cut the resumption time 
down to a minute or two (after closing the last active socket maybe?). 
If the majority of resumptions are simply browsers opening multiple 
connections anyway, this might not have too bad an effect on resumption 
rates.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Mon, 29 Nov 2010 23:33:10 +0100 (MET)

Eric Rescorla wrote:
> Seth David Schoen wrote:
> > Eric Rescorla wrote:
> > > 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.

> 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