Think about interoperating with other anonymity systems.

[Yawning]

As much as Katzenpost will rule them all, it may be worth giving thought to where and how to inter-operate with other anonymity systems.

My inclinations here are:

• It is pointless to use alternative transports within the network itself (Provider<->Node, Node<->Node, Provider/Node<->Authority links).
• It makes sense to support alternative transports between the Client and Authority, though in the near future (as in when I get around to it), clients will cease speaking to the Authority at all, so this will be a wasted effort.
• The main place where this would be a good idea is the Client->Provider link.

With that in mind, this is roughly what needs to happen:

• Solidify the MixDescriptor format changes required to support server instances publishing alternative addresses.
• Add support for clients to fetch directory documents from the Provider.
• Add the support to the server code for publishing alternative addresses.

This should happen before any production network is deployed because the changes are sweeping, and will either break things, or impose the overhead of writing and maintaining backward compatiblity/transition code.

[david415]

interesting. Certain colleagues of mine in Berlin pointed out that the Loopix Provider model doesn't offer very strong location hiding properties and they suggested that clients should connect to Providers using Tor. If Providers had an onion address then that would also be good. I think this is a good feature until we change the Provider model to something with ephemeral aggregation points that queue messages and are retrieved by SURBs.

[Yawning]

This is somewhat offtopic, but I don't really thing there's anything wrong with the current Provider model to be honest. If this were some utopian world where abuse didn't exist, then I would have designed it differently, but as long as there is a requirement for users to be strongly authenticated (to thwart abuse if nothing else), most of the other designs impose considerable additional design complexity (yes, I am aware that blind signed tokens are a thing).

Back to being on topic, my current plan (unless someone comes up with something better) is to alter the Addresses array in the MixDescriptor to something like Addresses map[string][]string, where the key would be the transport, and the value the vector of address. For example:

[
  "Addresses": {
    "tcp4": { "192.0.2.1:1234", "198.51.100.2:4567" },
    "tcp6": { "[2001:DB8::1]:8901" },
    "torv2": { "thisisanoldonion.onion:2323" },
  },
]

[Yawning]

Ok, the MixDescriptor format that I proposed in a comment is now the new and improved MixDescriptor format. All nodes MUST currently have at least one tcp4 address or the descriptors will be treated as invalid.

Both server and minclient need additional changes to leverage the added functionality, but I figure that getting the main breaking change over with now is the sensible thing to do.

[Yawning]

I went and added the tcp transport which allows FQDNs because clients using DNS to figure out what address to contact the provider on seems like a perfectly reasonable thing to do. All internal addressing is still explicitly IP based.

[Yawning]

The server and authority handle publishing alternative addresses, though the mailproxy will only use the transports that it understands (so nothing exotic).

This is basically done, Tor's fairly unusable these days because of the HS related overload issues anyway, so I'm going to delay working on this more till I can use the network without wanting to cut myself.