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
