Re: [Masque] MASQUE detection through tracking trackers

Ben Schwartz <> Tue, 05 November 2019 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEF7012095B for <>; Tue, 5 Nov 2019 13:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 jHt2cSEYJW1q for <>; Tue, 5 Nov 2019 13:08:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CEAA1208CB for <>; Tue, 5 Nov 2019 13:08:21 -0800 (PST)
Received: by with SMTP id i6so939543ilr.11 for <>; Tue, 05 Nov 2019 13:08:21 -0800 (PST)
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=vgqWRG+sm6EF3bPQcnlVqOhwf5QXW8gqdQbN33IcXTg=; b=KSLoUMqe08TrCyg/2v/3e7+q10Dm99Fpz7EeWYUAoT9oJqcheO9vSW28pv8yo8TnXu qUo9t4aSB+JTOjIcyQWIGvy+u/kXttJzVkv5B+7SXxI5xtr2VxEOK1orHW8fA+b8+dRH Lefc6M024Gkos9aN2vce3E3Qk23C03hpfS0zluWaQZfwZKsL/06Gbzviuqz6TooOMK8p 9aAN0NV6BgMXKGl9AyCd4v+93n8EHVNsKhReFkzR8s7XlkfKBvqDARadY5aopMP6A68a fnSe8AiN2JvIYufsW2aVaHpMQ5uduMueDRVTdQAHeah4P7HWAZMrOTMKeqQsY91HxjMC w1vQ==
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=vgqWRG+sm6EF3bPQcnlVqOhwf5QXW8gqdQbN33IcXTg=; b=halS9wQ50hRUUhJRLHJ1JUbNOH1iPH2Jq2OriudUqS4aSAvdWbS1WBTEKXkz1UePML EAcqW5oaGzvgUW1q5+/7b2k2Yont1NPgfGZH4iN4LVbl38oAUjtTFv/7KCcNPe+FPviA RGOeYW+31zmF0aV2N8LqJi/Sl5NRiTdkzFS5yjRP6U+Hd+GMyx1XaDHDja5vLjT3Ude9 TvJhu9u1FSrpTOz96DpCx/y34bEjymZCPta/Tq9Z6Xuk/unK+9SqE7eK73mdrP+Pl2sX oUuZM3fl241djVijs+/rxPKevqYcIS7JwVeKdLfl1pTyGcUKHoQT2P1pmztqF4QC2Qaq EJHg==
X-Gm-Message-State: APjAAAVXYsRIqfmMo1i93Kyb1WS7jW+cWIFcj0ivbPStpsHCo9nBbWDN PtutTRIq7Zcqmi8Gzj1Y1Nbc2oTNeUTvzicRxBWw/Q==
X-Google-Smtp-Source: APXvYqzqPKbMxPYFwhoOjXpLvjTkPmRi7qHTmNim6E4GlCaIS+teDlpjjd9sATj9hwzaHh17pKx+zEDnRGVqHoZF3J4=
X-Received: by 2002:a92:8dd9:: with SMTP id w86mr36573116ill.163.1572988100131; Tue, 05 Nov 2019 13:08:20 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 5 Nov 2019 16:08:08 -0500
Message-ID: <>
To: David Schinazi <>
Cc: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= <>, Ted Hardie <>, Nick Harper <>,
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000fcbee405969fd42c"
Archived-At: <>
Subject: Re: [Masque] MASQUE detection through tracking trackers
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, 05 Nov 2019 21:08:24 -0000

I think this topic is fascinating and important, but I support keeping it
out of scope for MASQUE.  The countermeasures you've mentioned are, I
think, largely separable from the MASQUE protocol, and MASQUE is a
challenging enough problem already.

If we want to consider the metadata revealed by the client's pattern of
connections, I think that should go in a different draft, and perhaps a
different working group.  It should also be informed by empirical and
theoretical research that we haven't done.

I do think this is a good reminder that we should keep MASQUE flexible
enough to enable research and experimentation.  For example, it might be
worth reviewing how well MASQUE supports connection migration and load
spreading, to reduce the emphasis on a single proxy IP.

On Tue, Nov 5, 2019 at 3:49 PM David Schinazi <>

> Hi Töma,
> Thanks for bringing this to the list! I really feel like this kind of
> traffic analysis is going to be hard to work around.
> I'm setting the tracking/GDPR and TLS conversations aside because I don't
> think they're integral to the attack here.
> The fundamental issue is that in today's Web, if I browse a random
> website, my browser will not only connect to the
> hostname in the URL bar, but it'll also make many other connections -
> those could be trackers but also CDN-hosted
> images, JavaScript libraries, etc. So a connection to a random website
> that is not accompanied by these sidecar
> requests is going to stick out. I think we may want to discuss this in the
> MASQUE draft, and mention that clients
> should attempt to get a list of these common sidecars, and make decoy
> sidecar requests when bringing up the
> MASQUE tunnel. At the end of the day, traffic analysis evasion is an arms
> race, and there's no way around that.
> The MASQUE document should discuss these attacks and perhaps give
> guidance, but I think ultimately we'll
> need MASQUE implementors to keep innovating in these counter-measures,
> just like middleboxes are innovating
> in their traffic analysis techniques.
> Thanks,
> David
> On Tue, Nov 5, 2019 at 12:22 PM Töma Gavrichenkov <>
> wrote:
>> Peace,
>> On Tue, Nov 5, 2019, 10:32 PM Nick Harper <> wrote:
>>> Depending on the domain, a typical laptop or phone is configured to hard
>>> fail: TLS errors on domains that use HSTS (whether preloaded or sent via an
>>> HTTP header) are non bypassable.
>> In theory, there is no difference between theory and practice.  In
>> practice there is.  People know captive portals are invasive, but they
>> accept the risk.
>> Anyhow, this is not really relevant to the topic.  The access is blocked
>> anyway, you can just recall some Web site w/o HSTS to click through the
>> warning to figure out what is it that the network wants from you.  Maybe in
>> future versions they will implement RFC 7710.  I'm surprised, kind of, that
>> this is apparently the most interesting part of the message.
>> --
>> Töma
>>> --
>> Masque mailing list
> --
> Masque mailing list