> > 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.
I support everything Martin has said here. IMO the only circumstance in which 'unencrypted (integrity-only) QUIC' could make sense is for internal use in datacentres. It is certainly true that the protocol as designed is (rightly) designed for the public internet and certainly reflective of the hostility of the public internet as a network environment today. At the same time it makes it feel a bit overkill for a backend protocol between servers in a trusted environment. But maybe the burden of that is a non-issue in practice. I imagine a lot of providers supporting HTTP/3 remain using HTTP/2 or HTTP/1.1 for their backend connections behind HTTP LBs, at least for now. Maybe this will change with things like WebTransport. But I'd certainly expect higher CPU usage. Of course people will argue how you are supposed to know you have a trusted environment. "SSL added and removed here :)" and all that. I imagine there would be general wariness of the risk that the thing starts getting accidentally (or deliberately) deployed on the public internet. Best not to go back to the fun of NULL as a ciphersuite option. The risk of the thing getting deployed in corporate environments (many of which keep deploying broken ways to try and break TLS to snoop on traffic) seems even higher. QUIC is very well designed in that it has a clean separation between the handshake layer and the rest of it, so as noted in principle you could swap out TLS 1.3 for something else. I believe there was one paper discussing the merits of doing this with the Noise protocol. But in principle anything could be used. The interface between the handshake layer and QUIC is fairly narrow, so (without going into 0-RTT related stuff) any handshake layer would need to be able to: - send and receive data on the crypto bytestream however it likes; - raise alerts, if it wishes; - emit traffic secrets for the different encryption levels; - emit a 'handshake complete' event; - provide transport for the transport parameters. That's about all there is to it. I find the relative narrowness of this interface interesting and usually a sign of good design. So I certainly expect to see people experimenting with different handshake layers in the future.
