The MASQUE Proxy
Internet-Draft draft-schinazi-masque-proxy-04
David Schinazi
Google LLC
1600 Amphitheatre Parkway
Mountain View
CA
94043
United States of America
dschinazi.ietf@gmail.com
28 August 2024
masque
proxy
kuzh
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document defines the concept of a "MASQUE Proxy", an Internet-accessible node that can relay client traffic in order to provide privacy guarantees.
About This Document
The latest revision of this draft can be found at https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque-proxy.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-schinazi-masque-proxy/.
Source for this draft and an issue tracker can be found at https://github.com/DavidSchinazi/masque-drafts.
Introduction
In the early days of HTTP, requests and responses weren't encrypted. In order to add features such as caching, HTTP proxies were developed to parse HTTP requests from clients and forward them on to other HTTP servers. As SSL/TLS became more common, the CONNECT method was introduced [CONNECT] to allow proxying SSL/TLS over HTTP. That gave HTTP the ability to create tunnels that allow proxying any TCP-based protocol. While non-TCP-based protocols were always prevalent on the Internet, the large-scale deployment of QUIC [QUIC] meant that TCP no longer represented the majority of Internet traffic. Simultaneously, the creation of HTTP/3 [H3] allowed running HTTP over a non-TCP-based protocol. In particular, QUIC allows disabling loss recovery [DGRAM] and that can then be used in HTTP [HTTP-DGRAM]. This confluence of events created both the possibility and the necessity for new proxying technologies in HTTP.
This led to the creation of MASQUE (Multiplexed Application Substrate over QUIC Encryption). MASQUE allows proxying both UDP ([CONNECT-UDP]) and IP ([CONNECT-IP]) over HTTP. While MASQUE has uses beyond improving user privacy, its focus and design are best suited for protecting sensitive information.
Privacy Protections
There are currently multiple usage scenarios that can benefit from using a MASQUE Proxy.
Protection from Web Servers
Connecting directly to Web servers allows them to access the public IP address of the user. There are many privacy concerns relating to user IP addresses [IP-PRIVACY]. Because of these, many user agents would rather not establish a direct connection to web servers. They can do that by running their traffic through a MASQUE Proxy. The web server will only see the IP address of the MASQUE Proxy, not that of the client.
Protection from Network Providers
Some users may wish to obfuscate the destination of their network traffic from their network provider. This prevents network providers from using data harvested from this network traffic in ways the user did not intend.
Partitioning
While routing traffic through a MASQUE proxy reduces the network provider's ability to observe traffic, that information is transfered to the proxy operator. This can be suitable for some threat models, but for the majority of users transferring trust from their network provider to their proxy (or VPN) provider is not a meaningful security improvement.
There is a technical solution that allows resolving this issue: it is possible to nest MASQUE tunnels such that traffic flows through multiple MASQUE proxies. This has the advantage of partitioning sensitive information to prevent correlation [PARTITION].
Though the idea of nested tunnels dates back decades [TODO], MASQUE now allows running HTTP/3 end-to-end from a user agent to an origin via multiple nested CONNECT-UDP tunnels. The proxy closest to the user can see the user's IP address but not the origin, whereas the other proxy can see the origin without knowing the user's IP address. If the two proxies are operated by non-colluding entities, this allows hiding the user's IP address from the origin without the proxies knowing the user's browsing history.
Obfuscation
The fact that MASQUE is layered over HTTP makes it much more resilient to detection. To network observers, the unencrypted bits in a QUIC connection used for MASQUE are indistinguishable from those of a regular Web browsing connection. Separately, if paired with a non-probeable HTTP authentication scheme [CONCEALED-AUTH], any Web server can also become a MASQUE proxy while remaining indistinguishable from a regular Web server. It might still be possible to detect some level of MASQUE usage by analyzing encrypted traffic patterns, however the cost of performing such an analysis at scale makes it impractical.
This allows MASQUE to operate on networks that disallow VPNs by using a combination of protocol detection and blocklists.
Related Technologies
This section discusses how MASQUE fits in with other contemporary privacy-focused IETF protocols.
OHTTP
Oblivious HTTP [OHTTP] uses a cryptographic primitive [HPKE] that is more lightweight than TLS [TLS], making it a great fit for decorrelating HTTP requests. In traditional Web browsing, the user agent will often make many requests to the same origin (e.g., to load HTML, style sheets, images, scripts) and those requests are correlatable since the origin can include identifying query parameters to join separate requests. In such scenarios, MASQUE is a better fit since it operates at the granularity of a connection. However, there are scenarios where a user agent might want to make non-correlatable requests (e.g., to anonymously report telemetry); for those, OHTTP provides better efficiency than using MASQUE with a separate connection per request. While OHTTP and MASQUE are separate technologies that serve different use cases, they can be colocated on the same HTTP server that acts as both a MASQUE Proxy and an OHTTP Relay.
DoH
DNS over HTTPS [DoH] allows encrypting DNS traffic by sending it through an encrypted HTTP connection. Colocating a DoH server with a MASQUE IP proxy provides better performance than using DNS over port 53 inside the encrypted tunnel.
Security Considerations
Implementers of a MASQUE proxy need to review the Security Considerations of the documents referenced by this one.
IANA Considerations
This document has no IANA actions.
Informative References
[H3]

