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] Abridged Certificate Compression
> > If you are going to do this, you might as well go the whole hog and > provide a mechanism that allows the client to say if it already has a cert > on file for that particular host, e.g. by means of a digest. > If clients cache intermediates as they go, then reporting that list to a server is an obvious privacy issue. When you restrict to a fixed set, updated in unison, we essentially return to reach Dennis' proposal. Best, Bas ___ 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 Simon, On 15/08/2023 03:41, Simon Mangel wrote: 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]. 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. 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
