Subject: [Masque] Feedback requested on paper draft that mentions MASQUE

From: David Fifield <[email-masked]>
Date: Tue, 21 Jul 2020 23:36:56 -0600

I'm writing a paper for the upcoming Free and Open Communications on the
Internet (FOCI) workshop. The topic is somewhat related to MASQUE, in
that I advocate for the use of QUIC or a similar session/reliability in
the interior of circumvention protocols. It's not quite the same as
MASQUE, because I'm not suggesting to use QUIC as the outermost layer
exposed to the censor, but as an inner layer providing greater
flexibility in program design.

This is the current draft. The final revision is due 28 July.
https://www.bamsoftware.com/papers/turbotunnel/turbotunnel-20200721.pdf

My primary concern is to ensure that I am representing MASQUE fairly and
accurately. Of course I welcome comments in general.

	MASQUE is a proposal to colocate covert proxy servers with
	existing web servers, over HTTP/2 (TLS/TCP) or HTTP/3
	(QUIC/UDP). Despite the use of QUIC, MASQUE is not really an
	example of the Turbo Tunnel idea. The key difference is that
	MASQUE puts QUIC on the outside of the protocol stack, not the
	inside, and makes QUIC itself act as the obfuscation layer, with
	the goal of blending in with normal web traffic. Alternatively,
	MASQUE could be regarded as an optimization in which the same
	protocol (QUIC) works across three layers: session/reliability,
	obfuscation, and network transport (refer to Figure 1). The
	observation is that not only is QUIC a convenient session
	protocol, it also makes a good cover protocol, because of its
	encrypted-by-default nature and its increasing use on the
	Internet. Collapsing three layers into one avoids the overhead
	of encapsulating QUIC packets into some other protocol. The
	efficiency comes at the loss of some flexibility: the
	obfuscation of MASQUE is not ``pluggable''; the only option for
	obfuscation is as web traffic.

There's some additional discussion on MASQUE here:
https://github.com/net4people/bbs/issues/9

Thanks for your work on MASQUE.

---

From: David Schinazi <[email-masked]>
Date: Wed, 22 Jul 2020 10:11:32 -0700

Hi David,

Thanks for sharing your paper! I enjoyed it.

Overall I agree that adding a session layer on top of pluggable
transports makes sense, as it allows moving the internal
sessions across different proxies or pluggable transports
without disrupting connectivity.

Regarding your description of MASQUE, it reflects my original
vision for MASQUE, but that has changed a little bit in the
last year of IETF discussions, so I would add some tweaks:

- Obfuscation is no longer the main goal of MASQUE, though
it is a requirement, so I'd rephrase the first sentence to
something along the lines of:
<<   MASQUE is a proposal to colocate proxy servers with
        existing web servers, over HTTP/2 (TLS/TCP) or HTTP/3
        (QUIC/UDP); it allows proxying capability to be
        indistinguishable from regular Web Traffic.>>

- I would link to the charter of the MASQUE working group at
https://datatracker.ietf.org/wg/masque/about/ instead of
draft-schinazi-masque-obfuscation.

- When you say "MASQUE is not really an example of the
Turbo Tunnel idea", I think you're right, though I'll point out
that you could use multiple layers of MASQUE to accomplish
that. In other words, you could run MASQUE as both your
pluggable transport and as your Turbo Tunnel session layer.
We mentioned this briefly in the "Onion Routing" section:
https://tools.ietf.org/html/draft-schinazi-masque-obfuscation-02#section-2.3
So I would perhaps rephrase the rest of the paragraph to
mention that:
  - as a pluggable transport, MASQUE only has the option
    of looking like Web traffic
  - MASQUE could also be used as a Turbo Tunnel session
    layer inside another pluggable transport

I'm happy to chat about this more, I'm sure it'll take more
work to actually get MASQUE to a point where it could be
useful for you, but making sure it meets that use-case is
important to me.

Cheers,
David

On Tue, Jul 21, 2020 at 10:37 PM David Fifield <[email-masked]>
wrote:

> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: David Fifield <[email-masked]>
Date: Mon, 27 Jul 2020 18:15:02 -0600

>         indistinguishable from regular Web Traffic.>>

Thanks for this explanation. It helped me understand how MASQUE has
developed. That, and the IETF 107 slides helped.
https://www.ietf.org/proceedings/107/slides/slides-107-masque-masque-master-slide-deck-02

> draft-schinazi-masque-obfuscation.

Okay.

> pluggable transport and as your Turbo Tunnel session layer.

Yes -- I'm glad you picked up on this. QUIC works both as a covert
obfuscation protocol and as a session protocol, and there's nothing
incoherent about QUIC-in-QUIC, with the outer QUIC being a disposable
pure transport mechanism and the inner layer holding the actual session
state. It's really no different than KCP-in-TCP, say: replace KCP
(session protocol) with QUIC, and replace TCP (transport protocol) with
QUIC.

I was reluctant to mention the QUIC-in-QUIC idea only because, in my
experience trying to explain the Turbo Tunnel idea, the biggest point of
confusion is that as soon as you mention QUIC, people's minds turn to
UDP and they think you are proposing a UDP-based pluggable transport.
It's a bit of work to communicate the idea that if QUIC is used for its
session properties, the QUIC packets are not sent as UDP datagrams but
are encoded into some other obfuscation protocol, which may not be
UDP-based at all. The fact that QUIC actually works in both places
doesn't help the explanation :)

>     layer inside another pluggable transport

Here is how I have revised the paragraph:
	MASQUE~\cite{masque-wg} is a proposal to colocate proxy servers
	with web servers, over HTTP/2 (TLS/TCP) or HTTP/3 (QUIC/UDP),
	such that proxy traffic looks like ordinary web traffic. Despite
	the use of QUIC, MASQUE is not really an example of the Turbo
	Tunnel idea---the key difference is that it puts QUIC on the
	outside of the protocol stack, not the inside. To put it in
	terms of this paper, in MASQUE, QUIC is the obfuscation layer
	(chosen to look like web traffic), not the session/reliability
	layer. However, thanks to the fact that QUIC works well both as
	a session protocol and as an obfuscation protocol, MASQUE could
	be adapted into a Turbo Tunnel design in two ways. First, one
	could run some other session protocol through the MASQUE tunnel,
	treating MASQUE as just another obfsucated proxy protocol.
	Alternatively, one could encapsulate MASQUE's QUIC packets into
	some other obfuscation layer (obfs4, say, or even another
	instance of MASQUE) and use MASQUE as an inner session layer.

---

From: David Schinazi <[email-masked]>
Date: Mon, 27 Jul 2020 18:10:03 -0700

Thanks for following up, David!

I agree with you on the details, and the revised paragraph looks great!

David