Re: [TLS] Resumption ticket/PSK

[Viktor Dukhovni <[e-mail]>]

On Thu, May 19, 2016 at 03:09:23PM -0400, Kyle Rose wrote:

> On Thu, May 19, 2016 at 3:05 PM, Viktor Dukhovni <[e-mail]> wrote:
> 
> > 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
> 
> 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.

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.

> > The burden of tracking counter-measures should fall squarely on
> > the client.
> 
> 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.

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.