Will TLSv1.3 always send session ticket?

[Viktor Dukhovni]

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.

If this is left entirely to applications, many of the less sophisticated
ones might not know to consider the issue.

In my SMTP use-cases, after STARTTLS, the client is expected to send
a short "EHLO" command, and then turn around and read a server response,
so deadlock would require a very small TCP window on the server side,
and/or an unreasonably large (many kilobytes) client EHLO name.

So Postfix does not take any application-layer steps to postpone session
ticket transmission.  I also would not to send session tickets without
an indication that the client did not present a sufficiently fresh ticket,
so handling session ticket generation in the application logic would
become even more complex...

-- 
    Viktor.