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 <d...@sandboxaq.com> 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: <internet-dra...@ietf.org> > Date: Sun, Nov 5, 2023 at 12:43 AM > Subject: New Version Notification for draft-joseph-tls-turbotls-00.txt > To: Carlos Aguilar-Melchor <carlos.agui...@sandboxaq.com>, David Joseph < > d...@sandboxaq.com>, Douglas Stebila <dsteb...@uwaterloo.ca>, Jason > Goertzen <jason.goert...@sandboxquantum.com> > > > 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 tls@ietf.org or on the GitHub repository which contains > the draft: https://github.com/PhDJsandboxaq/draft-ietf-turbotls-design > > > > The IETF Secretariat > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
