[messaging] Thoughts on reliability-optimized Mixnets

[dawuud]

replying inline.

On Sun, Dec 31, 2017 at 03:33:08AM +0100, Moritz Bartl wrote:
> On 31.12.2017 02:18, Vincent Breitmoser wrote:
> > Research papers typically select these variables to have very strong
> > anonymity guarantees. But it might be worthwhile exploring (or at least
> > brainstorming) the opposite approach: Optimize for the least impact on
> > usability, reliability, and performance, and see if we can still get
> > worthwhile anonymity gains.
> 
> I would first like to see any actual formulas. It irritates me to even
> begin to think about tradeoffs before we know what they might be in the
> first place.

Indeed. I agree, mildly rage inducing.

> > Obviously, the only way for a mixnet provider to avoid
> > depending on another organization's operational performance is to run
> > all mixes itself. 
> 
> The Internet depends on "other organization's operational performance"
> all the time. Constantly. It is the Internet, after all. So, you put
> reliability on top of unreliable networks, and that can give you certain
> guarantees, regardless of who operates parts of it.

I agree with this as well. There is a huge amount of packet switching network
literature to back up this claim as well. Roughly 40 years of papers endorsed
by the IETF, no? The burden is not upon us to defend these established design
principles.

> > Now this leads to an interesting legal question: How difficult is it,
> > for some entity (that is generally honest), to create an organizational
> > structure that operates mixes, under different jurisdictions?
> 
> As long as you exercise control (and that control can be constructed to
> even just be "you write the software for your 'own' network"), that is
> just too weak for anything serious. The type of legal attacks we're
> already looking at is no fun, and I don't expect this to become
> better... Look at what happened to the mix cascade run by the TU
> Dresden, due to legal pressure. [1]
> 
> But yes, probably this could be done in a way that is less
> straightforward to attack. If this is what people need to hear to
> finally support this kind of research, then OK, I'm willing to agree
> with the "better than nothing" argument, especially since it does not
> change anything for me in terms of design, priorities, and required work.
> 
> It just sounds a lot more realistic to have a court sign some order for
> "one bad actor (plus all subsidiaries under its control)" than for 10
> legally independent parties.

I agree with this as well. The point of the mix network is to have
multiple security domains. If not then you just run a server in the closet
or a one hop proxy/vpn.

> > This seems
> > like it's too easy - but what's to prevent three nominally independent
> > mix service providers from running a mixnet, for some umbrella org?
> 
> I really do not see a problem with participating providers to actually
> participate, and for some of them to provide decent bandwidth. We need
> one mix operator to be honest, and depending on your exact architecture
> you can get away with a total of three.
> 
> Compare this with Tor, where you not only need hundreds or thousands of
> relays, you also need operators who can deal with hundreds of abuse
> complaints per day. Which you simply won't have in a closed messenger
> scenario.
> 
> Overall, I see fifty other things that I would prioritize, and that
> needs to be either developed or researched, regardless of who will
> eventually run the network. Maybe that is not enough motivation, but
> really, I don't see the big problem with mixnet operations spread across
> multiple entities. Usenet does it, and how many PBs are transported
> there daily nowadays?

Indeed multiple entities operating the network is the only way to do it properly.

> Just to give you an idea, a non-profit IX in Berlin is sponsoring us
> 10Gbit/s of actual traffic, just like that. This is happening at more
> and more places, thanks to the Tor relay community, and together with
> the "no abuse problems" argument, it will be fairly easy to find even
> faster, stable sponsored sites.
> 
> What's the figures we are looking at for zcash transactions? Signal
> messages? Whatsapp? What would that mean for a mixnet?
> 
> Generally, it seems that practitioners are underestimating how much
> actual research this topic still needs before we should put a mixnet in
> front of any actual users. Until we have that research, we should use
> the momentum to support them, make it easy to run simulations and
> experiments, and once we have anything that resembles an interesting
> research project we have more than enough universities already who would
> love to participate in a large testbed.

Yes! It is about proper design and measuring leakage so that we can
cast aside our statistical intuitions and establish facts about a given
mix network.

Anyway, us sending e-mails without action items isn't going to change
the situation. The researchers will do their research and we will write code.
Once they publish the paper about tuning Loopix then we can write our
decoy traffic specification document and then write code.

> There are dozens of interesting mixnet designs, and there is no (in
> numbers: zero, none) framework that allows researchers to actually test
> their hypotheses. We have the opportunity here to give them the right
> tools, which also deals with real-world network issues and everything
> else that is usually out of scope (PKI etc).

Yes and I suspect that in the future, using ns-3, the descrete network
event simulator will be useful as well. But perhaps it will be a distant
future when an experienced ns-3 developer helps with the mixnet movement.

> Moritz
> 
> [1] https://anon.inf.tu-dresden.de/strafverfolgung/index_en.html
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20171231/a5e9e2f1/attachment.sig>