Subject: [Masque] MASQUE and Tor "pluggable transports"

From: Philipp Winter <[email-masked]>
Date: Tue, 6 Aug 2019 09:20:44 -0700

Hi everyone,

I read the most recent MASQUE draft that I found here:
<https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html>
It's great work, thanks for this!

Section 2.4 suggests onion routing on top of MASQUE servers to add
anonymity.  There may be an easier way to accomplish this: one could
turn MASQUE into a "pluggable transport" protocol.  Originally developed
by Tor, pluggable transports are a traffic obfuscation mechanism that
puts a proxy in front of both a client and a server.  These proxies
disguise the traffic that's exchanged between client and server as shown
in the following diagram:
<https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt#n61>

Turning MASQUE into a pluggable transport would make it easy-ish to
integrate for systems that support the pluggable transport specification
including Tor, Psiphon, and Lantern.  MASQUE would also benefit from
security properties offered by its "host" system -- in Tor's case this
would be anonymity.

Practically speaking, a user would start Tor Browser with the MASQUE
pluggable transport (which would be included in Tor Browser).  A
rendez-vous mechanism would inform the user about MASQUE servers that
she could use.  Once a MASQUE server receives the user's HTTPS data, the
server extracts the content and shoves it into a Tor bridge that's
running on the same (or potentially a different) machine.  All of this
could be implemented as part of a new module for the obfs4proxy system,
which is the pluggable transport proxy that the Tor project uses:
<https://gitlab.com/yawning/obfs4>

Is there interest in pursuing support for pluggable transports?

Cheers,
Philipp

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 6 Aug 2019 12:36:06 -0400

Pluggable Transports generally work between special-purpose, cooperating
clients and servers, so standardization is not necessary.  MASQUE, in some
future form, could be a useful basis for a pluggable transport, but I don't
think it makes sense to focus on PT during the standards development
process.

If you're interested in HTTP-like pluggable transports, I suggest looking
at https://github.com/sergeyfrolov/httpsproxy.  Once MASQUE is fully
specified, I expect we'll see transports like httpsproxy utilizing MASQUE
if there is demand.  However, for Tor's purposes, a MASQUE-based transport
is unlikely to represent an improvement over httpsproxy.

On Tue, Aug 6, 2019 at 12:20 PM Philipp Winter <[email-masked]> wrote:

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

---

From: Shivan Kaul Sahib <[email-masked]>
Date: Tue, 6 Aug 2019 09:39:43 -0700

An Internet draft on pluggable transports was discussed at the most recent
privacy research group meeting:
https://tools.ietf.org/html/draft-oliver-pluggable-transports-00

On Tue, Aug 6, 2019 at 9:36 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

>> <https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html
>> >

---

From: David Schinazi <[email-masked]>
Date: Tue, 6 Aug 2019 12:29:37 -0700

Hi Philipp,

Thanks for reading the document, and for your message. I've been reading up
on pluggable
transports and I totally agree that MASQUE could be a good fit - using an
existing framework
to support Tor and other applications seems ideal to me. We're still at the
early stages for
MASQUE - the document doesn't yet define a wire-format that can be
implemented - but once
we get a first draft of that written up and start implementing it, I'd love
to experiment with
pluggable transports to see how well the obfuscation bit of MASQUE plays
with them.

Additionally, once we've accomplished the goal of using MASQUE to help
obfuscate Tor traffic,
there is interest in the community to go for something more ambitious,
which is a tighter
integration between MASQUE (as a way to proxy QUIC over QUIC) and onion
routing. We
suspect that this integration could help with overall performance, but a
lot of code needs to
be written to see if the theory hold water.

So I guess one way to phrase this is that there are multiple components in
MASQUE:
- the obfuscation bit sounds like a great fit for pluggable transports
- the QUIC proxying bit sounds like it could be interesting as an
underlying transport,
    but that would involve a whole lot more work.

Thanks,
David

On Tue, Aug 6, 2019 at 9:40 AM Shivan Kaul Sahib <[email-masked]>
wrote:

>>> <
>>> https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html
>>> >

---

From: Philipp Winter <[email-masked]>
Date: Wed, 7 Aug 2019 15:05:14 -0700

On Tue, Aug 06, 2019 at 12:29:37PM -0700, David Schinazi wrote:
> We're still at the early stages for MASQUE - the document doesn't yet
> define a wire-format that can be implemented - but once we get a first
> draft of that written up and start implementing it, I'd love to
> experiment with pluggable transports to see how well the obfuscation
> bit of MASQUE plays with them.

Thanks for your interest!  I'd be happy to help out once MASQUE reaches
this stage.

> obfuscate Tor traffic, there is interest in the community to go for
> something more ambitious, which is a tighter integration between
> MASQUE (as a way to proxy QUIC over QUIC) and onion routing. We
> suspect that this integration could help with overall performance, but
> a lot of code needs to be written to see if the theory hold water.

FYI, here's a recent summary of this effort, which you may already be
familiar with:
<https://lists.torproject.org/pipermail/tor-dev/2018-March/013026.html>

Cheers,
Philipp

---

From: David Schinazi <[email-masked]>
Date: Wed, 7 Aug 2019 17:59:27 -0700

Thanks for the link, Philipp. That was news to me, and really interesting!

The first thought that comes to mind is that we could use QUIC encryption
between relays (instead of DTLS) and even for the layered onion encryption.
That would require changing how QUIC authenticates, but IETF QUIC was
designed to allow that by having quic-transport
<https://quicwg.org/base-drafts/draft-ietf-quic-transport.html> and quic-tls
<https://quicwg.org/base-drafts/draft-ietf-quic-tls.html> be separate
documents.

Now it's just a matter of writing (a lot of) code :-)

David

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 08 Aug 2019 11:06:41 +1000

> between relays (instead of DTLS) and even for the layered onion 

That seems reasonable.  There are some MTU concerns here, but nothing a little engineering can't fix.

> That would require changing how QUIC authenticates, 

How so?  QUIC doesn't really dictate how you authenticate.  Maybe some implementations would have to change, but they would need to do that for tunneling anyway (as they already do for proxying).

---

From: David Schinazi <[email-masked]>
Date: Wed, 7 Aug 2019 18:13:20 -0700

> How so?  QUIC doesn't really dictate how you authenticate.  Maybe some
> implementations would have to change, but they would need to do that for
> tunneling anyway (as they already do for proxying).
>

Sorry what I meant was "That would require changing how current
implementations of QUIC authenticate" - today most folks are implementing
QUICv1 which has quic-transport and quic-tls. We'd need implementations of
a separate new QUIC version that uses a different authentication scheme.

David

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 08 Aug 2019 11:27:44 +1000

On Thu, Aug 8, 2019, at 11:13, David Schinazi wrote:
> implementations of QUIC authenticate" - today most folks are 
> implementing QUICv1 which has quic-transport and quic-tls. We'd need 
> implementations of a separate new QUIC version that uses a different 
> authentication scheme.

Still not following you there.  Why would that stack not work in this instance?

---

From: David Schinazi <[email-masked]>
Date: Wed, 7 Aug 2019 18:40:54 -0700

> Still not following you there.  Why would that stack not work in this

I'm not very knowledgeable on Tor yet, but if Tor has an authentication
scheme that is sufficiently different from TLS for parts of its encryption,
if it wants to switch that to QUIC it'll need an implementation of QUIC
with the different authentication mechanism.