HTTP/3
M. Bishop, Ed.
June 2022
RFC 9114
DOI 10.17487/RFC9114
[TODO]

find that 20 year old email about using nested CONNECT tunnels with SSL to improve privacy
[CONNECT]

Upgrading to TLS Within HTTP/1.1
R. Khare
S. Lawrence
May 2000
RFC 2817
DOI 10.17487/RFC2817
[QUIC]

QUIC: A UDP-Based Multiplexed and Secure Transport
J. Iyengar, Ed.
M. Thomson, Ed.
May 2021
RFC 9000
DOI 10.17487/RFC9000
[DGRAM]

An Unreliable Datagram Extension to QUIC
T. Pauly
E. Kinnear
D. Schinazi
March 2022
RFC 9221
DOI 10.17487/RFC9221
[HTTP-DGRAM]

HTTP Datagrams and the Capsule Protocol
D. Schinazi
L. Pardue
August 2022
RFC 9297
DOI 10.17487/RFC9297
[CONNECT-UDP]

Proxying UDP in HTTP
D. Schinazi
August 2022
RFC 9298
DOI 10.17487/RFC9298
[CONNECT-IP]

Proxying IP in HTTP
T. Pauly, Ed.
D. Schinazi
A. Chernyakhovsky
M. Kühlewind
M. Westerlund
October 2023
RFC 9484
DOI 10.17487/RFC9484
[IP-PRIVACY]

IP Address Privacy Considerations
Matthew Finkel
Apple Inc.
Bradford Lassey
Google
Luigi Iannone
Huawei Technologies France S.A.S.U
Brad Chen
Google
23 October 2022
Internet-Draft draft-irtf-pearg-ip-address-privacy-considerations-01
[PARTITION]

Partitioning as an Architecture for Privacy
M. Kühlewind
T. Pauly
C. A. Wood
July 2024
RFC 9614
DOI 10.17487/RFC9614
[CONCEALED-AUTH]

The Concealed HTTP Authentication Scheme
David Schinazi
Google LLC
David Oliver
Guardian Project
Jonathan Hoyland
Cloudflare Inc.
28 August 2024
Internet-Draft draft-ietf-httpbis-unprompted-auth-10
[OHTTP]

Oblivious HTTP
M. Thomson
C. A. Wood
January 2024
RFC 9458
DOI 10.17487/RFC9458
[HPKE]

Hybrid Public Key Encryption
R. Barnes
K. Bhargavan
B. Lipp
C. Wood
February 2022
RFC 9180
DOI 10.17487/RFC9180
[TLS]

The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla
August 2018
RFC 8446
DOI 10.17487/RFC8446
[DoH]

DNS Queries over HTTPS (DoH)
P. Hoffman
P. McManus
October 2018
RFC 8484
DOI 10.17487/RFC8484
Acknowledgments
MASQUE was originally inspired directly or indirectly by prior work from many people. The author would like to thank Nick Harper, Christian Huitema, Marcus Ihlar, Eric Kinnear, Mirja Kuehlewind, Brendan Moran, Lucas Pardue, Tommy Pauly, Zaheduzzaman Sarker and Ben Schwartz for their input.
In particular, the probing resistance component of MASQUE came from a conversation with Chris A. Wood as we were preparing a draft for an upcoming Thursday evening BoF.
All of the MASQUE enthusiasts and other contributors to the MASQUE working group are to thank for the successful standardization of [HTTP-DGRAM], [CONNECT-UDP], and [CONNECT-IP].
The author would like to express immense gratitude to Christophe A., an inspiration and true leader of VPNs.