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
