New Privacy Protocols and Edge Infrastructure | Fastly

These days,  everybody demands that cryptography be used to secure communication and enhance privacy. You wouldn’t think of launching a new web service without HTTPS anymore. It has also become common to do direct messaging using Internet-based end-to-end encryption in order to counteract some of the spying and phishing abuses of legacy SMS, email, and voice calls. Even a data gathering project as large as the U.S. Census is trying to use cryptography to enhance privacy.

As this landscape has matured, we have gained an increased appreciation for the subtlety of data protection. For instance, it’s not always just the data in transit that needs protection; you need to consider the role metadata plays as well. 

Protecting Metadata

I have personal experience with this. After HTTPS had gained significant momentum, the Internet was left with the problem that HTTPS only protects the contents of web transactions – not the metadata that sets up those transactions. The biggest leaker was DNS—used to translate the host names you see in URLs into IP addresses that can be connected to.

Traditional DNS requests could be snooped on and attackers could substitute their own answers in place of the real ones. A user could pick a DNS server of their choice – perhaps one they trusted – but attackers on the communications network would frequently route the request to any server they liked. The user couldn’t tell the difference, even if this hijacking used the client’s data to support a data broker business model.

Securing DNS Traffic

Subsequently, I co-authored a specification for DNS over HTTPS (aka DoH RFC 8484) which is now one common way for a client to secure their DNS traffic. Clients using DoH can be confident that their communications with a DNS server are restricted to just the client and server. This is a significant advancement over traditional unsecured DNS. There is still a metadata issue with the Server Name Indication within HTTPS itself, and that is being addressed through an independent effort in the IETF named Encrypted Client Hello.

However, even with those two technologies, the situation is imperfect. Secure two-party communication is ideal for a conversation such as a text message, where both parties trust each other but may not trust the network that connects them. A DNS server is not quite the same situation – a client still may not trust the network that connects it to the server, but it may not totally trust the server, either. DoH can protect against the network attacker, and HTTPS or DNSSec can prevent the server from providing incorrect responses, but nothing in the protocol prevents the server itself from tracking who made what DNS request.

The Next Step: Oblivious DNS

The next evolution in DNS is represented by Oblivious DNS (aka ODoH). I co-authored and helped publish it as RFC 9230. ODoH applies IP Blinding techniques to DoH using double encryption and a single relay to separate the content of the DNS request from the identity of the client. In brief, a relay is used by the client to hide the client’s IP address from the DoH server. In this manner the relay sees only the identity because of the double encryption, and the DoH server sees only the DNS data because it is not communicating directly with the client.

IP blinding is a trend in privacy-aware networking. First brought to prominence by ToR, it has also recently been used by the Private Relay service. Both of those examples apply IP blinding to the transport layer (streams of arbitrary internet data), while ODoH is specific to DNS and operates at the application layer. Application-specific protocols can be easier to manage at scale than generic transport protocols, so it is architecturally nice to have multiple approaches available to attack the problem.

In Progress: Oblivious HTTP

Oblivious HTTP (aka OHTTP) will provide a third approach. OHTTP is currently a not-yet-standardized draft within the IETF, but promises to generalize ODoH to carry arbitrary HTTP exchanges in a way that blinds the server to the identity of the client while still hiding the content through the relays. OHTTP requires four nodes for a single transaction – a client, a relay, a gateway, and the server – making it a bit more resource-intensive than ODoH but more flexible in what it can accomplish.

Edge cloud platforms, like Fastly, provide key roles in delivering the infrastructure for the modern, privacy-aware network. We are working with more partners every day to explore the fit between our edge cloud and the needs of these blinding applications. Our programmable network is essentially an infinitely-scalable distributed application platform ideal for this paradigm. It offers CPU, bandwidth, and low-latency services, available globally. Even better, the edge cloud platform is optimized as an HTTP delivery platform already providing advanced TLS, routing, and connection management, which are all essential to a high performing infrastructure.

This post is part of Privacy Week, where Fastly is bringing you stories about how we’re integrating privacy practices and technology into the very fabric of the internet.