💾 Archived View for gemi.dev › gemini-mailing-list › 000253.gmi captured on 2024-03-21 at 17:13:55. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
One of the acknowledged disadvantages of TLS for Gemini is latency. TLS 1.3 has a feature that could mitigate this problem in some circumstances. To quote RFC 8470: > TLS 1.3 [TLS13] introduces the concept of early data (also known as > zero round-trip time (0-RTT) data). If the client has spoken to the > same server recently, early data allows a client to send data to a > server in the first round trip of a connection, without waiting for > the TLS handshake to complete. > > When used with HTTP [HTTP], early data allows clients to send > requests immediately, thus avoiding the one or two round-trip delays > needed for the TLS handshake. This is a significant performance > enhancement; however, it has significant limitations. > > The primary risk of using early data is that an attacker might > capture and replay the request(s) it contains. Has anyone implemented a Gemini client and/or server with support for 0-RTT data? 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?)
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
---