Subject: [TLS] Resumption ticket/PSK

From: Kyle Rose <[email-masked]>
Date: Thu, 19 May 2016 14:19:48 -0400

Regarding the ability for passive observers' tracking of clients
across connections (and potentially across IPs) via a session ticket
used more than once, should there be any language around recommended
practice here, especially for clients?

An appropriately-configured server can help the client avoid this
problem without performance penalty by issuing a new session ticket on
every connection (for non-overlapping handshakes) and/or multiple on
one (to cover that gap), and a client can help by keeping only the
most recent ticket for a particular session and/or using a given
ticket only once.

Thoughts on adding language under "Implementation Notes" such as:

"Clients concerned with privacy against tracking by passive observers
SHOULD use a PSK/session ticket at most once. Servers SHOULD issue
more than one session ticket per handshake, or issue a new session
ticket on every resumption handshake, to assist in the privacy of the
client while maintaining the performance advantage of session
resumption."

For pure PSK I assume tracking is less of an issue, but I'm happy to
entertain thoughts there, as well.

Kyle

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 May 2016 11:31:53 -0700

Yes, I think this would be good text. PR wanted :)

-Ekr

On Thu, May 19, 2016 at 11:19 AM, Kyle Rose <[email-masked]> wrote:

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

---

From: Kyle Rose <[email-masked]>
Date: Thu, 19 May 2016 14:59:51 -0400

https://github.com/tlswg/tls13-spec/pull/461

It could probably use some cleaning up ("PSK/session ticket"). Do we
also want a sentence explaining the issue?

Kyle

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 19 May 2016 19:05:08 +0000

> Yes, I think this would be good text. PR wanted :)

I think this is much too complicated.  Simpler solution is for
clients (browsers and the like for which tracking is an issue) to
not reuse sessions when their IP address changes, and/or keep
session lifetime suitably short on the client end.  In addition
implementing a short "idle timeout" for sessions on the client side
would be quite effective.

The burden of tracking counter-measures should fall squarely on
the client.

-- 
	Viktor.

---

From: Kyle Rose <[email-masked]>
Date: Thu, 19 May 2016 15:09:23 -0400

On Thu, May 19, 2016 at 3:05 PM, Viktor Dukhovni <[email-masked]> wrote:

> not reuse sessions when their IP address changes

I don't think this is sufficient. Reusing session tickets will reveal
distinguishing information about individual clients behind NAT exit
points, for instance, even when their internal/RFC1918 addresses don't
change.

> The burden of tracking counter-measures should fall squarely on

I agree that it's up to the client, but there are measures the server
can take to assist the client while not adding to its full handshake
burden. IOW, it helps the server, as well.

Kyle

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 19 May 2016 19:19:31 +0000

> points, for instance, even when their internal/RFC1918 addresses don't

It is good enough.  Clients that want strong protection against
tracking by session ids can disable session caching entirely, or
set an idle timeout of ~5 seconds, Ensuring that session re-use
happens only for a quick burst of connections to the same server.

This is only relevant to a particular type of client, and should
not be default protocol behaviour.

> burden. IOW, it helps the server, as well.

I don't see how constantly generating and transmitting new tickets
helps the server, or helps clients (at fixed network addresses)
that don't need this protection.  Just a waste of bandwidth and
needless churn in the client's session cache.

There are clients where limiting ticket re-use makes sense, these
clients can take appropriate measures.

If some clients desperately want a fresh ticket with every resumption,
I think they should explicitly signal that via an optional new
extension.  I'd have no objection to a zero-length payload extension
that indicates that a fresh ticket is desired even if the session
is resumed.

-- 
	Viktor.

---

From: Kyle Rose <[email-masked]>
Date: Thu, 19 May 2016 15:45:26 -0400

> not be default protocol behaviour.

I suspect the root of arguments for/against this proposal are
philosophical more than technical. I disagree with your contention
above that client-behavior-only is sufficient, because my definition
of "sufficient" includes something about resource usage on the server
in pursuit of the privacy desires of the client, which you implicitly

> that indicates that a fresh ticket is desired even if the session

This IMO *would* be good enough from a technical standpoint.

I can't give you a technical argument for my proposal, because the
question fundamentally isn't a technical one: it's a philosophical one
regarding which properties we want this protocol to have by default. I
can only suggest a requirement that TLS, as a privacy protocol, must
at the very least not add to the ability to track clients. Reuse of
session tickets violates this requirement by adding an identifier
transmitted in the clear that allows a passive observer to track a
client much more easily than it would otherwise be able to do.

> needless churn in the client's session cache.

I'm not sympathetic to the bandwidth argument, given how typically
small these things are. I'm also not sympathetic to concerns about
generation, as session ticket generation is logically limited to
low-cost crypto operations (i.e., not public key crypto) that are
probably not significant in comparison to the rest of the key
derivation schedule: certainly, in the typical case thousands or tens
of thousands can be generated for the cost of a single extra PKC
operation. And nothing about this proposal suggests that a client MUST
not use a session ticket more than once, only that the server offer it
the opportunity to resume a session without doing so.

> clients can take appropriate measures.

My goal is to make it easy for the client to do this in a way that is
efficient for the server. A client can already simply turn off session
caching to gain added privacy, but there are ways to tweak
implementations to help resource-constrained servers, as well.

Kyle

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 19 May 2016 20:01:24 +0000

> in pursuit of the privacy desires of the client, which you implicitly

Well, if a client is not behind a carrier-grade NAT, it is readily
identified by its network address until it obtains a new one.  So
the tracking identifier is at layer 3 and TLS won't change that.

Nevertheless, some clients may want to attempt to gain fine-grained
protection against correlating back to back or parallel resumption
requests.  For this they'd have to ensure that all session tickets
are single use, and either perform new handshakes when increasing
the number of parallel connections to the server, or somehow obtain
more than one ticket within a single session.

The proposal is rather complex, and often still not effective.
For this reason, I'm suggesting that the complexity should not be
specified as a default behaviour.  There's a lot clients can do
unilaterally, and a new extension can be designed to close any gaps
for clients with "greater needs".

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 May 2016 16:37:30 -0400

> more than one ticket within a single session.

I believe that this is the intent of the PR.  I've suggested an
alternative wording that cleaves closer to your text above.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 19 May 2016 20:50:22 +0000

> alternative wording that cleaves closer to your text above.

I'm suggesting that instead of servers guessing that clients want
this, it might make more sense to employ an extension to request
single-use tickets.  Session tickets will often encapsulate the
client certificate, and issuing them on every resumption can
considerably increase the size of the server response.  Many clients
will not benefit, so I'm suggesting that this should be optional.

I've not heard many others chime-in yet, so it is not yet clear
where WG consensus may lie on this question.

-- 
	Viktor.

---

From: Kyle Rose <[email-masked]>
Date: Thu, 19 May 2016 17:13:50 -0400

I've modified the branch to use your wording. As Viktor said, it
doesn't address his objection, but it's still a more precise starting
point for further discussion.

Kyle