I found a more extensive description of the MASQUE protocol: https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html
Here are my key take-aways after reading the draft:
* MASQUE enables circumvention by hiding a circumvention proxy behind a web server, similar to Sergey's httpsproxy. Clients "unlock" the web server's circumvention feature by using the newly-proposed HTTP Transport Authentication Standard: https://tools.ietf.org/html/draft-schinazi-httpbis-transport-auth-00
In a nutshell, clients need to send a CONNECT request with a transport authentication header to .well-known/masque/initial. Crucially, MASQUE defends against active probing by responding with "405 Method Not Allowed" to failed authentication attempts -- the same response one would get for an unexpected CONNECT request. This prevents censors from learning if a web server supports MASQUE.
* Once a client "unlocked" a MASQUE server, one can tunnel several types of traffic over the MASQUE server. One can use it as an HTTP proxy, send DNS requests, and do both UDP and TCP proxying.
* MASQUE supports QUIC over HTTP/3 and TLS 1.3 over HTTP/2. There is a fallback mechanism from HTTP/3 to HTTP/2 to provide a disincentive for censors to block QUIC or HTTP/3.
* MASQUE only provides obfuscation and does not provide anonymity. The document suggests onion routing in Section 2.4 to work around this shortcoming.
* MASQUE does not defend against traffic analysis but QUIC supports padding, so there's a mechanism to mitigate this problem. Traffic analysis defence is left for future work in Section 7.2.
* QUIC has a "connection migration" feature that allows clients to seamlessly switch end-to-end connections from one MASQUE server to another.
* Similar to onion services, MASQUE makes it possible to make available a server behind NAT by using a MASQUE server as a rendez-vous mechanism.
There's an IETF mailing list for the project: https://mailarchive.ietf.org/arch/browse/masque/
MASQUE may make a good pluggable transport and we should engage early to make this happen. I intend to suggest this idea on their mailing list soon.
Cheers, Philipp
anti-censorship-team@lists.torproject.org