[flagged]
TurboTLS: TLS connection establishment with 1 less round trip
11–20 of 50 posts
Re: TurboTLS: TLS connection establishment with 1 less round trip
#12This 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...
Re: TurboTLS: TLS connection establishment with 1 less round trip
#13HTTP/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-bas…
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).
Re: TurboTLS: TLS connection establishment with 1 less round trip
#14HTTP/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-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 ready (and the h2 connection does not have any queued requests). At least that is my understanding.
Re: TurboTLS: TLS connection establishment with 1 less round trip
#15This 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...
...provided a round trip has already been made. In other words, not a single round trip.
Re: TurboTLS: TLS connection establishment with 1 less round trip
#16fewer
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.
Re: TurboTLS: TLS connection establishment with 1 less round trip
#17An 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?
Re: TurboTLS: TLS connection establishment with 1 less round trip
#18This 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...
...provided a round trip has already been made. In other words, not a single round trip.
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)
Re: TurboTLS: TLS connection establishment with 1 less round trip
#19An 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.
[deleted]
Re: TurboTLS: TLS connection establishment with 1 less round trip
#20Earlier quoted context omitted.
...provided a round trip has already been made. In other words, not a single round trip.
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 coming up on 50 years old at this point.