TLS 1.3 Today
Most people are aware of the major change in TLS that occurred with the release of TLS 1.3 in August 2018. Since then, over 54% of websites support TLS 1.3 in most cases alongside support for TLS 1.2. All the major browsers will request to use TLS 1.3 if supported by the web server, so TLS 1.3 is likely to be the most used version of TLS at this point in time.
TLS 1.3 included many enhancements that deliver better performance and stronger security than earlier TLS versions. As there are many sources that detail the benefits provided by TLS 1.3, I’m not going to discuss these here, but instead will focus on what TLS 1.3 enhancements have been developed since its release, or are currently in development. A detailed description of TLS 1.3 and its benefits can be found here.
Isn’t TLS 1.3 a Done Deal?
Well yes, TLS 1.3 is published as RFC 8446, but that isn’t the end of work in the IETF TLS working group. Since TLS 1.3 was published, additional RFCs have been published that relate to TLS 1.3, or that define enhancements to TLS 1.3. In this blog post, I’ll look at a few of these developments and what their significance is for enterprise networking.
TLS Ticket Requests (RFC 9149)
Work on this was started before the publication of TLS 1.3. This enhancement defines a new TLS extension that can be used in a TLS 1.3 or DTLS 1.3 handshake to allow the client to specify the desired number of session tickets it would like the server to dispense during the handshake.
TLS session tickets are dispensed by the server to the client during a TLS handshake and are then kept by the client for future use when the client wishes to reuse the session. Using a session ticket to initiate a reuse session avoids the need for a full TLS handshake, making it more efficient.
RFC 8446 (TLS 1.3) specifies that the server dispense an arbitrary number of session tickets to the client during the TLS handshake. While this behavior works, it is not ideal in a number of situations, such as:
- Different server implementations may choose different arbitrary values, resulting in the number of session tickets received by the client being dependent on the software stack on the server. Implementations may also choose to dispense a different number of session tickets during a full handshake to the number they dispense during session resumption. The variability in what a server may do, while still being compliant with the TLS 1.3 specification, is never going to be ideal for all use cases.
- A client has no way to express how many session tickets it needs which may force future connections to do full handshakes rather than use session reuse. A client may know that it opens parallel TLS connections to the same server in order to work concurrently, but it has no way of letting the server know that it requires “n” session tickets in order to set up “n” concurrent connections for the session.
- Periodically, a server may force a full handshake in response to a session reuse request. The server may do this because it wants to refresh the authentication of the client (when client certificates are in use) or simply to prevent security parameters being used for too long a time period. The server forces the full handshake by refusing to use a session ticket sent by the client in a reuse handshake. If the client has cached a number of session tickets associated with the initial flow, these may be invalid after a new session is established via the full handshake. If the client tries to use the invalid cached session tickets, then the server will use a full handshake losing the efficiency of session reuse. To deal with this issue, the client should flush the cached session tickets and replace them with the session tickets dispensed by the server during the full handshake. In order to replace the cached session tickets, the server may need to dispense more tickets during a full handshake than it would normally dispense during a reuse handshake.
Allowing the client to tell the server the preferred number of session tickets it would like to receive addresses all the issues noted above. The client can specify a different number for a full handshake to what it specifies in a reuse handshake. For example, the client may specify eight session tickets in the case of a full handshake in order to allow concurrent connections to be established, but only one session ticket in a reuse handshake to avoid excess session tickets being generated.
This feature is implemented as an extension to TLS 1.3; a new “ticket request” extension can be sent by the client specifying the number of tickets required in a new session (full handshake) and in a reuse session. If the extension is sent by the client and the server supports the extension, then it will either send back the requested number of session tickets or a smaller number determined by its internal limit on the maximum number it is prepared to dispense. The server also sends a “ticket request” extension back to the client specifying the number of session tickets it is dispensing on this connection.
The benefits from using the ticket request feature are easy to see:
- Clients that intend to use concurrent connections to a server can get sufficient tickets from the server, assuming it implements the feature, to use session reuse to establish the parallel connections.
- Servers can avoid generating more session tickets than required which is beneficial as there is a computational cost in the cryptography to generate session tickets.
Delegated Credentials for TLS
Work on Delegated Credentials started before the publication of the TLS 1.3 specification. There is not yet a published RFC for Delegated Credentials, but there should be soon as the draft document is in the final phase of approval. Despite the fact that there is not yet an RFC, Delegated Credentials have been in use since 2019 by large companies such as Facebook, Cloudflare, and Mozilla.
Delegated Credentials were developed to address a number of issues:
- The need by large Internet sites with many servers to reduce the risk of the private key associated with the TLS certificate used by the sites being compromised. The maximum duration of a public TLS certificate has been reduced over the last few years and is now only one year. Reducing this further has significant consequences as the site is dependent on a public Certificate Authority issuing the certificate, and doing this more frequently will cost more in both administrative time and money. Reducing the lifetime of a certificate to a few days or hours, while desirable, is not achievable if it involves the issuance of new publicly trusted TLS certificates at this rate.
- Smaller enterprise sites also face the risk of the TLS certificate and its private key being compromised if they are held on the server and it is compromised. Storing the certificate and private key in a more secure network HSM helps reduce this risk, but has a performance impact as the server needs to interact with the HSM during every TLS handshake.
- TLS certificates not only provide a public key, they also specify the signature algorithm that the key be used with. Having the choice of signature algorithm specified in the TLS certificate has a number of drawbacks. Only a limited set of algorithms are supported in TLS certificates, so the choice is restricted and the use of more modern algorithms is not possible until the TLS certificate standards change to support their specification.
Delegated Credentials work by allowing a server to provide a delegated credential to the client during the TLS handshake without having access to the site TLS certificate private key. The credential includes a public key and specifies a signature algorithm as well as the duration that the credential is valid for. When generated, the credential is cryptographically tied to the site using the private key associated with the site TLS certificate, allowing the client to authenticate the credential using the site TLS certificate public key. Once the credential is validated, the client then uses the credential’s public key and signature algorithm during the TLS handshake rather than the public key and signature algorithm specified in the server TLS certificate. The server needs the private key associated with the credential rather than the private key associated with the site TLS certificate in order to complete the handshake. The maximum duration of a delegated credential is seven days.
A delegated credential could be created by a server that uses an HSM to store the site TLS certificate and private key, in which case it will generate the private public key pair to be used in the credential and then have the credential signed using the TLS certificate private key held in the HSM. Once signed, the delegated credential is used by the server without any need to access the HSM during TLS handshakes, removing the performance issue noted earlier.
Large Internet sites will typically centralize generation of delegated credentials, in which case the private/public key pair for the credential will be generated by the system creating the credential. Once the credential has been signed using the private key of the site TLS certificate, it can be sent to a server along with the private key associated with the credential, allowing the server to terminate TLS sessions without needing access to the site TLS certificate private key.
A new TLS extension is defined which allows a client to indicate in the Client Hello message that it is prepared to accept delegated credentials if the server wants to use them. The same extension can be used by the server in the Certificate Request message (used if the server is carrying out client authentication) to indicate that it will accept delegated credentials along with the client certificate.
One important point to note is that the public TLS server certificate in use by the site needs to have an X.509 extension (DelegationUsage) indicating that the certificate supports Delegated Credentials. This does mean that the existing site TLS certificate will need to be updated to a new certificate that includes the extension.
The benefits of using Delegated Credentials are significant, particularly for large organizations with many servers. An indication of this can be seen by some of the organizations that have already adopted this approach in advance of the actual RFC being published.
- Facebook is using this approach to reduce the lifetime of TLS certificates down to days or hours as they describe here.
- Cloudflare is using Delegated Credentials in a slightly different way to enable their CDN edge servers to respond on behalf of a hosted site without needing to have the hosted site TLS certificate private key. Details on this can be found here.
TLS is Not Standing Still
The above examples of enhancements to TLS 1.3 are by no means all that is going on with regard to TLS 1.3. There are other developments in progress that are more contentious than the examples mentioned in this blog post. We will take a look at these in a future post.
