Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TurboTLS: TLS connection establishment with 1 less round trip

arxiv.org

Post reply on HN
Print view View original

1–10 of 50 posts

Re: TurboTLS: TLS connection establishment with 1 less round trip

#4

Post by ThePhysicist »

londons_explore wrote: post #2

HTTP/3 seems to offer all these benefits already... And seems to be simpler and more compatible... And doesn't require a new DNS field which will surely trip up plenty of middleboxes...

Encrypted Client Hello (ECH) is similar as it requires an extra DNS record, for a different purpose though.

Re: TurboTLS: TLS connection establishment with 1 less round trip

#5

Post by dwheeler »

r1ch wrote: post #3

An interesting idea, but QUIC / HTTP/3 also avoids the extra RTT for TLS negotiation by bundling it with the connection handshake and in a less janky way than this. I don't see a good reason for a server or browser developer to implement this when QUIC exists.

TLS is used for other protocols, e.g., SMTPS (SMTP + TLS). But there's an extra DNS query for this case, and I don't think TLS setup time is a significant cause of delays. So I don't know how useful this is.

Re: TurboTLS: TLS connection establishment with 1 less round trip

#6

Post by j16sdiz »

dwheeler wrote: post #5
r1ch wrote: post #3

An interesting idea, but QUIC / HTTP/3 also avoids the extra RTT for TLS negotiation by bundling it with the connection handshake and in a less janky way than this. I don't see a good reason for a server or browser developer to implement this when QUIC exists.

TLS is used for other protocols, e.g., SMTPS (SMTP + TLS). But there's an extra DNS query for this case, and I don't think TLS setup time is a significant cause of delays. So I don't know how useful this is.

I think most SMTP use STARTTLS with preetablished TCP connection..

Re: TurboTLS: TLS connection establishment with 1 less round trip

#7

Post by ekr____ »

londons_explore wrote: post #2

HTTP/3 seems to offer all these benefits already... And seems to be simpler and more compatible... And doesn't require a new DNS field which will surely trip up plenty of middleboxes...

Without taking a position on TurboTLS versus H3...

There are actually two types of middlebox problems:

1. DNS resolvers which don't carry new record types. 2. Middleboxes which don't properly handle UDP-based protocols

(2) applies to both H3 and to TurboTLS, and in both cases you need some kind of fallback in case things fail.

(2) applies to TurboTLS as specified. However, it's worth noting that H3 also has a DNS-based mechanism for advertising support via the HTTPS record (that is also used for ECH). However, you can also advertise H3 support via Alt-Svc, so presumably you could do the same with TurboTLS.

In general, any new transport like H3 or TurboTLS has to be offered on a best-effort basis with a fallback, otherwise you'll have a lot of hard failures.

Re: TurboTLS: TLS connection establishment with 1 less round trip

#8

Post by mananaysiempre »

j16sdiz wrote: post #6
dwheeler wrote: post #5

Earlier quoted context omitted.

TLS is used for other protocols, e.g., SMTPS (SMTP + TLS). But there's an extra DNS query for this case, and I don't think TLS setup time is a significant cause of delays. So I don't know how useful this is.

I think most SMTP use STARTTLS with preetablished TCP connection..

Not sure about real-world statistics, but the current IETF position is that SMTP STARTTLS for mail submission (not transport) is to be phased out in favour of “implicit” SMTP-over-TLS with no cleartext portion, due in part to the former being an implementation minefield[1].

[1] https://datatracker.ietf.org/doc/html/rfc8314#appendix-A

Re: TurboTLS: TLS connection establishment with 1 less round trip

#9

Post by dwheeler »

j16sdiz wrote: post #6
dwheeler wrote: post #5

Earlier quoted context omitted.

TLS is used for other protocols, e.g., SMTPS (SMTP + TLS). But there's an extra DNS query for this case, and I don't think TLS setup time is a significant cause of delays. So I don't know how useful this is.

I think most SMTP use STARTTLS with preetablished TCP connection..

There's a big push to use implicit TLS with SMTP, instead of STARTTLS. Here's a post about that:

https://blog.apnic.net/2021/11/18/vulnerabilities-show-why-s...

Post reply on HN