On Tue, Jan 23, 2024, at 14:29, Marten Seemann wrote: > Plain-text communication was an explicit anti-goal in the design of > QUIC.
This is absolutely right, but I'm a little disappointed that no one has really said *why* yet. 1. This is the right way to build an Internet protocol. I can point to RFC 7258 or considerable effort to improve HTTPS deployment over plaintext HTTP as general trends here. But it goes deeper than that. 2. Many of the features of QUIC critically depend on being able to rely on encryption or integrity protection to some degree. Address validation tokens that leak to the network path would be disastrous for the ability of a server to use those for denial of service mitigation. Performance optimizations like 0-RTT depend on that. While on that point 0-RTT wouldn't work without encryption. And that is without getting into the integral functions that encryption fills in the handshake. 3. QUIC would not deploy without it. Encryption-optional variants of QUIC were tried and it was found that network ossification either immediately or quickly caused those protocols to break in ways that were hard to reason about. So while I understand that debugging QUIC is a wee bit difficult, we didn't use TLS just because we felt like it. Yes, we believe that encryption is the right thing to do, but there was a large pragmatic component. Cheers, Martin p.s., People looking to use QUIC in anger really only have to familiarize themselves with qlog or Wireshark. These are great tools that go beyond just making the content visible into making it comprehensible.
