On Thu, May 19, 2016 at 3:19 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> 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. 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 admit to below: > 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. 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. > 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. 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. > There are clients where limiting ticket re-use makes sense, these > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
