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

21–30 of 50 posts

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

#21

Post by r1ch »

drowsspa wrote: post #17
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.

Doesn't it require you to already have connected to the server once?

There's a couple of "previously connected" bits with QUIC:

- The very first connection to a site is usually HTTP/2, which requires an additional RTT compared to QUIC, as the browser doesn't yet know if the server supports QUIC. In the response, the server can advertise the presence of QUIC support with the Alt-Svc header. This support flag can also be present in a HTTPS DNS record for the domain but that isn't queried by all browsers yet. Future connections to the same server will default to QUIC once the browser is aware of support, saving an additional RTT.

- Once connected to a QUIC server, the encryption keys can be cached for future connections, allowing the client to send data with the initial connection request (so called 0-RTT). This is only safe for idempotent requests though as this part of the protocol could be replayed by an attacker.

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

#22

Post by aseipp »

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.

The latency hit of the extra trip will definitely be felt by end users if the endpoint is far enough away (e.g. ~100-200ms.) You can mitigate the initial setup other ways though, like the CDN approach: terminate TLS much closer with a proxy and use a warm, pre-established backhaul connection to the origin.

Less round trips are always good, though, without any extra stuff to put in place.

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

#23

Post by ekr____ »

SahAssar wrote: post #14
ekr____ wrote: post #7

Earlier quoted context omitted.

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-bas…

> However, you can also advertise H3 support via Alt-Svc, so presumably you could do the same with TurboTLS. Alt-Svc is an http header, by the time you get http you already have TLS setup. In a Alt-Svc workflow you generally advertise h2 in TLS ALPN, then use Alt-Svc to advertise h3 capability in the headers of the first response, and then the client establishes a h3 connection and closes the h2 connection when it is…

Yes, that's correct. Basically the only good way to have a "first contact" fast track setup like this is by priming in DNS. My point is that the situation is th same for TurboTLS and QUIC/H3 in this respect.

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

#24

Post by ekr____ »

jakear wrote: post #20
baby wrote: post #18

Earlier quoted context omitted.

Not really, provided some data is already known, which is the case in TLS has well (either you know the public key of the server, or you trust a set of CAs)

"Secure communication in a single round-trip" implies securely transmitting to a specific audience without any correspondence beforehand and securely receiving information from them afterwards - which seems impossible - probably because it is. If you relax the constraints to allow for shared state beforehand (which could only arise from prior communication-trips of some sort), you're just at RSA: cool to be sure, but…

As you say, if you want to have 0-RTT data, you must have some prior information about the server. This information can come in two main forms.

1. Have the client know the server's public key in advance. You can then do a RSA or ephemeral-static key exchange, as in gQUIC, OPTLS, or TLS Fasttrack. 2. Have the client and the server do an initial handshake and then reuse the symmetric key for future connections, as in TLS 1.3 and IETF QUIC (which uses TLS 1.3).

The public key version has a number of superficially compelling properties, in particular that you can publish the server's data somewhere like DNS ("0-RTT Priming") and thus have 0-RTT with the first connection. By contrast with the symmetric version you have to have a connection first. The public key mode also will work in this setting. However, making this work in practice has a number of challenges around authentication, anti-replay, anti-amplification, etc. Initially TLS 1.3 had both of these modes but we ultimately removed the public-key based one in favor of a symmetric-key based mode.

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

#25

Post by semafour »

coreyp_1 wrote: post #16
foo42 wrote: post #10

fewer

https://www.merriam-webster.com/words-at-play/fewer-vs-less 1. See the exceptions section. Less is preferred in this construction. 2. Please do not misconstrue the opinion of one writer that lived 200 years ago into a proper grammar rule (see the history section). Worse, please do not be dogmatic about it when it has nothing to do with the topic. It is, in essence, the equivalence of an ad hominem attack.

It's also a joke, though: https://www.youtube.com/watch?v=zXINZxodu9U

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

#26

Post by JohnFen »

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...

But what about all the non-hypertext protocols?

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

#27

Post by bqmjjx0kac »

ThePhysicist wrote: post #4
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.

In fact, they both require the same DNS record: the HTTPS record.

(Well, technically ECH can obtain server configs any way, but HTTPS is recommended.)

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

#28

Post by drewg123 »

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.

QUIC is horribly inefficient on the server side, so there are legitimate reasons to use TLS 1.3 over TCP in high traffic scenarios (like CDN servers).

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

#29

Post by 10000truths »

drewg123 wrote: post #28
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.

QUIC is horribly inefficient on the server side, so there are legitimate reasons to use TLS 1.3 over TCP in high traffic scenarios (like CDN servers).

Interesting, can you explain in more detail on what makes QUIC more inefficient than TLS over TCP on the server side?

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

#30

Post by ekr____ »

JohnFen wrote: post #26
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...

But what about all the non-hypertext protocols?

HTTP/3 is based on QUIC, and these perf properties are due to QUIC, not H3.

With that said, the unusual performance dynamics of the Web make connection setup latency particularly important by contrast to, for instance, SMTP, where people don't really get bent out of shape if a message takes another 200ms to be delivered.

Post reply on HN