4 ms·
Thanks for the reply! It's coming back now; I definitely remember reading some early drafts and thinking "boy it's sad this is just HTTP 3.0-rc1". I always li
by KirillPanov 5y ago
Thanks for the reply!
It's coming back now; I definitely remember reading some early drafts and thinking "boy it's sad this is just HTTP 3.0-rc1". I always liked SCTP; I'm glad IETF-QUIC has moved back towards being (sort of) SCTP-over-UDP as well as a better HTTP.
On the encryption front I don't remember reading about a non-TLS version (I probably missed it). I'm kinda sad that got dropped. TLS is just crazy complicated in ways that are unnecessary for non-web things like ssh and wireguard.... X.509 and the whole certificate authority trainwreck.
I really hope we get a "QUIC with non-TLS encryption" at some point in the future.
- tialaramex 5y agoI don't buy the theory that the Web PKI or some equivalent is "unnecessary for non-Web things". If anything I think there have been a few places where there's a nasty security gap because somebody didn't just stuff the Web PKI in there, even though it wasn't necessarily a perfect fit, because what we got instead was nothing ie no security. An example of that first: Does your phone try to connect to SomeBrand WiFi networks? How does it know if this is a "real" SomeBrand WiFi network? It doesn't. In some scenarios this means you leak valid credentials for the "real" SomeBrand to bad guys. In most cases you at least leak identity information. That's not great news. If the WiFi network was named example.com the WiFi AP could of course present a certificate for example.com, leveraging the Web PKI. Now, there are people who want to do QUIC without TLS, mostly what they want to do is NOISE. Like this: https://www.cryptologie.net/article/467/quic-noise-nquic/ https://www.cryptologie.net/article/467/quic-noise-nquic/ But again, I think something like SSH is the exception and the Web PKI is more applicable to most uses for QUIC.