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
