Re: [Masque] MASQUE detection through tracking trackers

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
>