On Thu, Jan 23, 2020 at 12:57:31PM +0100, Hubert Kario wrote:

> > The deployed base of Postfix servers issues multi-use tickets (always,
> > there's no extension to tell me otherwise), and sends zero tickets
> > on resumption, so I need to not just throw away tickets that are
> > still valid.
> 
> I wonder if the approach with a database with strict ACID-ity is the 
> correct one for ticket storage.

It isn't "strict acidity", but there never more than one ticket per
peer, stores replace the existing entry, loads read the latest entry
stored.

> What I mean, is that, especially in postfix case, using slightly older 
> ticket that it could will have minimal impact on the connection.

Slightly older is unavoidable, because time passes between configuring
an SSL connection to use a particular session and actually using it.

If tickets rotate too fast, busy Postfix SMTP clients will frequently
end up with stale tickets, and will fail resumption much of the time.

The server accepts reuse, and defaults to assuming that the client is
willing to reuse.

If the extension provides a tiny bit more signalling at no cost to
applications that have no use for reuse, then I'll be able to also
support clients that explicitly signal non-reuse (e.g. MUAs talking
to a service that is both MSA and SMTP relay).

> Thus a database that is basically append only, with clients that look
> for newest ticket (and disregard races on this lookup) and a
> garbage-collection process that removes old tickets every few hours
> will work ok.

There is indeed a GC process, but we're using off-the-shelf indexed
file dabases (Berkeley DB or LMDB), which are not append only.  And
in any case, this is rather tangential.

The real issue is that I'd like to offer clients that don't reuse a
fresh ticket, but allow clients that do reuse to continue to do that.

Anyway, I wanted to avoid TL;DR, and just present an argument based
largely on:

    - No actual complexity to those that don't ever want reuse
    - Pontential savings to those who for some reason do reuse.

That really ought to be enough, given that ignoring the reuse
case and always issuign a ticket is *free*:

    /* Hande non-use, ignore reuse, and impose local limit */
    if (ticknum == 0) ticknum = 1;
    else if (ticknum == 255) ticknum = 0;
    else if (ticknum > ticklimit) ticknum = ticklimit;

    /* now proceed as in previously solved problem */

  v.s. extension as-is:

    /* Impose local limit */
    if (ticknum > ticklimit) ticknum = ticklimit;

That's a totally trivial change that yields status-quo, but allows other
implementations to do something more intelligent with "ticknum == 0".

-- 
    Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to