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

David Schinazi <> Tue, 06 August 2019 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9494120059 for <>; Tue, 6 Aug 2019 12:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QsYYVLpfpUgX for <>; Tue, 6 Aug 2019 12:29:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D76D12003F for <>; Tue, 6 Aug 2019 12:29:50 -0700 (PDT)
Received: by with SMTP id m8so49605430lji.7 for <>; Tue, 06 Aug 2019 12:29:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PjVNZZJJ3orQswj7ezqSsBf/vKgXHSzcGs93EdRvv1I=; b=K2HOQz6ehwX/KRpWWiKmv/bVYu+CQ7ZTGyabmpVCroE5lgdFBUgaTYnd/84Ax56EvR 1FZosqvgg0IKJ8zm0dnM9rJYCfQzi6dYaB1/EqIfCOhgs9vXjYWGqPGQ0Q4btrrv/Czg iVxVFBD/lUi9V+mCJMKi447UGQ3Hm8LQ2nuQnh2GItbfwXoZsUE7dm+nph47gLY2RHaC 5++nwwHW2NT0dr571VATRl+YokZM0uORIAjn4e9hrRXEiXP/K9ggGkeJWBlIh6oNNeey PTD30s7oo7MqmToR2NR7EgUbRg80U1SSoTitLNg7yvBJDA2dYyGTiXve3WV9M5JG6mM0 sKCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PjVNZZJJ3orQswj7ezqSsBf/vKgXHSzcGs93EdRvv1I=; b=nUCVoEbOIlJDRRtrF4E0v9mrdqenjk43NF8W2I7eVUcYfIeJtM2psxfA4gcBe8L4+l uhf3W63seAa+BVZcsz3JsRUlFdo+4Pbthw34PR9SkW5sFgn9wt8hIr7m2N3841cpMoIz S4yeH2nnv3AAuY4sqw1x7cBkYz1q+bz6MHQU6D5WZzNq0CC2OjjbqOy0b0eR/Q+cSq24 iMWudpbIXinmxwEpL3R5sB8IGwGEvnlcrgqVEZJmhXU4NIS/uVnGYR36X1Fox57yKGtR ff+aW9ZKEnHdgdQjTUI30kTLyD3LDZpaRPgNk1+7htgazk2kbLeJG0w3Do32CxBSlQZj tbWg==
X-Gm-Message-State: APjAAAV/t5dMfYSnVDpN1wBSW2L488u+vViumhYCOkDiBQcMmbr/tM6+ rk4ph6Si0Km36WcXa/H7/3dAbnK9znydBj+REXY=
X-Google-Smtp-Source: APXvYqxo6SENyBz9rALy7PU8gi0heI/NvbV4ioH5HLUuIVseap4dnowo+vyJvdMS2snbmWtB6AfHmvjejVa/CG8n6FA=
X-Received: by 2002:a2e:5b0f:: with SMTP id p15mr2549200ljb.82.1565119788352; Tue, 06 Aug 2019 12:29:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Tue, 6 Aug 2019 12:29:37 -0700
Message-ID: <>
To: Philipp Winter <>
Content-Type: multipart/alternative; boundary="000000000000040a03058f77d940"
Archived-At: <>
Subject: Re: [Masque] MASQUE and Tor "pluggable transports"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Aug 2019 19:29:54 -0000

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
- 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.


On Tue, Aug 6, 2019 at 9:40 AM Shivan Kaul Sahib <>;

> An Internet draft on pluggable transports was discussed at the most recent
> privacy research group meeting:
> On Tue, Aug 6, 2019 at 9:36 AM Ben Schwartz <bemasc=
>>; wrote:
>> 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  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 <>;
>> wrote:
>>> Hi everyone,
>>> I read the most recent MASQUE draft that I found here:
>>> <
>>> >
>>> 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:
>>> <>
>>> 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:
>>> <>
>>> Is there interest in pursuing support for pluggable transports?
>>> Cheers,
>>> Philipp
>>> --
>>> Masque mailing list
>> --
>> Masque mailing list
> --
> Masque mailing list