[TLS] RFC7924 (Cached Information Extension) Update for TLS 1.3
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 th
Re: [TLS] RFC7924 (Cached Information Extension) Update for TLS 1.3
Hi Dennis, > Can you expand more on the intended use case? When would it make sense > to use a RFC7924-like mechanism over TLS 1.3's session resumption? > > I skimmed RFC 7924 and session resumption seems strictly better as it's > already widely deployed, allows for the DH handshake to be optionally > elided and has the exact same storage requirements (some space required > on the client, none required on the server). We believe it to be useful in cases where the network bandwidth is severely restricted, such that one would want to keep the number of "full" handshakes as small as possible. Session resumption ticket lifetimes are limited to 7 days in TLS 1.3 [RFC8446, sec. 4.6.1], and are often configured to be even shorter [Sy2018Tracking, sec. 5.1.2]. As X.509 certificates (as the most interesting type of cached object) typically have a much longer validity period, the idea is to further bring down the frequency of "full" handshakes (including the server certificate chain) by either opting to uses RFC7924 instead of session resumption, or even combining the two techniques. When combining the two, the full TLS handshake after a session resumption ticket has expired could then be made more efficient using the cached Certificate and/or CertificateRequest message, at the cost of a second client-side cache. Best wishes, Simon References [RFC8446] The Transport Layer Security (TLS) Protocol Version 1.3, https://datatracker.ietf.org/doc/html/rfc8446 [Sy2018Tracking] Tracking Users across the Web via TLS Session Resumption, https://doi.org/10.1145/3274694.3274708 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RFC7924 (Cached Information Extension) Update for TLS 1.3
Hi Dennis, Am Dienstag, dem 15.08.2023 um 13:20 +0100 schrieb Dennis Jackson: > > Two observations: > > > > 1. The reason ticket lifetimes are often shorter than 7 days is > > because they can be used to track user visits. Caching end-entity > > certificates as in RFC 7924 over a long period of time is > > problematic for the same reason. >From my understanding, tracking clients is different in certificate caching compared to session resumption. Tracking users based on cached end-entity certificates only works in the following cases: (1) The server intentionally provides different certificates (e.g., by including identifiers in non-signed parts) to clients, thus making them identifiable based on the provided certificate hash in the ClientHello extension. (2) The client sends a combination of certificate fingerprints that is not narrowly scoped to the server it communicates with, thus revealing information about its previous communication partners apart from the server it tries to communicate with. (3) Not enough clients communicating with the server support certificate caching, such that indicating the cached certificate alone allows for tracking. (1) implies malicious intent by the server from the start and may be noticeable by the client (e.g., initialize two handshakes and compare the certificates it received). This is different from session resumption, where the established session ID/ticket always is unique to a client, even without active tracking intent by the server. (2) sounds like a client-side implementation issue to me, as the client should be able to sufficiently scope its certificate cache to the server based on IP address and/or SNI. (3) is a bootstrapping problem common to all newly-introduced TLS extensions. So, from my view, if the server provides its certificate independent of the client it communicates with, I would argue there is no tracking risk beyond the ability to recognize a client corresponds to SOME other client which communicated with the server before. In that way, the tracking risk of certificate caching would be significantly lower than that of session resumption. I would appreciate opinions on this. Also, I would like to briefly point out the argument Thom Wiggers made w.r.t. storage assumptions (cf. https://mailarchive.ietf.org/arch/msg/tls/lTVPpwqNfm2zQ3bAFYNgHhERakw/) : 1. Der AuthKEM-PSK Ansatz verfolgt dann ähnliche Ziele wie der Caching Ansatz, nur eben Speziell für AuthKEM, da sich gleichzeitig der Handshake / KeyExchange ändert.J 2. : In certificate caching, we store public information, whereas session data has to be kept secret. Best, Simon > > > > > > > 2. Although each individual session ticket lifetime is capped at 7 > > days, you can resume a TLS 1.3 session within the 7 day window and > > receive new session tickets over that connection and so extend the > > resumption window up till the certificate lifetime (subject to the > > tracking risk in (1)). > > > > So if you aren't concerned about tracking and you expect to make at > least one connection per week, session resumption is strictly better. > > If you're making fewer than one connection a week, RFC 7924 is > better, but then you're saving at most 52 handshakes per year per > device (as the max certificate lifetime is ~1 year), so I'd argue the > implementation benefit is pretty small. > > > And if you're concerned about tracking then neither RFC 7924 nor long > term session ticket renewal is appropriate. > > Best, > Dennis > > > > > As X.509 certificates (as the most interesting type of cached object) > > typically have a much longer validity period, the idea is to further > > bring down the frequency of "full" handshakes (including the server > > certificate chain) by either opting to uses RFC7924 instead of session > > resumption, or even combining the two techniques. > > When combining the two, the full TLS handshake after a session > > resumption ticket has expired could then be made more efficient using > > the cached Certificate and/or CertificateRequest message, at the cost > > of a second client-side cache. > > > > Best wishes, > > Simon > > > > > > References > > [RFC8446] The Transport Layer Security (TLS) Protocol Version 1.3, > > https://datatracker.ietf.org/doc/html/rfc8446 > > [Sy2018Tracking] Tracking Users across the Web via TLS Session > > Resumption, https://doi.org/10.1145/3274694.3274708 > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RFC7924 (Cached Information Extension) Update for TLS 1.3
Please ignore that weird German part in the unformatted mail, my mail client strangely hid it from me in the HTML version. Best, Simon Am Freitag, dem 25.08.2023 um 16:18 +0200 schrieb Simon Mangel: > Hi Dennis, > > Am Dienstag, dem 15.08.2023 um 13:20 +0100 schrieb Dennis Jackson: > > > > Two observations: > > > > > > 1. The reason ticket lifetimes are often shorter than 7 days is > > > because they can be used to track user visits. Caching end-entity > > > certificates as in RFC 7924 over a long period of time is > > > problematic for the same reason. > From my understanding, tracking clients is different in certificate > caching compared to session resumption. > Tracking users based on cached end-entity certificates only works in > the following cases: > (1) The server intentionally provides different certificates (e.g., > by including identifiers in non-signed parts) to clients, thus making > them identifiable based on the provided certificate hash in the > ClientHello extension. > (2) The client sends a combination of certificate fingerprints that > is not narrowly scoped to the server it communicates with, thus > revealing information about its previous communication partners apart > from the server it tries to communicate with. > (3) Not enough clients communicating with the server support > certificate caching, such that indicating the cached certificate > alone allows for tracking. > > (1) implies malicious intent by the server from the start and may be > noticeable by the client (e.g., initialize two handshakes and compare > the certificates it received). > This is different from session resumption, where the established > session ID/ticket always is unique to a client, even without active > tracking intent by the server. > (2) sounds like a client-side implementation issue to me, as the > client should be able to sufficiently scope its certificate cache to > the server based on IP address and/or SNI. > (3) is a bootstrapping problem common to all newly-introduced TLS > extensions. > > So, from my view, if the server provides its certificate independent > of the client it communicates with, I would argue there is no > tracking risk beyond the ability to recognize a client corresponds to > SOME other client which communicated with the server before. > In that way, the tracking risk of certificate caching would be > significantly lower than that of session resumption. > I would appreciate opinions on this. > > Also, I would like to briefly point out the argument Thom Wiggers > made w.r.t. storage assumptions > (cf. https://mailarchive.ietf.org/arch/msg/tls/lTVPpwqNfm2zQ3bAFYNgHhERakw/) > : > 1. Der AuthKEM-PSK Ansatz verfolgt dann ähnliche Ziele wie der > Caching Ansatz, nur eben Speziell für AuthKEM, da sich > gleichzeitig der Handshake / KeyExchange ändert.J > 2. > : > In certificate caching, we store public information, whereas session > data has to be kept secret. > > Best, > Simon > > > > > > > > > > > > 2. Although each individual session ticket lifetime is capped at > > > 7 days, you can resume a TLS 1.3 session within the 7 day window > > > and receive new session tickets over that connection and so > > > extend the resumption window up till the certificate lifetime > > > (subject to the tracking risk in (1)). > > > > > > > So if you aren't concerned about tracking and you expect to make at > > least one connection per week, session resumption is strictly > > better. > > > > If you're making fewer than one connection a week, RFC 7924 is > > better, but then you're saving at most 52 handshakes per year per > > device (as the max certificate lifetime is ~1 year), so I'd argue > > the implementation benefit is pretty small. > > > > > > And if you're concerned about tracking then neither RFC 7924 nor > > long term session ticket renewal is appropriate. > > > > Best, > > Dennis > > > > > > > > As X.509 certificates (as the most interesting type of cached object) > > > typically have a much longer validity period, the idea is to further > > > bring down the frequency of "full" handshakes (including the server > > > certificate chain) by either opting to uses RFC7924 instead of session > > > resumption, or even combining the two techniques. > > > When combining the two, the full TLS handshake after a session > > > resumption ticket has expired could then be made more efficient using > > > the cached Certificate and/or CertificateRequest message, at the cost > > > of a second client-side cache. > > > > > > Best wishes, > > > Simon > > > > > > > > > References > > > [RFC8446] The Transport Layer Security (TLS) Protocol Version 1.3, > > > https://datatracker.ietf.org/doc/html/rfc8446 > > > [Sy2018Tracking] Tracking Users across the Web via TLS Session > > > Resumption, https://doi.org/10.1145/3274694.3274708 > > > > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
