Re: [Masque] MASQUE detection through tracking trackers

Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 05 November 2019 21:29 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4284B12095B for <masque@ietfa.amsl.com>; Tue, 5 Nov 2019 13:29:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level:
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB399erk518D for <masque@ietfa.amsl.com>; Tue, 5 Nov 2019 13:28:59 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD97120B7E for <masque@ietf.org>; Tue, 5 Nov 2019 13:28:59 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id q21so14498358vsg.3 for <masque@ietf.org>; Tue, 05 Nov 2019 13:28:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=unJvnvAohucru2T4sjrQ1d8OzDZs6+2+uBEKflKmTpM=; b=lYRXh/cJ2FkSHUtd/sbbF/XStkZDzh0ylFHvAR6/J03PLhA9JkxQBBx8A0wR4euZkY rvESH3UEJDSyu2UStYbSOXbF8X8jpnqRVN2RlM+2lew46VHordUgEb0bUJPahf+BNRSD b1lWee0DDOzfv5XBIh3vqFAKfU8K91CMnyR99QPshYXQXcYYi3jZchXJV0P2uwicLHf7 du9sV28mX+L51wPi7xuaXUrpPocVPP+VJM+/dqrz8l2f27OSsL+LX/5mgRNxDEdlAI6K Qry1FHD+8kFJI8HqFQSSeaXq81hLqoVMJs9uDFbtcM6pqPczn5eS4Xf7lfA1q8btmB2n NHbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=unJvnvAohucru2T4sjrQ1d8OzDZs6+2+uBEKflKmTpM=; b=Q3l1/nyc4i3zc3c0e5YAScumGjTFl/ruEodPNhWlqhxTd/LFpzWw1g0CzchMSkoYYQ QfV/3bW6qYvvc0d4u9W7559mXFGqaE+d0fLiNMM0lsy020+qICsedH7BNwpEhMFr0Quj i0FY5oz1AMWoEU8BAy87IupVF5vlVchXAWxnBOXJhDyfGHdcHpTNNcjACJQM32eikXIW 8ZgNsg19pTM/uywkMY8E3cOChLFPT+kqtCKYzWSF92sH+7fAe2e9+qcgsWVTZZ/gWGi5 q3viqhCr8LON262Knt63rmK1H4G97FzThhFe+3zpa0fB+P5tJU+IRAqzuMA5JGfGd3XN BHFw==
X-Gm-Message-State: APjAAAXLEIg3mGXO2DMATbKD0VSjrsv34oQrHODyR3Pro2ljeNKKeEiz LtaW/hMNEhKkZsDMwVRW0O6I1z/Vif52KVRPIAE=
X-Google-Smtp-Source: APXvYqzAmCMWL9j4NL3gvW30QTkevwGJQb7XbOJuXMHas90ZbsZQHK2bSz1hzr7VtKtg8NPfANmARyNOQVmrsmIZW2M=
X-Received: by 2002:a67:d904:: with SMTP id t4mr5027011vsj.100.1572989338443; Tue, 05 Nov 2019 13:28:58 -0800 (PST)
MIME-Version: 1.0
References: <CALZ3u+Yd3wu3G2o-AJErNw6SSgU97F-osJfJhYaiuu5Sb9sF6g@mail.gmail.com> <CA+9kkMAbwCTfMb8Z-meqjuuqSGqR+E9OOe8EF1QpeTwAQj4ktA@mail.gmail.com> <CALZ3u+Y6tPDPW3MFnUsPjtZGwgm3t0CBu+BCy=jH-ty3ra6Sng@mail.gmail.com> <CA+9kkMBt-dQxaDgxCh_S7LWiYNMc94tTUNFo0KHhH6fhc34nuw@mail.gmail.com> <CALZ3u+YNd4SCvoyt9=+vcBVvBw=Ty9R-GFDCR-Nu_rF1WMqiYw@mail.gmail.com> <CACdeXiLWJbCfKY7UP5wtkhe0RXksWF3ZdFxTycPrG1TUMS_7dg@mail.gmail.com> <CALZ3u+Yx+V_MhJA8XvWrFTtxu1ow2LAiDYby2Z88Z1mWVotvTQ@mail.gmail.com> <CAPDSy+6KmfqndiHkgybS_mwO8YufBFrcpAQXdJbDJT0ewZ9-sA@mail.gmail.com> <CAHbrMsCwRMhR8gWccNSM6bGYw4TEPXP7gouJOvSZ4k3bSQ0p5A@mail.gmail.com>
In-Reply-To: <CAHbrMsCwRMhR8gWccNSM6bGYw4TEPXP7gouJOvSZ4k3bSQ0p5A@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 5 Nov 2019 21:28:47 +0000
Message-ID: <CALGR9obSNfKsY4imNUuBFvD4CZc8wBBg5r9KLqdj6rx86XaDAA@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, Ted Hardie <ted.ietf@gmail.com>, =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= <ximaera@gmail.com>, Nick Harper <nharper@google.com>, masque@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c0e3800596a01e30"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/D7qDmv-F8zqaa0KVUmkMxPZbjyI>
Subject: Re: [Masque] MASQUE detection through tracking trackers
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2019 21:29:01 -0000

This is indeed quite interesting, thanks for sharing. Initially I was in
the camp of Ted, David and Ben but then I asked myself the question in a
different way. If the prevalent use-case for MASQUE is to be
indistinguishable from HTTPS (to an unauthed observer) then your traffic
patterns have to match common HTTPS flows. Consider web browsing, video
streaming and APIs.

Arguably the only one of those three that has long-lived high-traffic
traffic patterns in a single connection (like you might see in a VPN-like
connection) is video and sadly the number of legitimate video streaming
services is easy to enumerate*.

The mention of padding to mitigate timing analysis feeds into the above
behavior, rather than resembling bursty web-like traffic.

Trying to solve such problems is probably out of scope I agree. But the
question I ask is, is MAQUE's premise trivial defeated in deployment
reality?

Lucas


* be also aware that legitimate streaming services have also value in being
enumerated

On Tue, 5 Nov 2019, 21:08 Ben Schwartz, <bemasc=40google.com@dmarc.ietf.org>;
wrote:

> 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 <dschinazi.ietf@gmail.com>;
> wrote:
>
>> 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 <ximaera@gmail.com>;
>> wrote:
>>
>>> Peace,
>>>
>>> On Tue, Nov 5, 2019, 10:32 PM Nick Harper <nharper@google.com>; 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/masque
>>>
>> --
>> Masque mailing list
>> Masque@ietf.org
>> https://www.ietf.org/mailman/listinfo/masque
>>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>