On 1/22/2024 8:00 PM, Martin Thomson wrote:
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.
+1
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.
That was a huge problem pre-HTTPS. Middle-boxes would "improve" the
communication by changing the definition of videos, suppressing
"unnecessary" parts of a protocol, detecting "errors" because they were
not programmed to handle a specific variant, etc. In the world wide
Internet, middle-boxes will get creative in a world-wide variety of
ways, resulting in protocol errors and application bugs that were almost
impossible to diagnose, let alone fix.
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.
I see two reasons to ask for plaintext: surveillance and debugging. I
won't comment on surveillance, but Martin is 100% right about debugging.
Qlog standardizes the debug logs of the protocol, and has proven
extremely valuable during debugging. The standard hooks define for
Wireshark allow exporting session keys to the local Wireshark instance,
resulting in display of captures in which QUIC packets and frames are
recognized.
Yes, in theory encryption might make debugging harder. But in practice
we have way fewer bugs in encrypted protocols, because we don't have to
deal with outsiders' interference. And the standard tools really ease
debugging a lot.
-- Christian Huitema
