On Thu, May 19, 2016 at 03:09:23PM -0400, Kyle Rose wrote:
> On Thu, May 19, 2016 at 3:05 PM, Viktor Dukhovni <ietf-d...@dukhovni.org>
> 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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
