[HN Gopher] TurboTLS: TLS connection establishment with 1 less r...
___________________________________________________________________
TurboTLS: TLS connection establishment with 1 less round trip
Author : yuedongze
Score : 73 points
Date : 2023-02-14 18:10 UTC (4 hours ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| londons_explore wrote:
| 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...
| ekr____ wrote:
| 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 wrote:
| 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 wrote:
| > 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____ wrote:
| 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.
| ThePhysicist wrote:
| Encrypted Client Hello (ECH) is similar as it requires an extra
| DNS record, for a different purpose though.
| bqmjjx0kac wrote:
| 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.)
| JohnFen wrote:
| But what about all the non-hypertext protocols?
| r1ch wrote:
| 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.
| dwheeler wrote:
| 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.
| aseipp wrote:
| 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.
| j16sdiz wrote:
| I think most SMTP use STARTTLS with preetablished TCP
| connection..
| mananaysiempre wrote:
| 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
| dwheeler wrote:
| 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...
| drowsspa wrote:
| Doesn't it require you to already have connected to the server
| once?
| r1ch wrote:
| 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.
| [deleted]
| foo42 wrote:
| fewer
| coreyp_1 wrote:
| 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 wrote:
| It's also a joke, though:
| https://www.youtube.com/watch?v=zXINZxodu9U
| betimsl wrote:
| [flagged]
| jewel wrote:
| 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-p...
| jakear wrote:
| ...provided a round trip has already been made. In other words,
| not a single round trip.
| baby wrote:
| 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 wrote:
| "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____ wrote:
| 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.
___________________________________________________________________
(page generated 2023-02-14 23:00 UTC)