On Thu, Jan 23, 2020, 4:41 AM Viktor Dukhovni <ietf-d...@dukhovni.org> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
