1. 12
  1. 4

    If QUIC is always encrypted, and the encryption layer is similar to TLS, then does opening a listening socket require setting up an X.509 cert and dealing with all that PKI crap?

    1. 2

      Interesting question, I tried to find an answer. In short, yes, after Google started out with their own simple encryption/authentication layer the IETF choose to standardize on (a modified version of) TLS 1.3.

      In 2019 a proposal of QUIC based on Noise was presented:

      nQUIC is designed as a minimal update to existing QUIC-TLS implementations. It could be specified as a new QUIC version compatible with the already existing QUIC RFCs. Thus, endpoints could support both TLS and Noise as possible handshakes without conflict. For now, we propose setting the first version of nQUIC to 0xff00000b. This is because the QUIC transport document states that ”[QUIC] versions with the most significant 16 bits of the version number cleared are reserved for use in future IETF consensus”.

      It concludes with:

      We presented nQUIC, a variant of QUIC-TLS that uses Noise for its key exchange algorithm and employs a DH-ratchet to provide post-compromise security. nQUIC offers improved performance, ease of implementation, drastically reduced code size, clear security properties and better protection in case of endpoint compromise. nQUIC does not work with standard PKI-based certificate authentication – it requires trust in static public keys – getting rid of an entire class of vulnerabilities. nQUIC may serve as a second standardized version of the QUIC protocol, which may help prevent network ossification around QUIC-TLS when deployed. For future work, we plan to bring nQUIC to the QUIC Working Group for discussion.

      Now when searching the QUIC working group I only found one thread that mentions nQUIC or Noise: https://mailarchive.ietf.org/arch/msg/quic/UoK2F1F8wOQvji3aBOoS8_3IrPE/

      The Go implementation mentioned in the paper I can not find. The most recent code I could find was this Rust based project: https://github.com/ipfs-rust/quinn-noise. It doesn’t look like there is a very active effort in trying to get this going, but maybe it’s used in a non-public setting.

    2. 2

      Additionally, a client that expands Initial packets helps reduce the order of amplitude gain of amplification attacks caused by server responses toward an unverified client address.

      I’m confused by how this helps. Is the server required to reject any initial packet of size less than 1200 bytes? Otherwise the attacker could just send smaller ones.

      1. 2

        Very interesting write-up. It pictures the trend of moving transport protocol implementations out of the kernel into userspace as the next logical step in the evolution of the end-to-end model. So first with the conception of the Internet and IPv4 we moved complexity out of the network into the endpoints, and now within an endpoint we move complexity out of the platform/OS/kernel, into the application.

        This topic touches upon a major assumption in today’s high-capacity server infrastructure on the public Internet. Data streams use TCP and the DNS uses UDP.

        I wonder how much the popularity of WireGuard will change this ratio.

        1. 2

          Does it have to be between a “client” and a “server” or can it be P2P as well?

          1. 2

            Load balancing QUIC

            Very strange that this section has no mention of connection IDs. The connection ID scheme was clearly very carefully designed to allow for load balancing.