On Thu, Mar 05, 2020 at 02:49:23PM -0800, Watson Ladd wrote:
> My skepticism is entirely a function of this being a late breaking
> change to a relatively simple proposal, with not very much in the way
> of quantifiable evidence to back up the concern that shared cache
> contention is a big overhead. Is it 1%? .5? 10%? of the total time to
> use a connection. At 10% we definitely need to do something, at .01%
> we almost certainly don't.
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.
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.
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).
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.
--
Viktor.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
