>I would like to see examples of these use cases where using QUIC is >impossible, but using >TurboTLS is.
+1 QUIC is the obvious future replacement for TCP, (D)TLS, SCTP, and RTP. I think IETF should focus on QUIC. I think people staying on TLS/TCP need to live with an extra roundtrip. Visibility is likely not a very convincing argument for the TLS WG. Visibility needs to be solved in the endpoints. The sooner people understand this the better. TurboTLS would just delay this transition. Cheers, John From: TLS <[email protected]> on behalf of Bas Westerbaan <[email protected]> Date: Monday, 27 November 2023 at 11:40 To: David Joseph <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [TLS] TurboTLS: handshaking over UDP to remove 1 round trip I would like to see examples of these use cases where using QUIC is impossible, but using TurboTLS is. Best, Bas On Wed, Nov 15, 2023 at 6:37 PM David Joseph <[email protected]<mailto:[email protected]>> wrote: Hi everyone, We wanted to speak about this draft on TurboTLS at 118 but didn't manage to squeeze into the packed session. Forwarding a new draft here that describes an idea for UDP handshaking in parallel to setting up the TCP stream, then switching back to TLS-over-TCP for the session portion. This enables removing one round trip from all TLS versions in the best case, and in the worst case scenario, falling back to TLS-over-TCP with an extremely small latency boost. TurboTLS doesn't change the contents of any TLS messages, only how some handshake messages are delivered over UDP instead of TCP. This technique supports transparent proxying, whereby standard TLS requests can be intercepted and turbo charged, by sitting one proxy in front of both client and server. First client requests are intercepted, translated to UDP, received by the server proxy, translated back to TCP, and sent back without client nor server being aware that their exchange has been turbo charged. Proxying enables legacy systems using all versions of TLS to obtain faster connection establishment without touching their network stack. TurboTLS has most potential where migration to QUIC is not possible in the near term due to legacy servers, or due to firewall visibility/deep packet inspection concerns, yet for systems which handle many short-lived TLS connections per second with non-trivial network latency. We managed to speak with a few of you privately about your thoughts on the benefits and drawbacks of this technique, and would like you to share any more opinions with us below so that we can understand whether it is worth developing this draft further. If this sounds like it might be useful to you/your use case, please get in touch! Kind regards, David ---------- Forwarded message --------- From: <[email protected]<mailto:[email protected]>> Date: Sun, Nov 5, 2023 at 12:43 AM Subject: New Version Notification for draft-joseph-tls-turbotls-00.txt To: Carlos Aguilar-Melchor <[email protected]<mailto:[email protected]>>, David Joseph <[email protected]<mailto:[email protected]>>, Douglas Stebila <[email protected]<mailto:[email protected]>>, Jason Goertzen <[email protected]<mailto:[email protected]>> A new version of Internet-Draft draft-joseph-tls-turbotls-00.txt has been successfully submitted by Deirdre Connolly and posted to the IETF repository. Name: draft-joseph-tls-turbotls Revision: 00 Title: TurboTLS for faster connection establishment Date: 2023-11-05 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.txt Status: https://datatracker.ietf.org/doc/draft-joseph-tls-turbotls/ HTML: https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-joseph-tls-turbotls Abstract: This document provides a high level protocol description for handshaking over UDP in the Transport Layer Security (TLS) protocol (version independent). In parallel, a TCP session is established, and once this is done, the TLS session reverts to TCP. In the event that the UDP handshaking portion fails, TurboTLS falls back to TLS- over-TCP as is usually done, resulting in negligible latency cost in the case of failure. Discussion of this work is encouraged to happen on the TLS IETF mailing list [email protected]<mailto:[email protected]> or on the GitHub repository which contains the draft: https://github.com/PhDJsandboxaq/draft-ietf-turbotls-design<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-7d53d9db5abf71a2&q=1&e=6c163a7b-0fbb-4d8f-89b9-d1aa235ee7c7&u=https%3A%2F%2Fgithub.com%2FPhDJsandboxaq%2Fdraft-ietf-turbotls-design> The IETF Secretariat _______________________________________________ TLS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
