TLS 1.3 - Current State and TODOs

[reneme]

Current State (April 2023)

Botan 3.0.0 was released with support of the central pieces of the TLS 1.3 protocol. All missing features can be disabled by not negotiating them during the handshake. Therefore, the state of implementation in Botan 3.0 is usable in production.

The implementation is covered by unit and integration tests (based on RFC 8448 test vectors) and passes the relevant BoringSSL BoGo tests. A fuzzing target for the handshake messages is implemented and run in the CI.

Current Limitations (a.k.a. TODOs)

• TLS 1.3 server implementation
  ([TLS 1.3] Basic Server Implementation #3053)
• DTLS 1.3
• Implementation of the "signature_algorithms_cert" extension
  ([TLS 1.3] Support signature_algorithm_cert Extension #3125)
• Support for OCSP stapling (for both client and server certificates
  ([TLS 1.3] OCSP Stapling #3112)
• Support for early data (0-RTT)
  (regarding the ASIO stream wrapper, see also the remarks in "Future Work" in #3801).
• Support for early secret exporters
• Support for externally provided PSKs ([TLS 1.3] PSK Support #3618)
• Support PSK-based handshake without additional key exchange (PSK_KE vs. PSK_DH_KE)
  (see [TLS 1.3] PSK Support #3618 (comment) for reference in setting up a RFC8448-ish test transcript for this)
• Support "RawPublicKey" in the Certificate handshake message (Feature: RawPublicKey authentication in TLS 1.3 (RFC 7250) #3771)
• Post-handshake client authentication
• Support for the OID Filters extension in the CertificateRequest message
• Generation of TLS record padding bytes
• Support "Record_Size_Limit" in TLS 1.2
• Support "RawPublicKey" in TLS 1.2

Despite the limitations, the TLS 1.3 client and server are fully usable as stated above. All missing features are "optional" in a sense that the TLS 1.3 specification allows to disable them during the handshake.

Added Goodies

• Support for hybrid key exchange (classical EC(DH) + PQC KEM) as defined in this IETF draft
• Experimental implementation of KEM TLS (not planned to be merged upstream at this point)

Documentation

So far, no major changes in the existing API were required. A migration guide for users that come from Botan 2.x is provided.

Internal/Technical TODOs

The TLS 1.3 implementation is being actively developed. As such there is potential for internal refactorings and improvements on the go. A few starting points are listed as "Future Work" in the foundational TLS 1.3 Pull Request and further points might arise.

Separate TLS 1.2 and TLS 1.3 further

Most pressing (from my perspective) is the continued separation of TLS 1.2 and 1.3 code bases with the goal to allow disabling TLS 1.2 at Botan's build time. Furthermore, there is likely potential for significant performance gains by avoiding copying of data in the record and message marshalling. A profiling campaign of the implementation would be beneficial.

Ciphersuites

The cipher suite semantics have changed with TLS 1.3 (they now specify mainly the symmetric crypto). Nevertheless, the 1.2 and 1.3 implementations share a common abstraction for cipher suites which has a lot of blanks for TLS 1.3. We might (or might not) want to find a better split for those

Multi-Buffer API for sending/receiving TLS records

This would allow both us (in the ASIO wrapper: see here for instance) and most likely some downstream applications to avoid copies when funneling data in and out of the stream.

Improve Message Mashalling

Currently, marshalling is done fairly freestyle with some low-level help of the tls_reader.h header and the TLS_Data_Reader class. As this is dealing with most of the buffer manipulation in TLS 1.3, some more safe constructions would be highly appreciated. Maybe BufferSlicer and BufferStuffer (or TLS-specific derivatives thereof) can be helpful here. This might also allow to avoid significant data copying while unmarshalling messages.

Code Duplication in Client_Hello for PSK Binders

This is a significant duplication of message parsing/serialization code tailored for the partial Client Hello for PSK binder calculation. See find_client_hello_truncation_mark(). This should be kept in mind (and solved) when reworking the message marshalling.

References

We have open tickets that have asked for TLS 1.3 in the past:

• Features: TLS 1.3 #2185
• Features: DTLS 1.3 and QUIC #1961

Acknowledgements

This work was supported by the German Federal Ministry of Education and Research through the "Post-Quanten-Kryptografie” program under the project name KBLS.