Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

On Mon, Feb 3, 2020 at 10:50 AM Viktor Dukhovni wrote: > > I'll read the post more closely over the next few days and attempt to > summarize where I think we are, and propose a pull request to at least > clarify the issues that motivate potential tweaks to the design. > I find the sentinel idea

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

C.4 is clearly in a context where privacy is needed and by writing "SHOULD NOT" TLS 1.3 takes instead the position there are some cases this is not required. """ C.4 . Client Tracking Prevention Clients SHOULD NOT reuse a ticket for multiple

Re: [TLS] External PSK design team

I’m also interested in helping here for potential applicability for IoT device onboarding. From: TLS On Behalf Of Eric Rescorla Sent: 21 January 2020 14:52 To: Jonathan Hoyland Cc: Björn Haase ; TLS List ; Mohit Sethi M Subject: Re: [TLS] External PSK design team I am willing to contribute.

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Feb 3, 2020, at 1:39 PM, Ben Schwartz > wrote: > > I thought in Case E the goal was that each delivery agent keeps its ticket as > persistent per-process state, to avoid re-querying the global cache. I don't recall discussing such a scenario. In Postfix the cache is shared. There is not

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Feb 3, 2020, at 12:04 PM, Ben Schwartz wrote: > > What is reuse allowing us to optimize in this case? If each process has > its own ticket cache, then reuse doesn't reduce inter-process overhead, > so what is the resource we are trying to economize? The processes do not have their own

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> E. Multiple Ticket Reuse: Client want separate tickets for concurrent connections, that are later reused > Viktor described a case in which a client is split across multiple processes, so could be convenient to have independent tickets that are all retrieved from an initial connection that