The Quiet Work Behind Internet Protocols

The Internet runs on protocols that most people never think about—DNS for finding servers, TCP and QUIC for moving data, TLS for securing connections, HTTP for structuring requests. Each one is a carefully negotiated standard, and standards are where the real decisions about how the Internet works get made. Cloudflare Research has been deeply involved in several recent protocol developments, focusing on incremental fixes, larger architectural changes, and reusable building blocks.

That work has three goals: improving existing protocols, solving structural problems, and creating abstractions that protocol designers can reliably reuse. Each goal requires different kinds of engagement with the IETF, where most of these protocols are standardized.

Plugging Privacy Leaks One Protocol at a Time

The Internet leaks metadata. When a client connects to a server, it reveals the server's identity in DNS queries, in the TLS handshake, and sometimes even in the destination IP address. That lets third parties link a user's IP address to the sites they visit, creating per-user profiles without consent.

Fixing this takes a series of individual protocol changes, each addressing one piece of the leak:

  • DNS-over-HTTPS encrypts DNS queries between clients and recursive resolvers, so only those two parties see plaintext DNS traffic.
  • TLS Encrypted Client Hello (ECH) encrypts metadata in the TLS handshake itself, hiding the server name from everyone except the client and the authoritative server.
  • Oblivious DNS-over-HTTPS (ODoH) breaks the link between client IP address and DNS traffic entirely, using cryptography and network proxies so resolvers only see the queries—without per-client information.
  • MASQUE standardizes proxying arbitrary UDP and IP protocols over QUIC connections, analogous to HTTP CONNECT for TCP, letting clients use services without exposing their IP address.

Individually, these are incremental improvements. Together, they raise deeper questions: Do DoH and ECH provide enough privacy by themselves, or are tools like ODoH and MASQUE required? Could MASQUE subsume ODoH eventually? Those are open questions that need real deployment and analysis to answer.

QUIC and the Case for Architectural Change

QUIC and HTTP/3 are the biggest recent changes to how the web transfers data. QUIC is not just a faster version of TLS-over-TCP. Its security model is built around encryption at multiple layers, it resists network-layer ossification better, and it takes fewer round trips to establish a secure connection.

QUIC also pushes back on long-standing assumptions. The venerable socket API, which treats a connection as an in-order bit pipe, is no longer the right abstraction for modern applications. Higher-level APIs like Apple's Network.framework give developers access to QUIC's features without needing to think about sockets at all.

One distinctive trait worth noting: nearly every bit of a QUIC packet is encrypted and authenticated between sender and receiver. Frames within a packet can be rearranged or transformed by the sender at will. For context, TLS 1.3 had to include a middlebox compatibility mode because earlier TLS wire formats had become ossified by years of middlebox behavior. QUIC's design is meant to avoid repeating that cycle, protecting its extensibility for the long term.

That extensibility has already produced a wave of related work: multipath QUIC, new congestion control schemes, DATAGRAM frames for unreliable delivery, DNS-over-QUIC for recursive-to-authoritative traffic, and WebTransport for web applications. MASQUE builds directly on those features. The QUIC ecosystem is still young, and its future use cases are far from settled.

Standards as Reusable Building Blocks

Part of what standards bodies do is create building blocks—well-specified pieces that other protocol designs can depend on without reinventing them. One of the clearest recent examples is Hybrid Public Key Encryption (HPKE), a nearly-final standard for encrypting arbitrary data to a recipient's public key using a mix of asymmetric-and then symmetric-key cryptography.

That technique—hybrid encryption—has been used in TLS and PGP for years, but each protocol rolled its own version. HPKE takes that variation out of the equation with a single, interoperable standard that has been through thorough cryptographic analysis and has multiple implementations. Protocol designers can now treat it as a well-tested black box rather than a design decision to be evaluated from scratch.

HPKE is already used by major drafts including ECH, ODoH, and Message Layer Security (MLS).

Participation in Theory and in Practice

Engagement with the IETF is not just about showing up at meetings. Protocol development happens through a cycle of specifying, implementing, experimenting, and analyzing, and Cloudflare's value to that process comes partly from its operating context.

Running a large network gives Cloudflare experience deploying emerging technologies at scale quickly, an opportunity many standards participants lack. Publishing the results of those experiments—positively or negatively—helps inform the community. Open-sourcing experimental code also contributes reproducibility.

Some of the work is procedural as well. The IETF reaches decisions by consensus, and the organization thrives when voices that can build agreement are active. There are Cloudflare employees chairing working groups in the IETF as well as in its research arm, the IRTF—spanning security, privacy, transport, and application work, and extending into formal analyses designed to catch issues before a protocol becomes final.

The goal is that standards remain genuinely open, so the latest protocol gains benefit anyone who uses the Internet, regardless of vendor or affiliation.