On Thu, May 19, 2016 at 03:45:26PM -0400, Kyle Rose wrote:
> > 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:
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
