Subject: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my))

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 13:27:54 -0700

On 3 September 2014 13:12, Karthikeyan Bhargavan
<[email-masked]> wrote:
> The question is what is the identity of S that C should use when storing the ticket?
> Can we give some recommendations?

The only basis we really have is the identity that was originally
sought.  We still want to permit different certificates (if not
different names), so knowing identity prior to committing the first
flight is of marginal utility anyway.

If an attacker can masquerade as a valid origin, then I don't think
that we should be specifically concerned that it can produce tickets
that cause it to access information.

It's trivial to force that first flight to go anywhere, but you have
to be able to decrypt it to gain any real advantage.  The attack you
describe requires one of a range of breaks: forcing identical master
secrets, decrypting the session (not just finding a collision in the
MAC), or breaking the previous session.

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 16:12:23 -0500

> MAC), or breaking the previous session.

Almost the exact same words can be said, and definitely the exact same
semantics can be expressed, about stateful session resumption.

That a ticket is small (a small integer index into server-side cache
containing session keys) or large (possibly a session cache entry
encrypted in a server secret key) is an implementation detail that is
*almost* completely irrelevant to the security properties desired
here.

I say "almost" because there is one benefit to encrypted session
tickets: there is but one small key (O(1) storage) to
protect/keep/wipe/rotate/watch on the server side, compared to N cache
entries otherwise, which are O(N) for storage and might well spill
over to swap space and so on.

On the whole encrypted session resumption tickets are much better than
the alternative.

Not having any kind of session resumption would be disastrous if
adopted, surely leading to failure to adopt.

Nico
--

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 15:15:05 -0700

> over to swap space and so on.

Well, the information is out there, so there is always the (hopefully
remote) chance that the ticket itself could be decrypted, which
wouldn't be possible if a reference were used.  Not sure that that's
much of a distinction either.

> adopted, surely leading to failure to adopt.

There was some early talk about whether it might be needed, but it's
been clear to me at least for some time now that we need resumption.
And tickets do have scaling characteristics that are very appealing.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Sep 2014 22:30:00 +0000

> much of a distinction either.

If the encryption algorithm is not weak, the public exposure of
ciphertext encrypted with a secret key subject to periodic rotation
and disposal, is not significantly different from secret plaintext
subject to periodic rotation and disposal.

The difference is historical implementation shortcuts, dating back
to a kinder/gentler Internet where PFS was rarely used and was not
considered important, or simply not prioritized by the developers.
The shortcuts can and should be addressed, but *outside* the TLS
protocol.

When I get a chance later this year, I'd like to contribute some
of the Postfix key rotation code to OpenSSL, making it much easier
for applications to implement key rotation correctly.  Obviously
the communication with some sort of cluster-wide store would still
need to be abstracted via a callback, but the logic of when to
rotate keys, caching the current and previous key, ... can be
implemented in a generic way.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 18:00:58 -0500

> much of a distinction either.

That's just as true of any other ciphertext, including the entire TLS
connection's.  We have no choice but to trust our ciphers, otherwise
we're done here.  (Well, we always have one more choice: design new
ciphers.  But let's not go there.)

The point is that the session tickets, if encrypted with a decent
cipher (and mode) should be as secure as all TLS ciphertext.  And
tickets are no more appealing a target of cryptanalysis than, say, the
TLS handshake.  We have to trust the crypto from this point of view.
(While where we're working on the crypto algs we must work to make
them strong enough to be so trusted.)

> And tickets do have scaling characteristics that are very appealing.

Exactly.

Nico
--

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 17:29:01 -0700

> them strong enough to be so trusted.)

Generally, I agree.

The only difference here being that there is no agreement.  The client
has essentially no say on what level of protection is employed.

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 19:35:33 -0500

> has essentially no say on what level of protection is employed.

The client also expects the server not to betray it in a myriad other ways.

Nico
--

---

From: Brian Sniffen <[email-masked]>
Date: Wed, 3 Sep 2014 22:03:46 -0400

> TLS handshake.  We have to trust the crypto from this point of view.

That's true for a secrecy goal.  But is it the same for privacy?

Does it matter that a browser will retain tickets, which identify
conversational partners, for a while---and even if the browser cache,
DNS cache, cookie store, etc., are cleared?

-Brian

-- 
Brian Sniffen
"I reserve the right to evolve my views, and state that views I previously
 expressed may have been somehere along the spectrum from insufficiently
 nuanced through ill-informed to dead wrong."

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Sep 2014 02:16:22 +0000

> DNS cache, cookie store, etc., are cleared?

Tickets are I expect typically just part of the cached client-side
session object, at least with OpenSSL, they are not cached explicitly.
There's a lot more of value in the rest of the client-side session
than the ticket.

In fact the ticket is the least interesting part of client-side
state, it does not even contain the identity of the peer, just an
iv, key-id and some ciphertext.  All the fun bits are encrypted by
a key available only to the server.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 Sep 2014 11:12:19 -0700

> DNS cache, cookie store, etc., are cleared?

Yes, it can (and does) matter.  But I'm also interested in making
progress on one thing at a time ;)