Re: [MLS] Hiding content type

[Brendan McMillion <[e-mail]>]

>
> While the network layer would need to protect against network-level
> traffic analysis such as timing and frequency fingerprinting, this can be
> done in a generalized way that is agnostic to the application (such as if a
> mix network were used to route traffic between the client and the DS).


In the specific case of a mix network, that's not true. The DS has at least
these variables for traffic analysis:

1. Messages which are requested in quick succession (associating messages
that are requested together with the same group)
2. How many times a message is requested (associating a message with the
number of participants in the group it was sent to)
3. Messages requested over the same circuit (Tor and similar networks often
reuse circuits for efficiency)

and may have more depending on context.

On Tue, Jul 28, 2020 at 2:37 PM Chelsea Komlo <[e-mail]>
wrote:

> On Tue, Jul 28, 2020 at 8:11 AM Brendan McMillion <brendan=
> [e-mail]> wrote:
>
>> But in the former class, you would be forcing the application to invent
>>> its own scheme for signaling this stuff, which risks them making decisions
>>> that are suboptimal for metadata privacy.
>>
>>
>> Making a metadata-resistant deployment of MLS would already be incredibly
>> difficult because you'd have to design your application to use the network
>> in a way that prevents useful traffic analysis. Someone who's capable of
>> this should definitely be capable of choosing how messages are identified
>> in their system.
>>
>
> While the network layer would need to protect against network-level
> traffic analysis such as timing and frequency fingerprinting, this can be
> done in a generalized way that is agnostic to the application (such as if a
> mix network were used to route traffic between the client and the DS).
> Ideally, MLS as a higher-level application would not leak additional
> information when it is received by the DS after having been sent through
> such a network.
>
>
>> The flip side, is that your construction is already suboptimal for
>> metadata privacy because the epoch id only changes once per epoch. In the
>> construction that I described, the opaque identifier changes with each
>> message. You could also imagine a system where the identifier would change
>> with time instead of with protocol messages (for example, where messages
>> are distributed over Tor circuits).
>>
>
> It is true that message fields should be bitwise unlinkable to a network
> observer (see [1] for more information on how this property is instantiated
> in routing protocols). Time can be a dangerous dependency in distributed
> systems though, so I would be careful there.
>
> [1] https://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
>
>