14 ms·

TurboTLS: TLS connection establishment with 1 less round trip

112 points by yuedongze 4y ago

londons_explore 4y ago
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...
- ThePhysicist 4y ago
  Encrypted Client Hello (ECH) is similar as it requires an extra DNS record, for a different purpose though.
  - bqmjjx0kac 4y ago
    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.)
- ekr____ 4y ago
  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.
  - londons_explore 4y ago
    And H3 is already pretty widely deployed, so unless TurboTLS has some really compelling benefits, it will lose by default. HTTP/3 is in most browsers under 3 years old, and most server stacks support it (usually with a bit of extra config).
  - SahAssar 4y ago
    > 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 ready (and the h2 connection does not have any queued requests). At least that is my understanding.
    - ekr____ 4y ago
      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.
      - SahAssar 4y ago
        I just meant that QUIC/H3 is beneficial even after you already have a connection, so upgrading an existing connection is a valid strategy. TurboTLS is only beneficial for establishing the connection, so it needs to have prior knowledge about the support to be useful at all.
- JohnFen 4y ago
  But what about all the non-hypertext protocols?
  - ekr____ 4y ago
    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.
  - kixelated 4y ago
    You can use QUIC without the HTTP/3 layer on top. It's a general purpose replacement for TCP+TLS.
    - londons_explore 4y ago
      Does anyone use it for this?
r1ch 4y ago
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.
- drowsspa 4y ago
  Doesn't it require you to already have connected to the server once?
  - r1ch 4y ago
    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.
    - kixelated 4y ago
      You're right that HTTP/3 requires Alt-Svc at the moment. QUIC itself doesn't require a pre-established connection (1-RTT), which is notable for non-HTTP/3 protocols and WebTransport.
- dwheeler 4y ago
  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.
foo42 4y ago
fewer
- coreyp_1 4y ago
  https://www.merriam-webster.com/words-at-play/fewer-vs-less 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.
  - semafour 4y ago
    It's also a joke, though: https://www.youtube.com/watch?v=zXINZxodu9U https://www.youtube.com/watch?v=zXINZxodu9U
  - foo42 4y ago
    Interesting. I wasn't aware of that. I had a colleague who constantly "corrected" us (with some humour) and even long after he left the team we all wince when we see/hear "less" when it should be (or so we believed), "fewer". I preferred it before when I blindly said "less" but didn't always hear a voice in my head commenting on everyone else's use
- dbj99 4y ago
  less. If you correct people's grammar you have to make damn sure you're right otherwise you look a little bit foolish... less modifies singular nouns, fewer modifies plural nouns. Check here for more https://www.latimes.com/socal/daily-pilot/opinion/tn-dpt-me-1003-casagrande-20131001-story.html https://www.latimes.com/socal/daily-pilot/opinion/tn-dpt-me-...
betimsl 4y ago
[flagged]
jewel 4y ago
This reminds me of the noise protocol which lets you communicate securely with a single round trip. http://www.noiseprotocol.org/noise.html#zero-rtt-and-noise-protocols http://www.noiseprotocol.org/noise.html#zero-rtt-and-noise-p...
- jakear 4y ago
  ...provided a round trip has already been made. In other words, not a single round trip.
  - baby 4y ago
    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)
    - jakear 4y ago
      "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 coming up on 50 years old at this point.
      - ekr____ 4y ago
        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.

112 points by yuedongze 4y ago

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

ThePhysicist 4y ago
Encrypted Client Hello (ECH) is similar as it requires an extra DNS record, for a different purpose though.
- bqmjjx0kac 4y ago
  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.)
ekr____ 4y ago
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.
- londons_explore 4y ago
  And H3 is already pretty widely deployed, so unless TurboTLS has some really compelling benefits, it will lose by default. HTTP/3 is in most browsers under 3 years old, and most server stacks support it (usually with a bit of extra config).
- SahAssar 4y ago
  > 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 ready (and the h2 connection does not have any queued requests). At least that is my understanding.
  - ekr____ 4y ago
    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.
    - SahAssar 4y ago
      I just meant that QUIC/H3 is beneficial even after you already have a connection, so upgrading an existing connection is a valid strategy. TurboTLS is only beneficial for establishing the connection, so it needs to have prior knowledge about the support to be useful at all.
JohnFen 4y ago
But what about all the non-hypertext protocols?
- ekr____ 4y ago
  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.
- kixelated 4y ago
  You can use QUIC without the HTTP/3 layer on top. It's a general purpose replacement for TCP+TLS.
  - londons_explore 4y ago
    Does anyone use it for this?

r1ch 4y ago

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.

drowsspa 4y ago
Doesn't it require you to already have connected to the server once?
- r1ch 4y ago
  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.
  - kixelated 4y ago
    You're right that HTTP/3 requires Alt-Svc at the moment. QUIC itself doesn't require a pre-established connection (1-RTT), which is notable for non-HTTP/3 protocols and WebTransport.
dwheeler 4y ago
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.

foo42 4y ago

fewer

coreyp_1 4y ago
https://www.merriam-webster.com/words-at-play/fewer-vs-less 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.
- semafour 4y ago
  It's also a joke, though: https://www.youtube.com/watch?v=zXINZxodu9U https://www.youtube.com/watch?v=zXINZxodu9U
- foo42 4y ago
  Interesting. I wasn't aware of that. I had a colleague who constantly "corrected" us (with some humour) and even long after he left the team we all wince when we see/hear "less" when it should be (or so we believed), "fewer". I preferred it before when I blindly said "less" but didn't always hear a voice in my head commenting on everyone else's use
dbj99 4y ago
less. If you correct people's grammar you have to make damn sure you're right otherwise you look a little bit foolish... less modifies singular nouns, fewer modifies plural nouns. Check here for more https://www.latimes.com/socal/daily-pilot/opinion/tn-dpt-me-1003-casagrande-20131001-story.html https://www.latimes.com/socal/daily-pilot/opinion/tn-dpt-me-...

betimsl 4y ago

[flagged]

jewel 4y ago

This reminds me of the noise protocol which lets you communicate securely with a single round trip. http://www.noiseprotocol.org/noise.html#zero-rtt-and-noise-protocols http://www.noiseprotocol.org/noise.html#zero-rtt-and-noise-p...

jakear 4y ago
...provided a round trip has already been made. In other words, not a single round trip.
- baby 4y ago
  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)
  - jakear 4y ago
    "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 coming up on 50 years old at this point.
    - ekr____ 4y ago
      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.