Re: [TLS] Resumption ticket/PSK

2016-05-19 Thread Kyle Rose
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 On Thu, May 19, 2016 at 4:37 PM, Martin Thomson wrote: > On 19 May 2016 at 16:01, Viktor Dukhovni

Re: [TLS] Resumption ticket/PSK

2016-05-19 Thread Kyle Rose
On Thu, May 19, 2016 at 3:19 PM, Viktor Dukhovni 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

Re: [TLS] Resumption ticket/PSK

2016-05-19 Thread Viktor Dukhovni
On Thu, May 19, 2016 at 03:09:23PM -0400, Kyle Rose wrote: > On Thu, May 19, 2016 at 3:05 PM, Viktor Dukhovni > 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

Re: [TLS] Resumption ticket/PSK

2016-05-19 Thread Viktor Dukhovni
On Thu, May 19, 2016 at 11:31:53AM -0700, Eric Rescorla wrote: > 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,

[TLS] Resumption ticket/PSK

2016-05-19 Thread Kyle Rose
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