Will TLSv1.3 always send session ticket?

[Benjamin Kaduk]

On Thu, Sep 16, 2021 at 12:40:55PM -0400, Viktor Dukhovni wrote:
> On Thu, Sep 16, 2021 at 09:30:18AM -0700, Benjamin Kaduk via openssl-users wrote:
> > On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote:
> > > 
> > > I don't recall whether OpenSSL makes any effort to or supports deferring
> > > the transmission of session tickets until just before the first
> > > application data transmission from server to client (or else perhaps
> > > just before responding to a received close-notify with a reciprocal
> > > close-notify)
> > 
> > It's not the default behavior, but is supported: you can configure the
> > SSL/SSL_CTX to send zero tickets by default and then manually call
> > SSL_new_session_ticket(), which defers the transmission until there is another
> > write or explicit SSL_do_handshake() call.
> 
> So nothing built-in...  What I had in mind was a built-in behaviour of
> the library to delay session ticket transmission until there's a first
> opportunity to send some application data, which the client application
> can be reasonably expected to read at that point.

While I'm not opposed to having some turnkey solution built in, I do think
that the current default of sending tickets immediately after the handshake
is the correct *default* behavior.  That makes the new session (with ticket
and resumption capability) available to clients right after the handshake,
instead of needing to wait until some actual data from the server arrives.

I'd be interested in hearing your thoughts about what an API/config would look
like to enable the delayed-send behavior.


-Ben