Re: [Masque] MASQUE detection through tracking trackers

David Schinazi <dschinazi.ietf@gmail.com> Tue, 05 November 2019 20:49 UTC

Return-Path: <dschinazi.ietf@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 680DD120BD2 for <masque@ietfa.amsl.com>; Tue, 5 Nov 2019 12:49:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=0.001] autolearn=ham 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 5_1rOLQAo8zJ for <masque@ietfa.amsl.com>; Tue, 5 Nov 2019 12:49:16 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 B28F4120BC9 for <masque@ietf.org>; Tue, 5 Nov 2019 12:49:15 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id j14so16185558lfb.8 for <masque@ietf.org>; Tue, 05 Nov 2019 12:49:15 -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=8dvpSscAdMXYpIgDa9tpoL2HBKQaSNkXSHeggOwO644=; b=uyf90jaTkh/ZJ6tFCNWES/CjgrFyZwlhPoGojKMbWGitP5YS//wcC/BK/OYHNDVZD8 TZNdOFcxlgeJFYVzuoIPr+RLzbuuxEd79rD0MYxzeI21WqeLfyxXyA0b+Ux5Kd4GoKP6 N6yBP3Xa2M7SOnjXCxscZcBCxw2Hokg8c6upJEPbzi+7Gb2B+WDdMZdSq7FlAFRGYt9L 5mXnshnP49vQwPMqhsIXXHYMIbc1YFniwy41XOVNq7jXZ4UoWyAdM8VwwPjpIk21vV4R tzDWoiFMHFquOq6+1mKYvEnCVj9N53/y83qTB8jHorUYP6wS3BIEOG9gm5OmouE6YLGt 7r6g==
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=8dvpSscAdMXYpIgDa9tpoL2HBKQaSNkXSHeggOwO644=; b=C09OiugCeTXeao7lBkncn8Gz3yiZgXmpQqePygct2edO7fsD0PkdFMpxiF2o/eLQTD yUwkXQCcS+3wtBBU9U7EI87SLU1d/E4xlIUws9U1xLdocvs/jBol/z/PtND+40VTjfae JOxwsLo7+07nlB0CUABM0xkkTEBfAhdt1NYREOvbzPWJZF4Kgs4pCt0iqfab9SVdsbtd E5uzFpE9blbmAwHmUGfzU2SYqy3xbFd2AefMp0mvPgb3f5QHtfbPAAK8PxwVyHX+Pi76 aEReBAig/nfW/UNg74N6BswkjZwqc6nXYG2SU/pQWh+v7tvijcrGHuGsdBySVAkaLq0r BE+w==
X-Gm-Message-State: APjAAAXYlOkic4GBTJmbKrOn+zifeCZeZAVpmz0y8tEv7vN6tyvh2hU/ /pYPNlzFwUDghXoZ2efNrREfT6rhWF22Lm0KB78=
X-Google-Smtp-Source: APXvYqwWsSePWQj4a61mflMxmj8eFDarjfaFQtxp9taj5LFqiirrv8hAXIGgGxdoK+R2KfK5ZOyvouqltkPEvrQ+M88=
X-Received: by 2002:a19:6b04:: with SMTP id d4mr22473025lfa.10.1572986953944; Tue, 05 Nov 2019 12:49:13 -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>
In-Reply-To: <CALZ3u+Yx+V_MhJA8XvWrFTtxu1ow2LAiDYby2Z88Z1mWVotvTQ@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 5 Nov 2019 12:49:02 -0800
Message-ID: <CAPDSy+6KmfqndiHkgybS_mwO8YufBFrcpAQXdJbDJT0ewZ9-sA@mail.gmail.com>
To: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= <ximaera@gmail.com>
Cc: Nick Harper <nharper@google.com>, Ted Hardie <ted.ietf@gmail.com>, masque@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a051f105969f9020"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/qrk7BMxehvtB0ECi6P7VGobuuB8>
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 20:49:18 -0000

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
>