On Thu, Mar 05, 2020 at 06:15:26PM -0500, Viktor Dukhovni wrote: > It isn't just the impact on client ticket cache processing, whatever it > might be. Tickets can be quite large when client certs are in use, > because various TLS APIs promise server applications the ability to > return the client cert (or full chain) at the completion of the > handshake, which means recording the client cert or chain in > the ticket.
FYI, I accept that this is so, but IMO APIs should allow apps to, and apps should, specify what to save in the tickets, so that we can have a useful compression of the client certificate and chain. > And with PQ certs about to get substantially bigger than RSA certs, I > don't see why carefully designed servers and clients need to engage in > wasteful network traffic, CPU and I/O costs. See above. > In the case of Postfix, the new ticket has to be generated, encrypted > and transmitted by the server, received and decrypted by the client, > then base64 encoded and transmitted to the tlsmgr(8) process, which > stores it an LMDB or Berkeley DB database, incurring I/O costs to > store it (likely also an fsync). Well, users should configure the ticket DB to land on tmpfs, or you should force it to be so, since the DB is ephemeral. Or just use an in-memory DB if you don't need to share it. > With spinning rust the MTA's throughput is largely limited by the number > of synchronous writes to disk per second, and additional synchronous > writes degrade overall throughput. Meh. It's the wire bandwidth and server cycle waste issues that convince me. Nico -- _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
