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

[Watson Ladd <[e-mail]>]

On Wed, Jan 22, 2020 at 4:56 PM Nico Williams <[e-mail]> 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