On Wed, Jun 24, 2020 at 05:36:24PM -0700, Matt Brubeck wrote: > Has anyone implemented a Gemini client and/or server with support for > 0-RTT data? To the best of my knowledge, no. I don't think anybody has written anything supporting session resumption, either. It's very true that the combination of TLS and one-request-per-connection is a bad combination for latency (although, for what it's worth, I still think the user experience is pretty acceptable even now, and much better than the web). As for "how bad" this is, and whether or not it's a good motivation (as alluded to in other threads) for dropping TLS, it should be noted that, today, we are surely seeing almost the worst possible cases for this. Nobody is using stuff like 0-RTT data, nobody is using session resumption, and most people are using Let's Encrypt certificate chains which are three certs long, and each one uses big RSA keys. We can and should try to do better in this regard. > Any thoughts on which requests can safely use it? (For > example, would it be reasonable to allow early data for all requests > that don't use a client certificate?) In combination with the idea I've proposed previously that any request with non-reversible non-trivial consequences should require a client certificate, that would seem, at first glance, a pretty sensible response to the threat of replay attacks. Regarding TLS session resumption, there is the issue to consider of so-called "prolongation attacks": https://svs.informatik.uni-hamburg.de/publications/2018/2018-12-06-Sy-ACSAC -Tracking_Users_across_the_Web_via_TLS_Session_Resumption.pdf whereby TLS session information which roundtrips from the server to client and back can be used (as can *any* information which roundtrips in this way) for tracking. This could be mitigated easily with client-side policies on maximum session duration, but would be something for implementers to be wary of. Cheers, Solderpunk
---
Previous in thread (1 of 2): 🗣️ Matt Brubeck (mbrubeck (a) limpet.net)