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

[Watson Ladd <[e-mail]>]

On Thu, Jan 23, 2020, 4:41 AM Viktor Dukhovni <[e-mail]>
wrote:

> 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.
>

Sending a new ticket doesn't force clients to store it.

>
> 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;
>

What if we reverse the 0 and 255 case, and use the number 1 to mean 1? Now
the code is a no-op.

I still don't get the savings: tickets are free for the server and clients
can always not store them. With 0-rtt single use tickets are a lot more
compelling.


>     /* 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>