Dear all, tl;dr: We plan on updating RFC 7924 for TLS 1.3 and would like to check whether there is interest in the TLS wg.
The TLS Cached Information extension [RFC7924] has not seen significant adoption since its specification. However, we still believe it to be an interesting candidate in upcoming IoT application scenarios. While the extension is referenced in the TLS 1.3 spec, the fingerprint calculation is no longer stable with the changed Certificate message format in TLS 1.3 (cf. [RFC8446], section 4.4.2). That is, the Certificate message can now contain non-static extensions, such as OCSP Status or SignedCertificateTimestamp. As these change on each handshake, simply caching the whole message as specified by [RFC7924] is no longer useful. Would an update to RFC7924 for compatibility with TLS 1.3 therefore be in the interest of the TLS wg? We already have a few ideas on how to update RFC7924 for the Certificate message and TLS 1.3, which we outline in the following. We would appreciate any thoughts about this proposal. Fingerprint Calculation: The main idea is to construct the equivalent TLS 1.2 Certificate message format, which also allows for reuse of a single cache object independent of the TLS version used. The certificate_request_context and extensions entries are removed to calculate the SHA256 fingerprint. In addition to simply omitting certificate_request_context and extensions fields, both the handshake header length and the certificate_list length fields have to be recomputed. The resulting transformation would look like this: TLS 1.3 Certificate message: (as sent in initial handshake) +-----------------------------+ | Handshake header | | (type + 3-byte length) | +-----------------------------+ | certificate_request_context | | (0-length) | +-----------------------------+ | certificate_list length | +-----------------------------+ | +-----------+------------+ | | | cert_data | extensions | | | +-----------+------------+ | | ... | | +-----------+------------+ | | | cert_data | extensions | | | +-----------+------------+ | +-----------------------------+ TLS 1.2 Certificate message: (used for fingerprint calculation) +-----------------------------+ | Handshake header | | (type + 3-byte length) | < length recalculated +-----------------------------+ | certificate_list length | < length recalculated +-----------------------------+ | +-----------+ | | | cert_data | | < | +-----------+ | . copied from TLS 1.3 msg, | ... | . omitting extensions | +-----------+ | . | | cert_data | | < | +-----------+ | +-----------------------------+ Exchange Specification: RFC7924 specifies that on a cache hit, the complete message content is replaced by the fingerprint. With our proposed fingerprint calculation for TLS 1.3, this would make the use of Certificate message extensions impossible. That is because extensions would be excluded in the fingerprint calculation, and could not be transmitted in the abbreviated handshake if only the fingerprint is sent in the Certificate message. We therefore propose to instead only replace the cert_data field of the first certificate_list entry by the calculated fingerprint, and make all other cert_data fields 0-length. When receiving this message, the client can then reconstruct the complete Certificate message, including extensions, using the cached certificate chain. The server's Certificate message in an abbreviated handshake would then have the following structure: +------------------------------+ | Handshake header | | (type + 3-byte length) | < length recalculated +------------------------------+ | certificate_request_context | | (0-length) | +------------------------------+ | certificate_list length | < length recalculated +------------------------------+ | +-------------+------------+ | | | fingerprint | extensions | | < 1st cert_data replaced by fingerprint | +-------------+------------+ | | +-------------+------------+ | | | 0-length | extensions | | < | +-------------+------------+ | . | ... | . other cert_data replaced by 0-length | +-------------+------------+ | . | | 0-length | extensions | | < | +-------------+------------+ | +------------------------------+ Again, length fields would have to be recomputed based on the altered content. The client can now reconstruct the complete Certificate message, including extensions, by splitting the cached certificate chain into certificates, and "filling in" the cert_data fields in the received message. The syntax of the CertificateRequest message changed as well, as it is only constructed using extensions in TLS 1.3. However, it seems that at least for the extensions mentioned in [RFC8446], these only hold static data, such that caching the message as-is might be feasible. While the order of included extensions might still make problems, it may be reasonable to assume that it is stable per TLS server implementation. If any non-static extensions for the CertificateRequest message are proposed in the future, the situation changes. Note: We have already found an adaption for TLS 1.3 in academic work [Schwabe2021], where instead of caching the whole chain, each certificate is cached separately. This however leads to inconsistent signaling, as there is no differentiation between a choice of cached certificate chains and separately cached certificates of a single chain. Cheers and thanks in advance, Simon References [RFC7924] Transport Layer Security (TLS) Cached Information Extension, https://datatracker.ietf.org/doc/html/rfc7924 [RFC8446] The Transport Layer Security (TLS) Protocol Version 1.3, https://datatracker.ietf.org/doc/html/rfc8446 [Schwabe2021] More Efficient Post-quantum KEMTLS with Pre-distributed Public Keys, https://doi.org/10.1007/978-3-030-88418-5_1 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
