On Wed, Jan 22, 2020 at 4:56 PM Nico Williams <n...@cryptonector.com> wrote: > > On Tue, Jan 21, 2020 at 06:19:23PM +0000, Salz, Rich wrote: > > Viktor and I spoke in more detail. The use-case he brings up makes > > more sense to me now. The key observation is that this is not about a > > I also spoke to Viktor, and he explained the motivation in detail. He > really should have done so on the list, but it is this: > > TL;DR: Postfix multi-process ticket cache DB thrashing pain. > > - Postfix (which he co-maintains) is a multi-process service (with > client and server functionality -- it's an MTA, after all) > > - Postfix needs a multi-process ticket cache w/ concurrency > > - OpenSSL provices no such thing, only a single process in-memory > cache, and also callbacks the app can use to implement its own cache, > which then Postfix uses to implement a multi-process ticket cache > > - So, getting unnecessary tickets thrashes Postfix's shared cache, > which costs a fair bit due to synchronization > > > There are two ways to make this tolerable for Postfix: > > - either the TLS server says "here's a ticket and you MUST or MAY > replace the one you already had" > > or > > - the TLS client gets to ask for no unnecessary new tickets > > Now the first alternative would be infeasible to adopt because it would > require new OpenSSL callback APIs, and anyways would be a more invasive > change to TLS than the ticketrequest extension makes.
Nothing says you have to remember tickets, so unless I'm missing something the semantics already are the second one. Am I being silly? Sincerely, Watson _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
