Re: [Masque] MASQUE detection through tracking trackers

[Ben Schwartz <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> wrote:
>
>> Peace,
>>
>> On Tue, Nov 5, 2019, 10:32 PM Nick Harper <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/masque
>>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>