31–40 of 50 posts
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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 querie…
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?
Earlier quoted context omitted.
Interesting, can you explain in more detail on what makes QUIC more inefficient than TLS over TCP on the server side?
Kernels and hardware have been optimized for TCP. QUIC will catch up eventually.
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…
Earlier quoted context omitted.
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
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.
Earlier quoted context omitted.
"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…
I’m not sure what’s the relation with RSA but you’re right that it’s simple. And that’s what noise has been doing for years. There isn’t much else to look at here, unless you specifically need tls you should be using noise
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.