> 1. The Loopix paper mentions "Furthermore, many mix nodes can be securely > added to a stratified topology to scale throughput" but your mixdesign.txt > states "Operators are a part of a fixed set who all agree to cooperatively > run an equal size set of mixes and network perimeter points". Hopefully I'm > understanding you wrong but it sounds like: > > a) The proposed network won't scale as Loopix intended to.
No, it will scale as Loopix intended. The constraint that each Operator will run an equal size set of mixes is a deployment constraint that may not be adhered to strictly. We shall see, for now we haven't even finished our implementation so we are a ways away from discovering what works for deployments. What is to be understood here about the stratified topology for mix networks is that it the best option we have because it scales well, has slightly better entropy than free route topology, much easier to prove entropy than free route and allows for a fixed set of perimeter mixes in this case we call them Providers. Whereas most mixnet papers end up writing about cascade topology which doesn't scale well at all. > b) There are additional trust requirements/assumptions that Loopix doesn't > require. The Loopix design does use the same model we are implementing where Provider authenticate clients. > Could you clarify? > > 2. Why is a PKI necessary? On a quick read, Loopix paper doesn't seem to > mention this. You have a brief justification in pki.txt but the text does not > make complete sense to me: "it gives each client the same view of the > network, it links mix IDs to public routing keys." > > - If by "same view" you mean "same view of crypto identities" then this > suggests the network can't scale, as I was worried about above. > - If by "same view" you mean "same view of online/offline nodes" I think > this is impossible to achieve due to well, networks being unreliable. > > If mix IDs are simply the public routing keys themselves, does that avoid > the need for a PKI? I suppose you still need to map public keys to physical > addresses, but there's probably an existing system you could re-use for that > purpose. Yes you are right to point out the vagueness in the PKI spec draft I sent you. Mixnets like Tor require a PKI that clients can query to gain a view of the network so that path selection is possible. Like Tor's Directory Authority system we need to store various bits of information about each mix in say, a "mix descriptor". By "same view" I mean each client (just like in Tor) should receive the same network consensus document. The client uses this for path selection. To be clear, we are totally punting on the load balancing problem because it's hard. However, the new Peer Flow paper looks promising: [PEERFLOW] Johnson, A., Jansen, R., Segal, A., Syverson, P., "PeerFlow: Secure Load Balancing in Tor", Preceedings on Privacy Enhancing Technologies, July 2017, <https://petsymposium.org/2017/papers/issue2/paper12-2017-2-source.pdf>. > 3. "The PKI also needs to hold network wide parameters." I meant network parameters that cannot otherwise be detected such as the Poisson mix strategy lambda parameter that all clients must use with selecting their route hop delays. > - Why is this necessary, why can't each mix node detect this by itself? If > they rely on a "PKI" for these parameters, doesn't the "PKI" hold some > position of power over the network? The PKI is the root of all authority in the network... it can decide which mixes belong and what certain network parameters are set to. This is also why making the PKI/Directory Authority into a decentralized system is a good idea. > - How do these parameters relate to the exponential/poisson RV parameters > mentioned in the Loopix paper? Do those parameters also need to be uniform > across all mix nodes? I suppose not, since it is supposed to defend against > malicious mix nodes, but perhaps "most honest nodes" need to agree on the > same parameters. In any case, I don't see the point being explained in great > detail. (Again, this on a quick reading; I might have missed something.) > > Those are the specific questions. Apart from that, it would be good if you > could summarise the differences between your design and Loopix plus some > motivation on why. (Because people like me naturally ask "why not just do > Loopix".) We are essentially doing the Loopix design here. Ania, the primary author of the Loopix paper spent 3.5 months with us in our design team working on these specifications. We are adding to it's design: reliability via Stop and Wait ARQ. Also... we didn't get around to specifying decoy traffic and we intend to do this later. > I gather that you do already talk about this elsewhere, it just would be nice > to have it collected together in a separate document. For example the Loopix > paper has a Section 6 "Related Work" and a Table 2 that summarises this - it > was very nice to read that, especially for me who hasn't looked at this topic > for a significant time. > > In particular, it would be good if you could talk a bit about how your > differences, affect Loopix's original security properties. I think Section > 2.3 "Security Goals" is quite a nice summary of what it's trying to achieve. > If you could confirm that is indeed what your system is also aiming for, > together with any other security properties it doesn't mention, it would be > much easier to evaluate. Well... Stop and Wait ARQ is vulnerable to active confirmation attacks... like say an attacker causes the ACK packet to get dropped. In this case the sender would retransmit. However we intend to specify decoy traffic at some point in the future which should mitigate this kind of confirmation. Perhaps it would be less reassuring had we decided to use Go Back N ARQ or Select Repeat ARQ where missing ACKs cause more packets to be retransmitted. Yes, in summary our mixnet will have all the same security goals as Loopix but will not practically achieve most of them until the decoy traffic is specified. Cheers, David
signature.asc
Description: PGP signature
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging