Re: Will TLSv1.3 always send session ticket?
On Thu, Sep 16, 2021 at 09:49:31AM -0700, Benjamin Kaduk via openssl-users wrote: > I'd be interested in hearing your thoughts about what an API/config would look > like to enable the delayed-send behavior. A simple boolean SSL_CONF_CMD called something like: -ticket_delay, or -ticket_data_prepend would cause the ticket generation to be deferred until the first application data write from server to client. The API would be either a direct call to set the boolean, or an indirect action via the SSL_CONF layer. This would require a new bit to set the policy in the SSL_CTX that would be inherited by any derived SSL handles. The first data transmission would inspect the desired ticket count computed during the handshake, and send that many tickets, resetting the count to zero. The current immediate transmission of tickets would merely squirrel away the number of tickets to send with the first batch of data. -- Viktor.
Re: Will TLSv1.3 always send session ticket?
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
Re: Will TLSv1.3 always send session ticket?
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.
Re: Will TLSv1.3 always send session ticket?
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. -Ben
Re: Will TLSv1.3 always send session ticket?
On Thu, Sep 16, 2021 at 10:05:44AM +0100, Matt Caswell wrote: > No. Unless you configure the server otherwise OpenSSL will always send > session ticket(s) in TLSv1.3. It may be worth mentioning a discussion from some time back on the TLSWG list started by David Benjamin that notes that in TLS 1.3 it is not always opportune for the server to send post-handshake session resumption tickets unless it is also sending some application data. If the application protocol in question has the client sending first and delivering a large request to the server before attempting to read a response, an "unsolicited" transmission of session tickets from server to client may cause an application protocol deadlock if the client's TCP window is not large enough to accommodate the session tickets withour any client-side reads. This situation can with some justification be argued to be a defect in the TLS 1.3 protocol. 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) -- Viktor.
Re: Will TLSv1.3 always send session ticket?
On 16/09/2021 09:58, Jaya Muthiah wrote: TLSv1.3 does not require the server to send any tickets if it decides not to. What makes it decide NO TO. Here I am particularly interested in OpenSSL implementation only. In OpenSSL it is possible to configure the server to set the number of tickets that are sent - including down to 0. I understand that part that, my query was for any condition not in the user's hand. So let me rephrase - if openssl is configured to send one ticket by calling SSL_CTX_set_num_tickets(), is there a condition under which OpenSSL will not send session tickets? No. Unless you configure the server otherwise OpenSSL will always send session ticket(s) in TLSv1.3. Matt
Re: Will TLSv1.3 always send session ticket?
> TLSv1.3 does not require the server to send any tickets if it decides not to. What makes it decide NO TO. Here I am particularly interested in OpenSSL implementation only. > In OpenSSL it is possible to configure the server to set the number of > tickets that are sent - including down to 0. I understand that part that, my query was for any condition not in the user's hand. So let me rephrase - if openssl is configured to send one ticket by calling SSL_CTX_set_num_tickets(), is there a condition under which OpenSSL will not send session tickets?
Re: Will TLSv1.3 always send session ticket?
On 16/09/2021 07:19, Jaya Muthiah wrote: As I can read from the documents mentioned below, "or not at all" worries me. Is there a situation when a session ticket is not sent at all (other than when reused)? TLSv1.3 does not require the server to send any tickets if it decides not to. By default in OpenSSL a server will send 2 session tickets after a normal handshake, or 1 session ticket after a resumption handshake. There is nothing in the spec about that, so other libraries are very likely to have different policies and defaults. In OpenSSL it is possible to configure the a server to set the number of tickets that are sent - including down to 0. So, yes, there may be situations where the server does not send a session ticket. Matt
Will TLSv1.3 always send session ticket?
As I can read from the documents mentioned below, "or not at all" worries me. Is there a situation when a session ticket is not sent at all (other than when reused)? https://www.openssl.org/docs/manmaster/man3/SSL_CTX_sess_set_new_cb.html Note that in TLSv1.3, sessions are established after the main handshake has completed. The server decides when to send the client the session information and this may occur some time after the end of the handshake (or not at all). https://wiki.openssl.org/index.php/TLS1.3#Sessions In TLSv1.3 sessions are not established until after the main handshake has completed. The server sends a separate post-handshake message to the client containing the session details. Typically this will happen soon after the handshake has completed, but it could be sometime later (or not at all).
